라우팅된 VPN 클라이언트는 서버에 닿지만 LAN 호스트에는 닿지 않습니다

터널이 올라오고 클라이언트가 VPN 서버에 핑을 보내지만, 한 홉 떨어진 머신의 공유 폴더는 결코 응답하지 않습니다. 요청은 실제로 클라이언트를 떠났고 실제로 도착했기 때문에 클라이언트 구성에는 이를 설명할 것이 없습니다. 실패한 것은 돌아오는 길이며, 실패한 장치는 보통 VPN 호스트가 아니라 LAN 게이트웨이입니다. 응답 패킷을 추적하면 이 증상 부류 전체가 설명됩니다.

요청이 아니라 응답을 따라가세요

VPN 서버는 클라이언트 패킷을 복호화하고 소스 필드에 클라이언트 주소를 그대로 둔 채 LAN으로 전달합니다. 목적지 호스트가 그 주소로 응답하고, 이제 자신의 라우팅 테이블이 모든 것을 결정합니다. 기본 게이트웨이는 터널 풀에 대해 아무것도 모르므로 응답은 인터넷 제공업체 쪽으로 나가 그 경로 어딘가에서 버려집니다.

클라이언트에서는 증상이 거부도 재설정도 없이 그저 아무것도 없는 조용한 시간 초과입니다. 공유 폴더 탐색이 멈추고 핑은 응답이 없다고 보고하며, 서버는 할 일을 다 했으므로 로그는 정상으로 보입니다.

반환 경로를 호스트가 바라보는 곳에 두세요

모든 LAN 호스트는 자신의 기본 게이트웨이에 물어보므로, 터널 풀이 어디에 있는지 알아야 하는 유일한 장치가 게이트웨이입니다. 거기에 정적 경로를 추가하면 각 호스트는 손대지 않고도 올바른 경로를 물려받습니다.

게이트웨이가 자신의 주소를 DHCP 옵션으로 배포한다면 같은 방식으로 경로를 배포해 새 머신이 자동으로 받아들이게 하세요. 그렇지 않으면 경로는 구성 파일 하나에 머물고 다음 재구성에서 사라집니다.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

소스 NAT가 고치는 것처럼 보이는 이유

클라이언트 풀을 VPN 서버 주소 뒤로 마스커레이드하면 패킷에서 클라이언트 주소를 없애 문제를 없앱니다. 그러면 응답이 터널에 도달하는 방법을 이미 아는 서버로 돌아오고 모든 것이 작동합니다. 대가는 내부 호스트가 클라이언트가 누구인지 더는 볼 수 없고 모든 연결이 한 머신에서 나온 것처럼 보인다는 점입니다.

그 맞바꿈은 예를 들어 공급업체 장비에 정적 경로를 줄 수 없을 때처럼 때로는 옳습니다. 규칙은 /24용으로 쓴 규칙이 풀이 /16으로 다시 번호가 매겨지는 날 더는 맞지 않게 되고 첫 징후가 연결은 되지만 아무것에도 닿지 못하는 새 클라이언트 무리이기 때문에 현재 풀보다 넓게 만들지 마세요.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

클라우드 경로에는 세 가지 설정이 필요합니다

VPC에서는 서브넷에 클라이언트 범위로 가는 경로가 아예 없기 때문에 같은 빈틈이 다른 모양으로 돌아옵니다. 라우팅 테이블에는 터널 풀을 인스턴스의 네트워크 인터페이스로 보내는 항목이 필요하고, 그 인터페이스는 플랫폼이 자신의 주소가 아닌 출발지를 가진 패킷을 받아들일 수 있도록 소스 및 대상 확인이 꺼져 있어야 합니다. 보안 그룹과 네트워크 ACL도 양방향으로 풀을 허용해야 합니다.

각 누락은 서로 다른 부분 실패를 만듭니다. 라우팅 테이블 항목을 빼면 프라이빗 인스턴스는 응답을 풀로 되돌려 보낼 수 없는 서브넷으로 응답합니다. 확인이 켜져 있으면 플랫폼은 인스턴스가 이미 보낸 응답을 버립니다. 보안 그룹 규칙이 없으면 요청 자체가 도착하지 않고, 클라이언트는 한 계층 앞에서 시간 초과를 봅니다.

확인은 이 순서로 실행하세요

라우팅을 탓하기 전에, 전달하지 않는 호스트도 같은 조용한 방식으로 실패하므로 전달과 필터 정책을 확인하세요. 그다음 엄격한 필터는 예상치 못한 방향에서 오는 응답을 버릴 수 있으므로, 터널을 나르는 인터페이스에서 유효한 역경로 설정을 읽으세요.

클라이언트가 LAN 호스트에 핑을 보내는 동안 그 호스트에서 캡처한 것으로 마무리하세요. 대응하는 응답 없이 도착하는 요청은 반환 경로를 증명하고, 결코 도착하지 않는 요청은 결함을 서버나 터널로 되돌립니다.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

소스 및 대상 확인은 탄력적 네트워크 인터페이스 안내서에문서화되어 있습니다. 터널 트래픽을 실제로 나르는 인터페이스에 설정하고, 같은 인스턴스에 연결된 무관한 어댑터에는 설정하지 마세요.