FRITZ!Box 정적 경로: VPN 게이트웨이의 LAN IP를 가리키게 하세요

집 LAN에는 기본 라우터로 FRITZ!Box가 있고 그 옆에 소형 Linux 상자가 VPN 역할을 합니다. 상자는 사무실 네트워크에 닿지만 FRITZ!Box 뒤의 노트북은 닿지 못합니다. 정적 경로는 이 문제를 세 필드로 해결하며, 유일한 실제 어려움은 게이트웨이 필드에 터널 주소를 넣지 않는 것입니다. 게이트웨이는 자신의 LAN에서 다음 라우터이며 늘 그랬습니다.

인터페이스를 열기 전에 세 필드를 적어 두세요

LAN 192.168.50.0/24, FRITZ!Box 192.168.50.1, 고정 주소가 192.168.50.2 인 VPN 상자가 있고 이미 10.40.0.0/16 까지 작동하는 보호 경로가 있다고 합시다. 경로는 그 원격 접두사로 가는 패킷을 고정 LAN 주소의 장치에 넘기라고 말합니다. 원격 VPN 서버의 공용 엔드포인트와 내부 터널 주소는 FRITZ!Box가 그들에게 직접 아무것도 보내지 않으므로 여기서 둘 다 무관합니다.

설정한 게이트웨이가 언젠가 휴대폰의 것이 되지 않도록 그 LAN 주소를 DHCP 풀 밖에서 예약하세요.

FRITZ!Box가 경로를 보관하는 곳

FRITZ!는 홈 네트워크, 네트워크, 네트워크 설정 순으로 들어가 IPv4 경로 제어를 엽니다. 정확한 레이블과 중첩은 모델과 FRITZ!OS 버전에 따라 다르지만, 경로 표가 숨겨져 있으면 고급 보기를 켜고 위 값으로 항목 하나를 추가한 뒤 적용하세요. 같은 기능이 릴리스 사이에 여러 번 자리를 옮겼으므로 사용 중인 모델의 안내서도 한번 볼 가치가 있습니다. 표의 항목은 어느 화면에서 만들어졌는지 거의 알려주지 않으니 저장하는 항목의 정확한 문구를 적어 두세요.

FRITZ!Box가 직접 VPN을 종료하는 기능과는 다릅니다. 경로는 다른 장치를 가리키고, 내장 VPN은 바로 그 장치입니다.

게이트웨이는 도달하는 것만으로는 부족하고 라우팅해야 합니다

원격 네트워크에 닿는 호스트가 나머지 LAN의 라우터가 되는 것은 아닙니다. VPN 상자에는 IP 포워딩이 켜져 있어야 하고, LAN 인터페이스와 터널 사이의 포워딩을 허용하는 방화벽 정책이 있어야 하며, 응답을 자체 기본 경로로 내보내지 않고 LAN으로 되돌려 보내는 경로가 있어야 합니다. 포워딩만 켜고 방화벽 규칙을 잊는 것이 가장 흔한 반쪽짜리 수정이며, 클라이언트 쪽에서는 라우팅 장애처럼 보입니다.

FRITZ!Box 쪽에서 VPN 상자의 LAN 주소로 ping하고, 그다음 클라이언트에서 원격 주소로 추적해 두 번째 홉이 그 상자인지 확인하세요.

반환 경로와 겹치는 대역

원격 쪽에는 192.168.50.0/24 에 대한 터널 반환 경로가 필요합니다(VPN 상자에서 의도적으로 출발지를 변환하지 않는 한). 보존과 변환은 서로 다른 정책이며 로그와 접근 규칙도 다릅니다, 방금 추가한 정적 경로는 그 둘 사이에서 선택하지 않습니다. 겹치는 대역은 더 어려운 문제로, 집 LAN과 원격 네트워크가 같은 접두사를 공유하면 호스트 경로 하나로는 구분할 수 없고 주소 계획을 바꿔야 합니다.

LAN의 다른 곳에 더 구체적인 경로를 추가하거나 노트북에 두 번째 VPN 클라이언트를 두면 FRITZ!Box 항목을 조용히 이깁니다.

일반 클라이언트에서 시험하고, 다음으로 장애를 시험하세요

상자는 이미 동작하고 있었으므로 아무것도 증명하지 못하니, 시험은 VPN 상자가 아니라 LAN의 일반 승인된 머신에서 실행하세요. 원격 서비스에 닿아 응답을 확인하고, 무관한 인터넷 목적지가 여전히 기본 경로를 쓰며 터널로 끌려가지 않는지 확인하세요. 서브넷 하나에 닿기 위해 기본 경로를 바꾸는 것은 처음 시작한 세 필드 항목보다 훨씬 큰 변경입니다.

마지막으로 VPN을 끊으면, 게이트웨이가 보호 경로를 잃어도 정적 경로는 표에 남으므로 트래픽은 인터넷으로 되돌아가지 않고 상자에서 실패합니다. 폴백 트래픽을 막아야 한다는 요구는 저장된 경로가 아니라 상자 자체의 정책에 속합니다.