VPN 클라이언트 뒤의 서버가 터널을 통해 응답하는 이유

VPN 클라이언트도 실행하는 호스트로 들어오는 인바운드 연결은 아주 특정한 방식으로 실패합니다. 핸드셰이크는 도착하고 데몬은 응답하는데 클라이언트는 아무것도 받지 못합니다. 포트를 막는 것은 없습니다. 응답이 터널로 나갔기 때문입니다. 터널이 기본 경로를 소유하고 있고 커널은 응답을 목적지로 라우팅하지, 요청이 어디서 왔는지 기억으로 라우팅하지 않습니다. 데몬은 정상이고 포트는 열려 있습니다.

응답은 기억되는 것이 아니라 라우팅된다

기본 경로를 설치하는 VPN 클라이언트는 메트릭으로든, 공간을 더 구체적인 두 절반으로 나눔으로든 LAN 게이트웨이를 앞서는 항목을 추가합니다. 이제 나가는 패킷은 터널 인터페이스를 선택합니다. 커널은 응답 대상 패킷이 원래 어디서 도착했는지 결코 묻지 않습니다. 그 한 가지 누락이 뒤따르는 모든 증상을 설명합니다.

정방향은 목적지로 라우팅되고 역방향도 마찬가지입니다. 응답은 공인 클라이언트로 향하며 터널은 그것을 기꺼이 운반합니다. 먼 쪽은 자신이 소유하지 않은 출발지의 패킷을 받아 버리고, 원래 클라이언트는 시간이 다 될 때까지 기다립니다.

엄격한 역경로 필터링은 데몬이 읽기도 전에 인바운드 패킷을 버릴 수 있습니다. 먼저 그 카운터를 확인하세요. 필터로 인한 드롭과 라우팅 실수는 밖에서 보면 똑같기 때문입니다.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

첫 번째 명령은 지금 어떤 기본 경로가 이기는지 보여 줍니다. 두 번째는 엄격한 필터링이 전역인지 인터페이스별인지 알려 주고, 세 번째는 관련될 수 있는 포워드 체인의 규칙을 보여 줍니다.

반환 경로를 지키는 세 가지 방법

서비스 목적지를 터널에서 제외하는 것이 가장 좁은 선택입니다. LAN 게이트웨이를 향한 호스트 경로와, 모든 주소가 아니라 물리 주소에 묶인 데몬이 그 하나의 흐름을 터널 밖에 둡니다. 변경은 국지적이고 되돌리기 쉽습니다.

정책 라우팅이 일반적인 답입니다. 출발지 주소나 방화벽 표시를 키로 한 규칙이 기본이 WAN 게이트웨이를 가리키는 테이블을 선택하고, 호스트 자체의 연결은 계속 터널을 사용합니다. 우선순위를 명시해 두어 나중에 규칙이 가려지지 않게 하세요.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

처음 두 명령은 공인 주소에서 나온 응답을 위한 대체 경로를 만듭니다. 세 번째는 바로 그 출발지와 목적지가 어떤 경로를 택할지 커널에 묻는 것이며, 이렇게 규칙이 실제로 효과가 있는지 확인합니다.

소스 변환은 세 번째 선택지이며 서비스 앞에서 이미 NAT를 하는 라우터 앞에서 살아남는 유일한 방법입니다. 응답은 그 라우터로 돌아가야 하고, WAN 인터페이스로의 마스커레이딩이 이를 달성하면서 클라이언트를 서비스 로그에서 숨깁니다. 연결 후 기본 경로를 손으로 바꾸는 것은 진단입니다. 클라이언트가 다음 재연결에서 테이블을 다시 쓰기 때문입니다.

그 상자가 LAN을 위해서도 라우팅할 때

같은 고장은 호스트가 뒤의 장치를 위해 라우팅할 때 한 홉 더 멀리서 나타납니다. 인바운드 연결은 반환 경로가 터널뿐인 내부 장치로 전달되고, 응답은 공급자 주소에서 외부 클라이언트에 도달합니다. 내부 장치는 내내 제대로 동작하고 있습니다.

그러면 연결 추적은 기록한 적 없는 흐름에 대한 응답을 보고 버립니다. 목적지 변환은 인바운드 연결을 장치에 전달하고, 소스 변환은 응답이 라우터 자체에서 나온 것처럼 보이게 합니다.

전달된 포트를 WAN에 두면서 라우터 자체 트래픽은 터널을 쓰는 정책 경로가 더 깔끔한 등가물입니다. 소스 변환이 없으면 응답은 외부 클라이언트로 향하고, 내부 장치는 그 주소에 대한 경로가 전혀 없습니다.

원인을 가르는 세 가지 점검

세 가지 점검을 수행하세요. 인터넷에서 상자로의 연결, 상자에서 공인 호스트로의 연결, 이름 조회입니다. 처음 두 가지가 어긋나면 반환 경로가 원인입니다. 이름이 양방향으로 실패하면 리졸버가 터널만 공유하는 다른 고장입니다.

먼저 라우팅 문제를 고치고, 그다음 이름을 보세요. 둘을 섞는 것이 동작하는 서버를 고장 난 리졸버 탓으로 돌리는 길입니다.

예외가 어떤 인터페이스를 지목하는지 기록하고 구성을 버전 관리 아래에 두세요. 업그레이드 후 이름이 바뀌는 인터페이스에 대해 쓴 규칙은 오늘은 통과하고 다음 재부팅 후 실패합니다.