라우팅된 OpenVPN 터널에서 이름 조회가 실패하는 이유

호스트가 주소로는 ping에 응답하지만 이름으로 하는 모든 조회에서 실패한다. 터널은 올라와 있고 경로도 있으므로 VPN 설정이 잘못됐다는 결론이 자연스럽다. 더 쓸모 있는 결론은 그 조회가 애초에 라우팅 가능하지 않았다는 것이며, 라우팅된 터널은 유니캐스트 IP를 나르는데, 문제의 질의는 반대편에 없는 세그먼트를 찾는 브로드캐스트였다. 계층 불일치가 보이면 수리는 스스로 비용 순으로 정렬된다.

오해: 이름이 실패하니 터널이 고장 났다

증상이 설득력 있는 이유는 이름 계층 위의 모든 것이 동작하기 때문이다. 주소는 라우팅되고 인터페이스는 올라와 있으며 상대는 ping에 응답한다. 실패한 것은 점대점 링크를 건널 길이 한 번도 없었던 탐색 메커니즘이고, 이는 고장 난 터널과는 다른 진술이다. 이 두 진술을 분리하는 것이 진단의 대부분이다.

이를 터널 결함으로 다루면 도움이 될 수 없는 프로필 편집으로 이어진다. 옵션을 더하고 암호를 바꾸고 클라이언트를 다시 설치해도 브로드캐스트는 있던 자리에 그대로 남는다.

수리를 부르기 전에 실패한 메커니즘부터 부르라. 브로드캐스트를 쓰는 조회에는 세그먼트가 필요하고, 리졸버를 쓰는 조회에는 물어볼 주소가 필요하다.

TUN이 나르는 것과 나르지 않는 것

TUN 장치는 IP 인터페이스이며, 바로 그것이 라우팅 가능하게 만든다. OpenVPN은 클라이언트에 주소와 경로 집합을 주고, 그 뒤로 클라이언트는 데이터그램을 상대에게 보낸다. 그 모델에는 모든 호스트가 모든 프레임을 듣는 공유 링크를 만드는 요소가 없다.

탐색 트래픽은 그 모델에 전혀 맞지 않는다. 오래된 Windows 이름 질의, SSDP 공지, mDNS 요청은 하나의 목적지가 아니라 세그먼트의 모두에게 보내진다. 라우팅된 링크에는 보낼 «모두»가 없다. 그 메커니즘들은 모두 공유 매체를 전제한다.

따라서 터널이 건강해도 탐색은 완전히 실패할 수 있다. 누군가 VPN이 죽었다고 보고할 때 붙들어야 할 문장이 바로 이것이다.

브리징은 경계를 없애서 동작한다

TAP 장치는 프레임을 나르고, 브리지는 그것을 실제 LAN 세그먼트에 연결한다. 그러면 클라이언트는 그 세그먼트의 주소를 갖고 브로드캐스트 트래픽을 듣는다. 브리징이 이름 문제를 고치는 것처럼 보이는 이유가 그것이다. 또한 주소 지정을 그 세그먼트에 의존하게 만든다.

치료는 라우팅 경계의 제거이지 터널 안의 새로운 이름 능력이 아니다. 세그먼트가 브로드캐스트하는 모든 것이 이제 링크도 건넌다.

작은 실험실에는 공정한 맞바꿈이다. 분산된 인력에서는 좀처럼 그렇지 않다.

DNS와 WINS를 미는 것이 더 좁은 수리

클라이언트에게 물어볼 구체적인 곳을 주어라. dhcp-option DNS와 dhcp-option DOMAIN는 내부 이름을 존을 아는 서버로 보내고, 여전히 NetBIOS에 기대는 Windows 클라이언트도 같은 방식으로 WINS 서버를 받을 수 있다. 터널은 라우팅된 채로 남고 세그먼트는 제자리에 남는다.

두 조건이 그것이 되는지를 가른다. 지목한 서버가 존에 응답해야 하고, 질의가 터널을 통과하도록 허용되어야 한다.

리졸버는 서버 자체의 셸이 아니라 클라이언트에서 시험하라. 로컬에서 동작하는 리졸버는 터널이 무엇을 나르는지에 대해 아무것도 말해 주지 않는다.

어느 계층이 실패했는지 밝혀라

먼저 주소로 ping을 보내고, 다음에 이름을 해석해 어느 서버가 응답했는지 읽어라. 존을 호스팅하지 않는 서버의 부정 응답은 장비를 한 번도 떠나지 않은 질의와 다르게 보인다. 해석되지만 연결을 거부하는 이름은 전혀 다른 세 번째 문제다.

멀티캐스트도 같은 벽 뒤에 있다. 224.0.0.251 같은 그룹은 기본적으로 라우팅된 터널을 넘어 전달되지 않고, 멀티캐스트를 이해하는 경로나 LAN의 반사기가 없으면 그룹용 경로만으로는 충분하지 않다.