지리적 DNS와 애니캐스트: 받게 되는 VPN 진입점 점검

가까운 DNS 응답은 연결이 다른 곳에 착지하기 전까지는 해결된 문제처럼 느껴진다. 지리적 DNS와 애니캐스트는 둘 다 경로를 줄이려 하며, 그 결정을 서로 다른 정보로 내린다. 어느 쪽도 도달한 게이트웨이가 접근 가능한지, 클라이언트가 기대하는 정체성을 제시하는지, 세션이 노드 변경을 견디는지를 보장하지 않는다. 아래 점검은 그 네 가지 질문을 분리한다.

리졸버가 실제로 누구의 위치를 보고하는지 확인한다

토폴로지에 민감한 질의에 응답하는 권한 서버는 보통 질의한 재귀 리졸버의 주소를 보며, 이름을 입력한 사람의 주소를 보지 않는다. 중앙 집중 리졸버는 자신이 서비스하는 클라이언트에서 멀리 있을 수 있고, 응답은 그들이 아니라 리졸버를 반영한다. 이것은 결함이 아니며, 추가 정보가 주어지지 않는 한 프로토콜은 그렇게 동작한다.EDNS 클라이언트 서브넷 명세는 한계와 선택적 해결책을 모두 설명한다.

EDNS 클라이언트 서브넷은 모든 참여자가 지원하고 활성화할 때 출발 네트워크 정보를 실을 수 있다. 선택 사항이며 프라이버시와 캐시에 영향을 주고, 어떤 공용 리졸버든 사용자의 정확한 위치를 보고한다고 가정할 허가는 아니다. 그 위에 설계하기 전에 리졸버 운영자에게 물어보라.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

애니캐스트 라우팅이 무엇을 결정했는지 확인한다

애니캐스트에서는 여러 위치가 하나의 서비스 주소에 대한 도달 가능성을 광고하고, 네트워크는 각 클라이언트를 자신의 라우팅이 선호하는 노드로 전달한다. 그 선택은 지도상 거리가 아니라 BGP와 주변 정책이 한다. 토폴로지적 근접성도 짧아 보이는 경로가 혼잡하거나 비대칭일 수 있으므로 일반적으로 더 나은 왕복 성능을 뜻하지 않는다. 주어진 주소는 어느 노드가 응답했는지에 대해 아무것도 말해 주지 않는다.

서비스 위치는 DNS 응답만이 아니라 서비스 측에서 또는 그것을 지목하는 응답에서 확인한다. traceroute -n 198.51.100.20 은 지나온 경로를 보여 주지만 그 끝의 호스트는 여전히 지목하지 않으므로, 응답이 아니라 경로로 읽어야 한다.

세션이 노드 변경을 견디는지 확인한다

DNS 질의는 짧고 VPN 세션은 길며, 둘의 상태 요구는 전혀 다르다. 라우팅은 세션 중간에 옮겨갈 수 있고, 그렇게 되면 이후 패킷이 당신의 터널을 본 적 없는 노드에 도착할 수 있다. 그것이 견딜 만한지 여부는 구현에 달려 있는데, 공유 상태, 의도적인 재연결, 또는 문서화된 실패다. 주소만으로는 그중 어느 것도 제공하지 않는다.

옮겨가는 것을 가정하지 말고 관찰한다. sudo tcpdump -ni any -c 20 esp 는 경로가 바뀌는 동안 바깥 패킷을 보여 주며, 피어 주소의 갑작스러운 변화가 바로 그 이동이다. 실행하는 구현에 대해 의도한 동작을 명시하고, 경로 변경을 강제해 시험한다. 설계가 세션 복제를 가정한다면 그 메커니즘을 지목하고 그것이 덮지 못하는 실패를 지목한다.

정체성이 여전히 일치하는지 확인한다

모든 진입점은 클라이언트 프로필이 기대하는 정체성을 제시해야 한다. 서비스 이름으로 발급된 인증서는 모든 노드에서 동작하지만, 노드별 인증서는 클라이언트가 새로운 것을 받아들이도록 강제하며, 사용자가 경고를 넘겨 클릭하는 법을 배우는 곳이 바로 거기다. 기대하는 정체성과 프로필을 진입 모델과 일관되게 유지하라.

노드별 인증서가 드러나는 경우가 바로 그 경우이므로 특이한 노드에 도달한 클라이언트에서 확인한다. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com 는 체인과 이름을 인쇄하며, 클라이언트가 비교하는 것이 정확히 그것이다. 그다음 프로필을 좁힐지 인증서 모델을 바꿀지 결정한다.

첫 응답만이 아니라 기록을 확인한다

세 가지 시나리오를 평가하고 각각에 네 가지 사실을 적는다. 정상 진입, 한 위치 사용 불가, 그리고 합의된 복구 사례다. 네 가지 사실은 사용한 리졸버, 반환된 주소, 서비스한 위치, 새 애플리케이션 결과다. 그 기록이 DNS 선택 문제를 게이트웨이 문제, 라우팅 문제, 세션 상태 문제와 분리하므로, 그것이 없으면 넷은 클라이언트에서 똑같아 보인다.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

시나리오는 사무실에서만이 아니라 대표적인 접속 네트워크에서 실행한다. 질문 전체가 서로 다른 클라이언트가 실제로 어느 진입점에 도달하는지에 관한 것이므로, 네트워크 하나는 하나의 표본이다.