LAN 라우터와 VPN 클라이언트: 두 장치, 두 개의 라우팅 테이블

두 장치가 패킷을 전달하며 각자 자신의 테이블을 유지합니다. LAN 라우터는 원격 프리픽스가 VPN 클라이언트에 속한다는 것을 알고, VPN 클라이언트는 자신의 터널을 통해 그 프리픽스에 도달하는 방법을 압니다. 첫 번째 테이블만 구성하면 패킷은 일치하는 경로가 없는 머신에 도착하므로 기본 경로로 다시 나갑니다. 이것이 전체 고장이며, LAN 쪽에서는 라우팅 루프처럼 보입니다. 거의 그렇기 때문입니다.

경로를 건드리기 전에 두 홉을 그려 보세요

예시 구성을 하나 잡으세요. LAN 호스트는192.168.50.0/24, 일반 라우터는192.168.50.1, 전용 클라이언트는192.168.50.15, 그리고 원격 LAN은10.60.0.0/24에 있으며 그 클라이언트가 가진 터널로만 도달할 수 있습니다. 두 사설 범위는 서로 겹치지 않습니다. 터널에는 자체 주소 계획이 있습니다.

두 사설 범위가 모두 중요합니다. 어느 장치가 응답할 수 있는지를 결정하기 때문입니다. 원격 측은 패킷이 클라이언트의 터널 주소에서 오는 것을 보게 되고, 그 응답은192.168.50.0/24로 돌아갈 길을 찾아야 합니다. 나가는 방향만 구성하면 요청은 작동하지만 응답은 사라집니다.

1단계: 라우터를 터널이 아니라 클라이언트 쪽으로 향하게 하세요

LAN 라우터에서 다음 홉이 클라이언트의 LAN 주소인 목적지 경로를 추가하세요:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

그 레코드는 “터널을 만들 수 있는 머신으로 전달하라”고 말합니다. 터널이 어떻게 만들어지는지는 말하지 않으며, 클라이언트 자체의 경로를 대신하지도 않습니다. 관리형 라우터에서는 같은 역할이 장치의 정적 경로 페이지에 있고, Linux 라우터에서는 LAN을 소유한 인터페이스 구성에 속합니다. 닫아 버릴 셸에 넣는 것이 아닙니다.

두 번째 명령의 답을 확인하세요. 클라이언트를 gateway로, LAN 인터페이스를 device로 보고하면 첫 홉은 맞고 남은 작업은 다른 머신에 있습니다.

2단계: 클라이언트에 터널 쪽 자신의 경로를 주세요

이제 클라이언트는10.60.0.0/24에 대한 패킷을 받고 자신의 테이블을 확인합니다. 터널 구성이 그 프리픽스에 대한 경로를 설치했다면 패킷은 암호화된 채로 계속됩니다. 설치하지 않았다면 패킷은 일반 기본 경로와 일치해192.168.50.1로 돌아가고, 그곳이 다시 클라이언트로 보냅니다.

무언가를 추가하기 전에 보세요:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

모든 테이블에 프리픽스 경로가 없다는 것이 바로 찾고 있는 발견입니다. 터널 자체의 구성으로 추가해 다음 재연결에서 다시 설치되게 하세요. 수동ip route add는 세션과 함께 사라져 가장 불편한 시점에 고장이 돌아옵니다. 다음 홉은 터널 인터페이스이거나 VPN이 피어로 할당하는 주소이며 클라이언트에 따라 다르고, 피어 주소는 오래된 메모가 아니라 현재 프로필에서 와야 합니다.

루프는 실제로는 무한하지 않습니다. 지날 때마다 TTL이 줄고 패킷은 시간 초과 메시지와 함께 죽습니다. 그래서 반복 traceroute가 순환을 암시할 수 있지만, 단지 전달하지 않는 클라이언트는 같은 패킷을 조용히 버립니다.

3단계: 포워딩을 허용하고 반환 경로를 고르세요

받는 것과 전달하는 것은 다른 권한입니다. 클라이언트의net.ipv4.ip_forward=1는 커널 수준에서 통과를 허용하지만, 방화벽 규칙이 LAN 인터페이스와 터널 사이에서 그것을 여전히 허용해야 합니다. 클라이언트 자체의 관리 페이지 접근을 허용하는 규칙은 원격 LAN으로의 통과를 허용하지 않으며, 같은 호스트가 로컬에서 ping에 응답할 때 이 차이를 놓치기 쉽습니다.

원격 측에는 거울 문제가 있습니다.192.168.50.0/24이 이 인증된 클라이언트를 통해 도달 가능하다는 것을 알아야 합니다. OpenVPN 사용 시 보통 서버 구성이 밀어주는 클라이언트별 경로, 또는 서버에서 클라이언트 뒤의 LAN을 선언하는 클라이언트 전용 파일을 뜻합니다. 그것이 없으면 원격 LAN은 응답을 버리거나 자체 기본 게이트웨이, 즉 인터넷으로 보냅니다.

LAN 프리픽스를 광고할 수 없을 때 출발지 변환이 대안입니다. 클라이언트의 범위가 제한된 masquerade 규칙이 출발지를 터널 주소로 다시 쓰고, 그러면 응답이 자연스럽게 돌아옵니다. 또한 어느 LAN 호스트가 요청했는지도 숨기며, 그 자체로 원격 측이 안쪽으로 연결을 시작하게 허용하지는 않습니다. 포괄적인 masquerade를 추가해 나중에 부작용을 발견하는 대신 이 절충을 의도적으로 선택하세요.

4단계: 두 결정을 모두 지속되게 만든 뒤 실제 경로를 테스트하세요

각 경로에는 소유자가 있고, 소유자는 부팅 시나 재연결 시 다시 생성되는 구성입니다. 라우터에서는 정적 경로 항목일 수 있고, 클라이언트에서는 VPN 프로필, NetworkManager, systemd-networkd일 수 있습니다. 터널을 다시 연결하고 클라이언트를 재부팅해 확인하고, 편집을 믿는 대신 테이블을 다시 읽으세요.

터널의 외부 연결을 나르는 기본 경로는 그대로 두세요. 설정을 “단순화”하려고 그것을 바꾸면 내부 트래픽이 쓰기 전에 암호화된 경로가 깨지고, 증상은 변경 후 다시는 설정되지 않는 터널입니다.

일반 LAN 호스트에서 테스트하세요, 클라이언트가 아니라. 클라이언트에서 시작된 요청은 라우터의 첫 홉을 결코 거치지 않기 때문입니다. 원격 LAN에만 존재하는 서비스를 가져와 응답 본문을 확인하고, 클라이언트의 카운터나 로그를 보고 통과가 일어나는지 확인하세요. 사설 홉을 보여 주는 내부 traceroute는 포워딩을 증명할 뿐 암호화를 증명하지 않습니다. 외부 경로는 별도의 관측이며, 터널 자체의 인터페이스 카운터만이 그곳으로 무엇이 나갔는지 보여 줍니다.