전체 터널 VPN이 라우팅된 로컬 VLAN을 숨기는 이유

VPN 클라이언트의 “allow local network” 스위치는 건물 안의 모든 것을 덮는 것처럼 들립니다. 실제로는 보통 터널의 기본 경로에 몇 가지 사설 주소 예외를 추가하고 거기서 멈춥니다. 스토리지 VLAN이 계속 접근 가능하려면 해당 특정 프리픽스에 대한 경로가 터널의 도착을 견뎌야 합니다, 그리고 많은 클라이언트에서는 견디지 못합니다.

이는 VPN 설정이 아니라 라우팅의 문제이며, 좋은 소식입니다: 구체적인 답이 있습니다.

allow-local-network가 실제로 다루는 범위

클라이언트마다 그 옵션을 다르게 구현합니다. 어떤 클라이언트는 머신이 연결된 서브넷에 대한 경로를 추가하고, 어떤 클라이언트는 RFC 1918 범위를 추가하며, 몇몇은 기본 게이트웨이만 제외합니다. 그들 중 어느 것도 사무실 라우터가 스토리지 VLAN, 랩 세그먼트, 프린터 서브넷까지 제공한다는 사실을, 그 프리픽스가 클라이언트가 볼 수 있는 회선 위에 없기 때문에 모릅니다. 라벨이 당신의 토폴로지를 설명한다고 가정하지 말고 정확한 동작은 클라이언트 자체 문서를 읽으십시오.

이 차이는 클라이언트가 모든 트래픽이 VPN을 지나도록 기본 경로를 의도적으로 교체하는 전체 터널 설계에서 가장 중요합니다. 그것이 설계의 존재 이유이며, 동시에 로컬 라우팅 네트워크를 사라지게 만드는 원인입니다. 그 네트워크들은 자체 경로로 덮인 적이 없고 방금 교체된 기본 경로 위에 얹혀 있었을 뿐입니다. 클라이언트는 존재를 모르는 것을 라우팅할 수 없고, 자신의 인터페이스에 붙은 프리픽스만 배웁니다. 나머지는 토폴로지를 아는 누군가가 설명해야 합니다.

연결된 경로는 첫 번째 라우터에서 멈춘다

192.168.10.20/24에 있고 게이트웨이가 192.168.10.1인 워크스테이션은 192.168.10.0/24에 대한 연결된 경로를 자동으로 받습니다. 192.168.20.0/24의 스토리지 VLAN은 다른 프리픽스이며 그 게이트웨이를 통해서만 도달할 수 있고, 워크스테이션에는 기본 경로 외에 그것을 위한 경로가 없습니다. 터널이 올라오기 전에는 일반 기본 경로가 우연히 스토리지 트래픽을 192.168.10.1로 보내 모든 것이 동작합니다.

VPN이 전체 터널 기본 경로를 설치하면 192.168.20.1로 가는 패킷은 새 기본 경로를 따라 터널로 들어갑니다. 원격 게이트웨이는 그 프리픽스가 어디 있는지 전혀 모르므로 패킷을 버리거나 쓸모없는 곳으로 전달합니다. 스토리지 VLAN에는 잘못 구성된 것이 없었고, 그 경로는 빌려온 것이었으며 대출이 회수된 것입니다.

유혹은 /1 경로 쌍이나 두 번째 기본 경로 같은 넓은 예외에 손을 뻗는 것입니다. 그것을 견디십시오. 예외가 좁을수록 네트워크가 바뀔 때 설명하고 감사하고 제거하기가 쉽습니다.

예외를 이기는 테이블에 넣으십시오

하나의 라우팅 테이블 안에서는 /24가 가장 긴 프리픽스 일치로 /0이나 /1을 이기므로, 그 테이블이 실제로 조회된다면 로컬 게이트웨이를 통한 스토리지 VLAN으로의 구체적인 경로로 충분합니다. Linux에서는 보통 형태가 짧습니다:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

정책 라우팅은 그 보장을 복잡하게 만듭니다. 더 앞선 규칙이 자체 기본 경로가 터널을 가리키는 테이블로 트래픽을 보낼 수 있고, 그러면 당신의 /24가 있는 메인 테이블에는 결코 도달하지 못합니다. 잘못된 테이블에 있는 올바르게 보이는 항목이 끊어진 경로처럼 보이는 장애를 설명해 주므로, 경로를 권위 있다고 가정하기 전에 규칙을 확인하십시오.

그다음 클라이언트가 지원하는 메커니즘 또는 인터페이스를 소유한 네트워크 관리자를 통해 항목을 영구적으로 만드십시오. 프롬프트에 입력한 경로는 다음 재연결에서 사라지고, 하나의 Wi-Fi 게이트웨이에 묶인 경로는 노트북이 방문하는 다음 네트워크로 옮길 수 없습니다.

이름과 정책은 경로를 따르지 않는다

경로를 고치는 것은 패킷을 되살릴 뿐 이름은 아닙니다. 로컬 장치가 그것들에 대해 아무것도 모르는 강제 리졸버를 통해 확인되면 주소에 도달할 수 있어도 마운트는 계속 실패합니다. 로컬 이름에는 로컬 또는 분할 DNS 구성이 필요하며, 이는 경로 예외와 별개의 결정입니다.

정책은 다시 별개입니다. VPN 클라이언트의 로컬 액세스 필터는 사설 범위로의 트래픽을 의도적으로 금지할 수 있고, 경로는 그 규칙을 무시하지 않습니다. 신뢰할 수 없는 네트워크에서 사설 주소는 목적지가 당신의 스토리지 서버라는 증거도 아니므로, 예외는 경로 자체만큼 구체적이어야 합니다.

넘겨줄 수 있는 계약

완성된 설계는 짧은 목록으로 읽혀야 합니다: 일반 인터넷 트래픽은 터널을 따르고, 이 이름 붙은 로컬 프리픽스는 로컬 라우터를 통한 경로를 유지합니다. 프리픽스, 다음 홉, 그리고 함께 가는 DNS 접미사를 적어 두고, 라우팅 테이블을 읽지 않고도 누군가 검증할 수 있을 만큼 목록을 짧게 유지하십시오.

로컬 범위와 원격 범위의 겹침을 주의하십시오. VPN 뒤의 무언가와 프리픽스를 공유하는 스토리지 VLAN은 더 구체적인 경로로 확인되며, 그 결과 동작은 간헐적으로 보이는 방식으로 혼란을 줍니다. 한쪽의 번호를 다시 매기는 것이 모호함을 영원히 디버깅하는 것보다 보통 저렴합니다.

계약을 두 번 테스트하십시오: 터널이 올라간 상태에서 한 번, 내려간 상태에서 한 번. 로컬 경로가 그중 한 상태에서만 동작한다면, 그 예외는 아직 계약이 아닙니다.