VPN은 연결되지만 LAN 장치에 도달하지 못함: 무엇을 확인할까

트래픽은 터널로 들어가고, 게이트웨이는 자기 주소에 응답하며, 그 뒤의 무엇도 응답하지 않는다. 이 패턴은 흔하며 모순이 아니지만, 게이트웨이의 응답은 터널이 종료되었음을 증명해도 그 너머로 주소 지정된 패킷에 무슨 일이 일어나는지는 아무것도 증명하지 않는다. 두 테스트는 같은 머신에서 서로 다른 코드 경로를 사용한다.

이제부터는 게이트웨이 반대편에서 무언가를 테스트하라. 포워딩이 아무리 망가져도 게이트웨이 자체 주소는 계속 응답할 것이다.

게이트웨이는 자기 스택에서 응답한다

게이트웨이로 주소 지정된 패킷은 로컬 입력 경로로 전달되며, 커널은 대기 중인 소켓이 이를 받아들일지 결정한다. 게이트웨이 뒤의 호스트로 주소 지정된 패킷은 대신 포워딩 경로로 전달되며, 여기에는 다른 검사 집합이 적용된다. 포워딩은 완전히 비활성화될 수 있고, 커널이 활성화한 뒤 터널을 전혀 언급하지 않는 필터 규칙이 이를 거부할 수도 있다. 그중 어느 것도 게이트웨이 자체의 응답에는 영향을 주지 않으며, 그래서 이 증상은 그렇게 확실하게 오도한다.

터널을 통해 도달하는 관리 페이지도 첫 번째 범주에 속한다. 그것은 터널에 대한 증거이지, 그 뒤의 네트워크에 대한 증거가 아니다.

흐름을 처음으로 떨어뜨리는 경계까지 따라가라

클라이언트에서 시작해 흐름이 사용할 경로와 출발지 주소를 확인하라. 그다음 게이트웨이에서 바로 그 흐름이 도착하는지, 그리고 같은 흐름이 LAN 쪽으로 떠나는지를 관찰하라. 결코 도착하지 않으면 문제는 클라이언트 쪽이나 터널의 허용된 프리픽스에 있다. 도착하지만 결코 떠나지 않으면 문제는 포워딩이나 전방 경로 필터에 있으며, 캡처가 이미 어느 쪽인지 말해 주었다.

같은 테스트를 게이트웨이에서 실행하면 게이트웨이에서 발생한 패킷은 출발지도 반환 요구도 달라 흥미로운 절반이 가려진다. 각 단계에서 클라이언트의 흐름을 그 자체의 출발지 주소와 함께 사용하라. 잘못된 인터페이스에서 찍은 캡처는 자신감 있는 헛소리를 낳는다.

반환 경로와 호스트 방화벽은 따로 실패한다

패킷이 호스트에 도달한 뒤에는 세 가지가 더 성립해야 한다. 서비스가 패킷이 전송된 주소에서 대기하고 있어야 하고, 호스트 방화벽이 이를 받아들여야 하며, 응답은 클라이언트 풀 쪽으로 돌아가는 경로를 가져야 한다. 마지막 것이 자주 실패하는데, 호스트의 기본 경로가 터널 범위에 대해 들어 본 적 없는 라우터를 가리키기 때문이다. 결과는 호스트 관점에서 성립하고 반대 방향에서는 조용히 죽는 연결이다.

클라이언트에서 보내고 반환을 관찰해 반환 경로를 의도적으로 테스트하라. 단방향 캡처는 한 시간의 추측이 해결하지 못할 것을 몇 초에 해결한다.

클라이언트의 출발지 주소로 각 홉을 확인하라

가치는 어느 한 줄이 아니라 비교에 있으므로 검사를 순서대로 실행하고 모든 출력을 보관하라. 아래 명령은 출발지 주소를 고정하고, 선택된 경로를 보여 주며, 포워딩의 양쪽을 캡처한다. 자신의 LAN 호스트와 터널 인터페이스로 바꿔라.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

경로 질의는 클라이언트가 그 패킷을 애초에 터널로 보낼지를 보여 주고, ping은 호스트에서 무언가 돌아왔는지를 보여 준다. 두 캡처를 비교하면, 터널 인터페이스의 프레임에 LAN 인터페이스의 대응물이 없을 때 그것이 서비스 장애가 아니라 포워딩 결정임이 드러나며 도착과 출발이 분리된다. 두 캡처가 요청을 보여 주고 하나만 응답을 보여 준다면, 남은 용의자는 반환 경로다.

어느 주소가 응답했고 어느 전달된 목적지가 실패했는지 기록하라. 그 문장이 서버에 도달할 수 없다는 주장 대신 실행 가능한 보고서로 만든다.