초록 아이콘, 같은 공인 IP: VPN이 건너뛴 경로
트레이 아이콘은 터널을 알려 줄 뿐 기본 경로를 뜻하지 않는다. 네 번의 조회로 클라이언트가 경로를 설치했는지, 아니면 출구가 소스를 변환하지 않았는지 알 수 있다.
연결됐고 트레이 아이콘이 초록색이며 주소를 되돌려 주는 페이지가 여전히 공급자 주소를 보여 준다고 해서 자동으로 고장은 아니다. 클라이언트는 터널을 만들고 라우팅 테이블을 고치는 두 가지 별개의 일을 한다. 어느 쪽이든 다른 쪽 없이 일어날 수 있고, 선택적 라우팅은 두 번째를 일부러 건너뛰는 구성이다.
클라이언트가 실제로 설치한 것
터널이 올라와 있는지 묻는 대신 실제 목적지까지 패킷을 어느 인터페이스가 실어 나를지 물어라. 그 목적지로 가는 경로가 없는 터널은 아무도 다니지 않는 사유 도로다.
ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4첫 명령은 Linux와 macOS에서 답하고, 나머지 둘은 Windows의 등가물이며 하나면 충분하다. 답이 물리 어댑터를 지목하면 터널은 올라와 있고 기본 경로는 한 번도 움직이지 않았다. 터널을 써야 할 목적지로 조회를 다시 하면, 멀리 있는 목적지와 평범한 목적지에 대한 두 번의 조회가 어떤 설계가 배포됐는지 알려 준다.
선택적 라우팅의 세 가지 형태
전체 터널 프로필은 보통 인터페이스를 가리키는 기본 경로를 쓰거나, 접두사 길이에서 이기는 절반 범위 접두사 쌍을 쓰고 원래 기본 경로는 테이블에 남는다. 선택적 라우팅은 다른 선택이며 여러 형태가 있다. 한 프로필은 RDP 서버 같은 단일 호스트를 라우팅하고, 다른 하나는 특정 위치에서 도달해야 하는 공인 대역을 라우팅하며, 세 번째는 한 애플리케이션을 일부러 제외한다. 셋 다 정당하고, 어느 것도 일반 웹사이트가 보는 주소를 바꾸지 않는다.
grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20결정하는 지시자를 프로필에서 읽고, 그다음 그것이 만들어 낸 것을 테이블에서 읽어라. 밀어 넣은 지시자는 클라이언트에서 억제될 수도 있으므로 서버를 탓하기 전에 프로필과 테이블이 일치해야 한다.
반대편은 출발지 주소를 다시 써야 한다
브라우저에서는 똑같아 보이는 두 번째 고장이 있다. 경로는 터널 안으로 향하고, 서버는 패킷을 받은 다음 클라이언트의 사설 주소를 그대로 둔 채 전달한다. 다음 홉에는 그 주소로 돌아갈 길이 없어 응답이 사라지고 페이지가 멈춘다. 서버는 아예 전달을 해야 하고, 출발지를 인터넷이 되돌려 라우팅할 수 있는 무언가로 변환해야 한다.
sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE실제로 인터넷을 향하는 인터페이스를 지목하되, 최신 배포판에서 그것이 항상 eth0은 아니다. 고정 주소를 가진 호스팅 서버는 masquerade 대신 그 주소로 명시적으로 변환할 수 있다. 두 절반이 모두 중요하니, 변환 없는 전달은 라우팅할 수 없는 출발지를 흘리고 전달 없는 변환은 패킷을 영영 보지 못한다.
이름 해석은 자기 길을 간다
이름을 찾은 조회가 로컬 네트워크의 리졸버로 간 동안 트래픽만 터널로 나갈 수 있다. 보이는 주소는 같지만 질의는 다르고, 그 틈이 바로 분할 DNS 설계가 택하는 것이다.
resolvectl status | head -20
resolvectl query example.org어느 서버가 답했는지, 터널 이전 기준선과 다른지 살펴라. 분할 터널에서 이것은 보통 사람들이 주소를 두고 불평할 때 바꾸고 싶어 했던 설정이고, 그들이 한 번도 보지 않은 설정이기도 하다.
문제를 정리하는 네 가지 관찰
터널을 내린 상태와 올린 상태에서 출구 주소를 기록하라. 두 상태 모두에서 목적지 조회를 실행하고 매번 인터페이스를 적어 두라.
curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9조회가 터널 안으로 들어갔는데도 응답이 공급자 주소를 보여 준다면 출구의 변환이 빠진 것이다. 조회가 물리 어댑터로 떨어진다면 프로필이 선택적이고 공인 주소는 처음부터 범위 밖이었다. 믿을 수 있는 응답 서비스로 바꾸고 네 가지 관찰을 함께 기록하라. 따로 보면 일화에 지나지 않지만 함께 보면 클라이언트가 두 일 중 무엇을 실제로 했는지 드러난다.