TCP는 되지만 UDP는 같은 포트에서 다른 서버에 도달한다

한 프로필이 TCP에서는 동작하고 UDP에서는 인증서 경고와 함께 실패합니다. 직관적인 해석은 UDP 경로가 신뢰를 깨뜨렸다는 것이고, 직관적인 수정은 인증서를 받아들이는 것입니다. 두 가정 모두 증상을 완전히 설명하는 한 가지 가능성을 건너뜁니다: 두 전송이 서로 다른 장비에 도달한 것입니다. 전달 규칙은 프로토콜별로 대응되며, 한 포트 번호의 TCP와 UDP 절반을 같은 호스트로 향하게 강제하는 것은 없습니다.

하나의 포트 번호, 두 개의 독립 규칙

전달은 프로토콜, 목적지 주소, 포트를 키로 하는 표 조회입니다. TCP 1194에 대한 규칙과 UDP 1194에 대한 규칙을 가진 게이트웨이는 두 개의 독립적인 결정을 표현하며, 그것들은 서로 다른 내부 호스트를 가리킬 수 있습니다. 공유된 번호는 사람을 위한 편의이며 네트워크가 강제하는 속성이 아닙니다. 포트 번호를 서비스 정의가 아니라 이름표로 다루십시오.

의도한 규칙이 아니라 실제로 적용되는 규칙을 보십시오. 목적지 주소, 변환된 포트, 인그레스 인터페이스가 모두 관여하며, 이전 이전 작업에서 남은 규칙이 두 절반이 어긋나는 흔한 이유입니다.

다른 무엇을 바꾸기 전에 두 매핑을 적어 두십시오. 그 두 줄이 가설의 전부입니다.

클라이언트가 실제로 검증한 것

핸드셰이크 동안 클라이언트는 설정된 신뢰와 기대하는 이름에 대해 인증서를 검사합니다. 예기치 않은 인증서는 신원 검사에서 떨어진 성공적인 검증이며, 상대가 도달하려던 곳이 아닐 때 그것이 올바른 결과입니다. 그것을 거부하는 것은 클라이언트가 동작한다는 증거이고, 전송이 고장 났다는 증거가 아닙니다. 보고된 이름을 보고된 체인보다 먼저 읽으십시오: 클라이언트가 비교한 것은 이름이기 때문입니다.

이 구분이 중요한 이유는 두 실패가 서로 다른 수정으로 이어지기 때문입니다. 신뢰 문제에는 신뢰 수정이 필요하고, 예기치 않은 상대에는 라우팅이나 전달 수정이 필요합니다.

클라이언트가 어떤 신원을 보고했는지 적어 두십시오. 그 이름이 어느 장비가 응답했는지에 대한 가장 강한 단서입니다.

시도를 서버와 대조하기

프로필, 공인 주소, 전송, 클라이언트가 사용한 포트를 기록하십시오. 그다음 시도 시각을 도달하려던 서버의 로그와 맞춰 보십시오. 그곳에 없음은 단서이며 방화벽이 버렸다는 증거가 아닙니다: 배포마다 로그 수준이 다르기 때문입니다. 타임스탬프와 출발지 주소를 함께 쓰면 둘 중 하나만 쓸 때보다 범위가 좁아집니다.

마주친 인증서 신원을 관리 채널을 통해 기대 신원과 비교하십시오. 채널 밖에서 비교하는 것이 이 검사를 신뢰할 수 있게 유지합니다.

두 전송이 같은 백엔드를 공유한다고 결론 내리기 전에 오래된 전달 규칙, 대체 리스너, 부하 분산 경로를 확인하십시오. 그중 어느 것이든 다른 전송을 건드리지 않고 흐름을 돌릴 수 있습니다.

잘못된 상대에 맞춰 신뢰를 고치지 말 것

예기치 않은 CA를 가져오면 증상이 사라지고 클라이언트가 누구를 신뢰하는지가 바뀝니다. 이것은 연결 실패보다 나쁜 상태입니다: 불일치를 해결하는 대신 숨기기 때문입니다. 터널이 올라오는지만 보려고 검증을 끄는 것도 마찬가지입니다.

상대가 정당하지만 의도하지 않은 것으로 밝혀지면 올바른 조치는 그것을 퇴역시키거나 규칙을 올바른 호스트로 향하게 하는 것입니다. 신뢰 저장소는 재고 오류를 맞추는 곳이 아닙니다.

거부 문구를 보관하십시오. 클라이언트가 본 것에 대한 유일한 기록입니다.

수정 후 새 흐름을 시험할 것

매핑을 고친 다음 새 클라이언트 세션으로 연결하십시오. 상태 기반 변환은 기존 흐름을 옛 목적지로 향한 채 둘 수 있어, 이미 맺어진 연결이 변경을 견뎌내고 판단을 흐릴 수 있습니다. 새로 시작하고 의도한 서버의 로그에서 그 시도를 처리했는지 확인하십시오.

두 전송이 같은 서버에 도달함이 입증되었는데도 동작이 다르다면, 남은 차이는 그 서버 자체의 리스너와 구성입니다. 전송 비교는 엔드포인트 신원이 확정된 뒤에야 의미가 있습니다.