VPN 클라이언트가 서버에는 닿지만 LAN에는 닿지 않는다: 어떤 수정인가

클라이언트가 OpenVPN 서버의 터널 주소로 ping을 보내 응답을 받지만, 이어서 서버 LAN의 호스트를 시험하면 아무것도 돌아오지 않는다. 이 분할로 문제 범위가 크게 좁혀지며, 터널은 올라와 있고 전달은 아마 동작하고 응답은 되돌아오지 않는 문으로 나가고 있다. 수정은 세 가지이고, 어느 것이 맞는지는 무엇을 통제할 수 있고 무엇을 포기할 수 있는지에 달려 있다. 아래 세 질문에 순서대로 답하면 선택은 더 이상 취향 문제가 아니다.

먼저 어느 방향이 끊겼는지 확인한다

요청은 VPN 풀에서 온 원본 주소를 달고 터널 인터페이스에 도착한다. 서버는 그것을 LAN 호스트로 전달하고, 그 호스트는 자기 표가 지정한 게이트웨이, 보통 LAN 라우터로 응답한다. 라우터에 풀으로 가는 경로가 없으면 응답은 거기서 죽거나 인터넷 쪽으로 헤맨다.

둘 중 하나를 고치기 전에 두 기계를 모두 시험한다. 서버에서 경로 표가 클라이언트에 어떻게 닿을지 묻고, LAN 호스트에서 같은 주소에 어떻게 닿을지 묻는다. 첫 조회는 대개 터널을, 두 번째는 LAN 라우터를 가리키며 그 차이가 한 줄짜리 결함이다. 두 번의 조회는 방화벽 감사보다 싸고 문제의 방향을 확정한다.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN 호스트가 이미 VPN 서버를 가리키고 있다면 문제는 방화벽 규칙이나 MTU 한도이지 돌아오는 경로의 부재가 아니다. 필터를 고치려고 경로를 추가하지 마라.

질문 하나: 원격 LAN의 라우터를 편집할 수 있는가?

LAN 라우터가 내 것이라면 VPN 풀에 대한 정적 경로를 만들고 다음 홉에 VPN 서버의 LAN 주소를 두는 것이 깔끔한 답이다. 클라이언트의 원본 주소가 그대로 유지되므로 LAN 호스트가 주소 단위로 기록·필터·속도 제한을 할 때 유리하다. 서버에서 주소 변환도 필요 없어 터널은 순수한 경로로 남는다. 대신 생기는 의무는 문서화이며, 풀과 경로와 서버 설정이 서로 맞아야 한다.

누군가 풀을 바꾸는 날 그것은 조용히 실패한다. 값을 한 번 적어 두고, 세 곳 중 어디를 고치든 세 곳을 함께 고치는 것으로 본다.

서비스를 호스팅하는 NAS나 레이어 3 스위치도 같은 경로가 필요하다(그 경로를 가진 라우터로 모든 것을 보내지 않는 한은). 인터넷을 향한 장비만 보지 말고 서브넷을 종단하는 장비를 확인하라. 작은 네트워크에는 라우팅에 대해 의견이 있는 장비가 셋 있는 경우가 흔하다.

질문 둘: LAN이 클라이언트 주소를 더 이상 보지 않아도 되는가?

라우터가 남의 것이라면 VPN 서버에서 변환하는 데 상대의 협력이 필요 없다. LAN 호스트는 서버의 LAN 주소를 보고 그리로 응답하며 서버가 다시 변환한다. 어플라이언스와 NAT 기반 원격 접속 역할이 그렇게 동작하는 이유다.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

대가는 귀속성이며, 클라이언트별 주소가 LAN 로그에서 사라진다. 그러면 LAN 호스트의 허용 목록은 풀이 아니라 서버를 지목해야 한다.

협력이 불가능할 때 변환을 고르고, 단지 불편할 때 고르지 마라. 변환은 클라이언트를 앞으로의 모든 조사에서 숨기며, 어느 노트북이 연결을 열었는지 알아야 하는 조사에서도 숨긴다. 주소를 페이로드에 넣는 프로토콜도 깨뜨릴 수 있다(변환은 헤더에서 일어난다). 어느 쪽이 더 앞선 것도 아니고, 둘은 소유권에 관한 서로 다른 질문에 답한다.

질문 셋: 서버 자신이 다른 터널의 클라이언트인가?

다른 구성을 그려 보라(VPN 서버가 상용 사업자에도 접속해서 터널이 둘, 주소도 두 벌인 경우다). 자기 클라이언트를 위해 전달하는 트래픽은 사업자를 통해 나가고, 사업자는 응답을 풀 주소로 되돌려 라우팅하지 않는다. 두 터널이 모두 건강한데 응답이 사라지는 이유다.

수정은 나가는 터널에도 마스커레이드를 거는 것이며, 사업자는 서버의 터널 주소만 보게 된다. 반대 방향에는 자체 규칙이 필요하다(서버가 자기 클라이언트로 연결을 시작하는 것은 다른 흐름이다). 그 규칙이 없으면 클라이언트는 라우팅할 수 없는 주소로 응답한다. 좁은 규칙을 넓은 마스커레이드보다 앞에 두어 구체적인 변환이 이기게 하라.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

여러 인터페이스를 가진 호스트는 클라이언트 쪽에서 똑같이 보이는 관련 장애를 더한다. 원본 주소가 다른 표에서 선택되었기 때문에 응답이 메트릭이 낮은 인터페이스로 나간다. 되돌아오는 경로를 조회로 확인하고, 가는 경로가 그것을 함축한다고 가정하지 마라.

이어서 양방향과 두 크기를 검증한다

변경 후 클라이언트에서 LAN 호스트로 ping하고, 다시 LAN 호스트에서 클라이언트로 ping한다. 두 번째 방향이 사람들이 건너뛰는 쪽이며 불완전한 변환 규칙을 드러내는 쪽이다. 두 결과를 시각과 함께 기록해 두면 나중의 회귀를 비교할 수 있다.

그다음 실제 데이터를 옮긴다(작은 ping은 통하는데 큰 전송이 멈추는 것은 MTU의 증상이다). 그 장애는 경로를 고쳤다고 스스로 칭찬한 직후에 나타난다.

마지막으로 재부팅 후 다시 시험한다. 실행 중에 넣은 경로와 방화벽 명령은 재부팅을 넘지 못하므로, 다음 부팅에서 사라지는 수정은 맥락이 적은 누군가가 다시 진단하게 된다. 변경을 시스템이 이미 쓰는 방식으로 영구화한 뒤 일부러 한 번 재부팅하라.