하나의 LAN 서브넷을 OpenVPN으로 라우팅하고 기본 경로를 유지하기

하나의 서브넷이 터널을 지나는 동안 LAN 기본 경로를 유지합니다. 정책 테이블과 메인 테이블 편집을 비교한 뒤 NAT 또는 서버 측 경로를 선택합니다.

LAN을 위해 라우팅하면서 동시에 VPN에 접속하는 장비는 자기 자신과 같은 논쟁에 빠집니다. 터널은 기본 경로를 차지하려 하고, LAN은 그것을 되찾아야 합니다. OpenVPN이 연결되면 터널을 통한 기본 경로나 한 쌍의 절반 기본 경로를 설치할 수 있는데, 이는 노트북에는 맞고 이웃이 LAN 주소에서 응답을 기대하는 게이트웨이에는 틀립니다. 답은 VPN을 건너뛰는 것이 아닙니다. 답은 두 결정에 서로 다른 테이블을 주는 것입니다.

하나의 기본 경로, 두 주인

전달되는 트래픽과 로컬에서 생성되는 트래픽이 같은 경로를 쓸 필요는 없습니다. LAN 클라이언트는 선택한 목적지에만 터널이 필요하고, 호스트 자체의 관리 세션과 그 클라이언트에 대한 응답에는 LAN 기본 경로가 필요합니다. 둘을 메인 테이블에 섞으면 서로 다른 두 질문에 하나의 답을 강요하게 됩니다.

OpenVPN에는 바로 이를 위한 스위치가 있습니다. route-noexec 클라이언트가 메인 테이블을 전혀 건드리지 않게 하고, 원래 사용했을 값은 route-up 스크립트로 route_vpn_gateway, dev 및 인터페이스 주소로 내보냅니다. 그다음 어떤 테이블이 어떤 경로를 받을지 나중에 읽을 수 있는 코드에서 결정합니다.

정책 테이블 대 메인 테이블 다시 쓰기

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

별도 테이블은 하나의 서브넷을 넘어 확장되는 유일한 선택입니다. 한 번 이름을 붙이고 나서는 이름으로 참조해 아무도 숫자를 외울 필요가 없게 하세요.

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

여기 주소는 자리 표시자입니다. 무엇이든 실행하기 전에 자신의 배포에서 LAN 접두사, 터널 게이트웨이, 장치 이름으로 바꾸세요.

규칙은 호스트와도 일치해야 합니다

LAN 접두사에만 일치하는 규칙은 전달되는 패킷을 다룹니다. 게이트웨이가 스스로 만드는 트래픽은 다루지 않고, LAN 클라이언트로 돌려보내는, 출발지로 게이트웨이의 LAN 주소를 가진 응답도 다루지 않습니다. 그 조회는 main으로 떨어지고 여전히 터널로 나갈 수 있습니다.

게이트웨이 자체의 LAN 주소에 대한 두 번째 규칙을 추가하거나, 첫 규칙을 둘 다 포함하는 집합으로 넓히세요. 순서가 중요합니다. 더 구체적인 규칙을 먼저 두고, 출발지를 명시하는 조회로 결과를 확인하세요.

ip route get 203.0.113.9 from 192.168.50.1

그것이 로컬에 남아야 할 목적지에 대해 터널 장치를 보고한다면, 테이블에 무엇이 들어 있든 규칙 집합이 틀린 것입니다.

NAT 또는 반대편 경로

VPN 서버는 터널 서브넷만 알고 그 밖에는 아무것도 모릅니다. LAN 출발지 주소로 도착한 패킷은 누군가 돌아갈 길을 마련하지 않으면 돌아갈 길이 없고, 그것을 마련하는 방법은 정확히 두 가지입니다. 서버에 LAN 접두사 경로를 추가하면 원래 출발지가 끝에서 끝까지 보이며, 감사된 설계가 보통 원하는 것이 이것입니다. 게이트웨이에서 마스커레이드하면 출발지를 터널 주소로 다시 쓰고 서버의 협력이 필요 없습니다.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

서버를 통제하지 못하고 거기에 경로를 추가할 수 없다면 NAT를 고르세요. 로그, 접근 제어, 반환 경로의 대칭성이 중요하다면 서버 측 경로를 고르세요. 마스커레이드는 반대편이 기록하는 모든 것에서 원래 주소를 지우기 때문입니다.

어느 쪽이든 전달이 켜져 있어야 하고, 엄격한 역경로 필터링은 main이 그 출발지에 터널을 선택하지 않았을 때 응답을 버릴 수 있습니다. 터널을 탓하기 전에 실제 값을 확인하세요.

재연결 후에도 분리가 유지되게 하기

손으로 추가한 규칙과 경로는 인터페이스가 다시 만들어지면 사라지고, 오래된 테이블 항목은 그것을 정당화한 세션보다 오래 살 수 있습니다. 테이블 규칙, 터널 경로, 마스커레이드 항목을 클라이언트의 route-up 스크립트 안에 넣고, 스크립트 맨 위에서 테이블을 비워 옛 게이트웨이가 새 세션으로 살아남지 못하게 하세요.

양쪽 끝에서 확인하세요. 게이트웨이에서 LAN 출발지로 조회하고, LAN 클라이언트에서 터널을 지나야 할 목적지로 실제 요청을 보냅니다. 존재하지만 절대 선택되지 않는 경로는 카운터를 읽기 전까지 경로가 전혀 없는 것과 똑같이 동작합니다.

관련 글