Summary

  • RADEXT 작업 초안은 RFC 7930이 실험적으로 도입한 RADIUS 패킷 코드 52 Protocol-Error의 표준화를 제안한다. IANA 등록부는 현재도 RFC 7930을 참조한다.
  • 오류에는 Error-Cause와 Original-Packet-Code가 모두 들어가야 한다. 뒤의 속성은 같은 Identifier를 가진 서로 다른 종류의 요청 중 어느 것이 실패했는지 가린다.
  • 이 오류는 한 홉씩 처리된다. 원인 502 또는 505를 받은 프록시는 다른 연결이나 목적지를 시도해야 하며, 방금 실패한 연결로 다시 보내서는 안 된다.

RADIUS에서 답이 없다는 사실은 너무 많은 뜻을 떠안아 왔다. 서버가 바쁜지, 요청을 처리할 수 없는지, 다음 프록시 뒤에서 길이 끊겼는지 접속 장비는 타임아웃만으로 알기 어렵다. 장비는 설정된 규칙대로 다시 보낸다. 장애가 커지면 여러 장비의 재시도가 이미 막힌 길에 한꺼번에 몰린다. 복구 기능이 고장 난 경로의 부하를 키우는 순간이다.

코드 52는 더 정확한 문장을 전한다. 요청은 받았지만 처리하지 못했다는 뜻이다. 11월 초안은 접속, 회계, 권한 변경, 연결 해제 요청을 예로 든다. 회계 기록을 쓰지 못했는데 접수된 것처럼 답하면 운영자는 장부를 믿게 된다. 인증 과정의 기술적 오류를 사용자 거절로 둔갑시키면 고객 지원은 엉뚱한 사람을 조사한다. RFC 7930은 2016년 이 코드를 실험용으로 만들었다. 새 문서는 여러 RADIUS 요청에서 이를 어떻게 다룰지 상세히 정하려 한다.

오류를 올바른 요청에 붙이는 장치가 두 속성이다. Error-Cause는 실패 원인을, Original-Packet-Code는 원래 요청의 종류를 담는다. RADIUS Identifier 숫자는 서로 다른 종류의 요청에서 겹칠 수 있다. 숫자만 보고 맞추면 회계 오류를 로그인 결과로 오인할 수 있다. 응답은 원래 Identifier를 복사하며, 원래 코드에 맞는 진행 중 요청이 없으면 고객은 그 응답을 버려야 한다. 정확한 진단도 잘못된 사건에 붙으면 자동화된 오판의 재료가 된다.

다음 홉이 망가졌다면 경로를 가진 쪽이 움직인다

초안 4절은 Protocol-Error를 홉 단위 패킷으로 정의한다. 프록시는 받은 오류를 그대로 전달할 수 없고 Error-Cause를 읽어야 한다. 프록시 네트워크의 고장인지, 홈 서버가 보낸 문제인지 먼저 나눈다. 프록시가 하위 연결을 선택했으므로 그 연결을 바꿀 권한과 책임도 프록시에 있다. 접속 장비는 자신이 프록시에 건넨 요청까지만 직접 볼 수 있다.

502 Request Not Routable (Proxy)와 505 Other Proxy Processing Error는 초안에서 프록시 네트워크의 문제를 가리킨다. 프록시는 같은 목적지로 향하는 다른 연결 또는 다른 목적지를 시도하는 편이 좋다. 방금 오류를 낸 연결에 원래 요청을 다시 보내는 것은 금지된다. 이 한 줄이 복구와 패킷 제조를 가른다. 죽은 길에 요청을 빨리 반복한다고 길이 살아나지는 않는다. 대체 경로의 순서, 재시도 횟수, 시간 한도는 운영자가 따로 정해야 한다.

다른 원인값은 대체로 홈 서버에서 왔다고 해석한다. 프록시는 원인을 실은 새로운 Protocol-Error를 자기 고객에게 보낸다. 받은 패킷을 중계하는 일과는 다르다. 프록시가 하위 결과를 읽고 상위에 새 보고를 남기는 행위다. 좋은 장애 기록은 처음 요청, 다음 서버의 오류, 프록시의 선택, 접속 장비의 최종 응답을 연결한다. 처리 실패를 알리는 패킷 하나로 사용자의 인증 성공이나 회계 기록 완료를 확정할 수는 없다.

이전 장비와의 전환, 협상, 오류 응답 선택에 관한 초안 부분에는 아직 TBD가 남아 있다. 공식 자료에는 두 프록시를 지나는 실제 배포 추적도 없다. 통제된 시험에서 요청 종류와 Identifier, 받은 원인, 포기한 연결, 새 경로와 접속 장비의 최종 동작을 함께 기록하면 제안된 책임 배분이 구현에서도 지켜지는지 확인할 수 있다.

RADEXT 초안 · Datatracker 상태 · RFC 7930 · IANA 등록부