VPN 경로의 다음 홉: 게이트웨이가 로컬에서 도달 가능해야 하는 이유

VPN 네트워크로 가는 경로는 혼동하기 쉬운 두 주소, 즉 패킷이 도달하려는 목적지 프리픽스와 그것을 한 걸음 더 가깝게 옮길 다음 홉을 나릅니다. LAN 호스트에서 그 다음 홉은 같은 링크에서 실제로 도달할 수 있는 라우터여야 합니다. 원격 VPN 주소는 아무리 목적지와 잘 맞아떨어져도 다음 홉이 아닙니다.

이 런북은 192.168.20.0/24 의 노트북, LAN 주소가 192.168.20.5 인 VPN 게이트웨이, 그리고 그 게이트웨이 뒤의 원격 네트워크 10.70.0.0/24 라는 일반적인 경우를 다룹니다. 아래 명령은 따로 말하지 않는 한 노트북에서 실행한다고 가정합니다.

두 주소, 하나의 경로

의도한 항목은 10.70.0.0/24 via 192.168.20.5 이며, 프리픽스는 패킷이 어디로 가는지, via 주소는 누가 그것을 그곳으로 나르는지 알려 줍니다. 커널은 지정한 인터페이스로 게이트웨이에 도달할 수 없는 경로를 설치하지 않으며, 그 거부가 바로 핵심입니다. 도달 가능하려고 터널이 필요한 다음 홉은 터널을 만드는 다음 홉이 될 수 없습니다.

그래서 첫 점검은 «게이트웨이가 살아 있는가»가 아니라 «게이트웨이가 이 링크에 있는가»입니다. 노트북 자체의 서브넷, 그 ARP 또는 이웃 항목, 경로에 있는 인터페이스가 모두 일치해야 합니다. 10.70.0.0/24 안에만 존재하는 주소는 두 번째 경로의 목적지가 될 수 있지만, 첫 번째 경로의 via 은 결코 될 수 없습니다.

다음 홉이 게이트웨이에 지우는 것

노트북에 경로를 설치하는 것은 첫 핸드오프만 결정합니다. 그다음 게이트웨이는 포워딩 활성화, 10.70.0.0/24 로 가는 터널 경로, 그리고 누가 그것을 쓸 수 있는지 정하는 접근 정책을 갖춘 자기 경로가 필요합니다. Linux 에서는 net.ipv4.ip_forward=1 과 터널 경로이며, 그 앞의 방화벽에는 포워딩되는 흐름을 허용하는 규칙이 필요합니다.

돌아오는 방향이 사람들이 잊는 부분입니다. 원격 쪽에는 192.168.20.0/24 로 돌아가는 경로가 있어야 하고, 아니면 설계가 노트북의 출발지를 원격 쪽이 아는 무언가로 변환해야 합니다. 게이트웨이에서 성공하는 ping 은 게이트웨이가 원격 네트워크에 도달할 수 있음을 증명할 뿐, 노트북의 패킷이 돌아오는 여정에서 살아남는지는 말해 주지 않습니다.

보내는 호스트에서 조회를 검증하세요

커널에 어느 다음 홉을 고를지 물어보고, 답에 나오는 인터페이스를 읽으세요:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

조회가 게이트웨이와 LAN 인터페이스를 보고하면 첫 구간은 의도대로 구성된 것입니다. 터널 장치를 보고하면 테이블에서 더 앞선 무언가가 더 구체적이어서 이기고 있습니다. 경로가 아예 설치되지 않으면 커널이 게이트웨이에 도달할 수 없다고 알려 주며, 그 메시지는 어떤 패킷 캡처보다 유용합니다.

그런 다음 올바른 위치에서 시험을 반복하세요. 게이트웨이에서 만든 요청은 게이트웨이 자신의 출발지 주소를 쓰므로, 빠진 돌아오는 경로나 특정 출발지만 허용하는 정책을 가릴 수 있습니다. ip-route 매뉴얼은 목적지, 게이트웨이, onlink 재정의를 구분하며, 재정의는 쓰기 전에 이해할 가치가 있습니다.

도달 가능성을 꾸며 내려고 onlink 를 쓰지 마세요

onlink 는 커널에 게이트웨이 도달 가능성 점검을 건너뛰고 그래도 그리로 보내라고 합니다. 그것은 경로를 만들지 않고, 없는 주소의 ARP 를 풀지 않으며, 원격 라우터가 당신의 Ethernet 세그먼트에서 응답하게 만들지도 않습니다. 응답하지만 연결된 서브넷에 있지 않은 게이트웨이에는 정당하며, 설명하지 않은 오류를 잠재우는 데 쓰면 함정입니다.

경로가 onlink 로만 설치된다면, 다음 질문은 게이트웨이가 왜 당신이 생각하는 곳에 없느냐입니다. 잘못된 VLAN, 잘못된 인터페이스의 두 번째 주소, 마지막 옥텟의 오타가 모두 이것을 만들며, 각각은 트래픽이 흐르기 시작하면 돌아오는 경로도 깨뜨립니다.

지점 간 터널은 Ethernet 이 아닙니다

터널 장치는 ARP 를 하지 않고 흔히 이웃의 의미 있는 서브넷이 없습니다. 그 경로는 흔히 10.70.0.0/24 dev tun0 처럼 보이며 via 이 전혀 없는데, 피어가 유일한 다른 끝점이기 때문입니다. LAN 방식의 via 을 그 테이블에 복사하면 커널이 거부할 수 있는 경로가, 더 나쁘게는 피어가 결코 응답하지 않는 주소를 가리키는 경로가 생깁니다.

런북에서는 도달 가능한 게이트웨이가 있는 LAN 경로와 인터페이스와 피어가 있는 터널 경로라는 두 모델을 분리해 두세요. WireGuard, OpenVPN, IPsec 은 모두 조금씩 다른 형태를 보이므로, 한 호스트에서 일반화하지 말고 실제로 쓴 형태를 기록하세요.

추가하고, 확인하고, 되돌리세요

전체 변경은 세 명령과 한 번의 점검이며, 바로 그 순서로 적어 두어야 합니다:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

경로를 확인하고, 목적지 하나를 확인한 다음, 변경이 예상하지 못한 방식으로 호스트를 도달 불가능하게 만들 경우를 대비해 삭제 줄을 준비해 두세요. 경로가 재부팅 후에도 남아야 한다면 shell 프로필이 아니라 호스트의 네트워크 구성에 넣고, 그것에 의존하기 전에 재부팅을 시험하세요. 자기를 추가한 shell 안에만 존재하는 경로는 두 번 디버그하게 될 경로입니다.