사이트 간 VPN이 한 방향으로만 작동합니다: 서로 다른 두 가지 장애

사이트 A는 B에 도달하지만 B는 A에 도달하지 못하고, 터널은 양방향 모두 정상으로 보입니다. 터널을 건드리기 전에 실제로 어떤 장애인지 결정하십시오. B에서 시작한 새 연결이 거부되는 경우와 A에서 시작한 연결에 대한 응답이 결코 돌아오지 않는 경우는 비슷한 불만을 낳지만 진단은 완전히 다릅니다. 하나는 경로상의 정책 또는 라우팅 문제이고, 다른 하나는 이미 허용된 트래픽의 반환 경로나 상태 문제입니다.

이 구분이 어떤 명령을 실행할 가치가 있는지 결정합니다.

똑같아 보이는 두 가지 장애

첫 번째 경우 B의 호스트가 A로 SYN을 보내지만 아무것도 돌아오지 않습니다. 두 번째 경우 A의 호스트가 세션을 성공적으로 열지만 응답이 돌아오는 길에 사라집니다. 두 사용자 모두 링크가 단방향이라고 말하고, 둘 다 사라진 패킷을 설명하므로 설명만으로는 둘을 구분할 수 없습니다.

실패한 시도를 어느 쪽이 시작했는지 물으십시오. 그 한 가지 사실만으로 가능한 원인의 절반이 제거됩니다.

그다음 테스트가 처음부터 끝까지 같은 호스트와 같은 서비스를 사용했는지 확인하십시오. 한쪽의 ping과 다른 쪽의 파일 공유 연결은 서로 다른 것을 시험하며, 게이트웨이에서 수행한 진단은 어떤 사용자 트래픽도 쓰지 않는 터널 주소를 고를 수 있습니다.

첫 번째 사례: 반환 경로가 없음

다른 기본 게이트웨이로 응답하는 원격 서버는 요청을 받고 응답을 다른 곳으로 라우팅할 수 있습니다. 그러면 상태를 추적하는 방화벽이 비대칭 응답을 버립니다 — 설정된 흐름과 맞지 않아 한 번도 작동하지 않은 방향처럼 보이기 때문입니다. 변환은 또 다른 형태를 더하는데, 목적지는 변환된 원본을 보고 그 주소로 응답하므로 원래 주소에 맞춰 작성된 규칙은 결코 일치하지 않습니다.

변환 후 목적지가 실제로 관찰하는 주소를 확인하고, 원래 서브넷이 아니라 그 주소에 대한 반환 경로를 확인하십시오.

두 번째 사례: 정책이 애초에 허용하지 않음

반대의 경우는 보기보다 단순하고 흔한데, 한 사무실은 중앙 서비스를 이용하기만 하고 중앙으로 연결을 시작하지 않도록 설계되었습니다. 그 비대칭은 의도된 접근 결정이며 터널은 설계대로 작동합니다. 터널 설정을 바꾸기 전에 접근 정책을 읽으십시오. 어느 방향이 의도되었는지는 패킷 캡처가 아니라 문서가 알려 줍니다. 캡처는 무슨 일이 있었는지만 보여 줄 뿐 무엇이 허용되었는지는 보여 주지 못합니다.

양방향 시작이 정말로 필요하다면 플랫폼이 지원하는 규칙 집합을 통해 해당 서비스의 권한을 추가하십시오. 애플리케이션 하나를 고치려고 모든 서브넷을 상호 신뢰로 만들면 좁은 요구가 넓은 권한으로 바뀌며, 그런 맞바꿈은 나중에 다시 검토되는 일이 드뭅니다.

같은 호스트에서 전후를 비교하십시오

두 개의 별도 시도가 아니라 같은 시도의 양 끝을 보십시오. 시작하는 호스트의 게이트웨이와 목적지에서 캡처한 뒤 무엇이 들어오고 무엇이 나갔으며 원격 측이 어떤 주소를 보았는지 비교하십시오.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

목적지의 캡처가 예상 밖의 원본 주소로 요청을 보여 준다면 답은 터널의 보안 정책이 아니라 변환이나 라우팅에 있습니다. 목적지에 요청이 전혀 보이지 않는다면 패킷은 보호 경로를 한 번도 지나지 않았습니다.

수정 후 같은 호스트에서 동일한 테스트를 반복하고 무관한 접근이 여전히 거부되는지 확인하십시오. “established” 터널 상태만으로는 두 결론 중 어느 것도 뒷받침하지 못합니다.