DHCP 경로가 트래픽을 VPN 터널 밖으로 내보낼 수 있을까?

암호화는 경계에서 시작되고, 그 경계는 패킷이 캡슐화되기 전에 엔드포인트가 내리는 라우팅 결정입니다. 당신의 키를 결코 보지 못하는 네트워크도 터널 자체의 경로보다 더 좋다고 여기는 경로를 기계에 줄 수 있습니다. 여기서 두 가지 실패가 혼동됩니다. 이미 터널 안에 있는 패킷을 읽는 것과, 한 번도 그곳에 놓이지 않은 패킷을 다른 곳으로 돌리는 것입니다.

이 구분이 중요한 이유는 두 번째 실패가 더 싸게 마련되고 훨씬 놓치기 쉽기 때문입니다. 클라이언트가 여전히 건강한 연결을 보고하는 동안 잘못된 인터페이스로 나간 요청으로 나타납니다.

네트워크가 당신에게 영향을 줄 수 있는 두 가지 방식

터널에 도달한 패킷은 지나는 모든 홉에서 페이로드가 가려지고, 그 보호는 경로가 예상을 벗어나도 유지됩니다. 터널에 결코 도달하지 않는 패킷은 당신의 주소에서 나가는 평범한 요청이며, 라우팅 테이블이 가리킨 곳으로 전송됩니다. 첫 번째 실패에는 깨진 암호나 침해된 피어가 필요하지만, 두 번째는 기계가 신뢰를 선택한 구성 메시지 하나면 됩니다. 이 비대칭이 라우팅 쪽에 별도의 점검이 필요한 이유입니다.

경로 위의 장비는 두 번째 경우에 영향을 주는 데 당신의 키가 필요 없습니다. 필요한 것은 엔드포인트가 경로, 리졸버, 또는 그것을 만들어내는 정책 규칙을 받아들이는 것뿐입니다.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

터널이 존재하기 전에 경로는 어디서 올 수 있는가

DHCP는 주소 임대만 나눠주지 않습니다. 클래스 없는 정적 경로 옵션은 목적지 프리픽스와 다음 홉을 실을 수 있으며, RFC 3442 는 잘못된 라우터 주소의 보안 결과를 논의합니다. 잘못 유도된 트래픽, 서비스 거부, 또는 경로에 앉아 있는 관찰자입니다. 터널이 올라오기 전에 그 경로들을 받아들인 클라이언트는 공급자와 아무 관계 없는 우선 경로를 갖게 될 수 있습니다.

그중 어느 것도 경로 주입을 보편적으로 만들지 않습니다. 클라이언트가 옵션을 받아들여야 하고, 프리픽스가 당신이 중요하게 여기는 트래픽을 덮어야 하며, 선택된 다음 홉에 도달할 수 있어야 하고, 시행 정책이 패킷을 그 길로 내보내도록 허용해야 합니다. 이 중 하나를 빼면 같은 응답은 무해해집니다. 같은 네트워크의 두 기계가 다르게 동작할 수 있는 것도 같은 이유입니다. 같은 클라이언트, 같은 정책, 심지어 같은 주소 체계를 실행하지 않기 때문입니다.

IPv6는 별도의 점검이 필요합니다. 라우터 광고는 DHCPv4 옵션과 다른 코드로 기본 경로를 전달하기 때문입니다. v4 테이블만 보는 테스트는 그것을 다루지 못합니다.

커널이 실제로 고르는 경로를 확인하라

경로 조회에는 답이 있으니 상태등에서 추측하지 말고 물어보세요. 아래 명령은 한 목적지에 대해 선택된 경로와 소스, 그리고 메인 테이블을 덮어쓸 수 있는 규칙을 보여줍니다. 연결된 상태에서 실행하고 다시 연결한 뒤에도 실행하세요. 임대 갱신이 답을 바꿀 수 있습니다.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

출력에서 두 가지를 보세요. 경로에 적힌 인터페이스와 선택된 소스 주소입니다. 터널 경로는 터널 장치를 가리키고, 새어 나간 경로는 물리 장치를 가리키며, 차이는 아무것도 복호화하지 않고도 보입니다. 실행 사이에 답이 달라지면 두 출력을 모두 보관하고 그것을 만든 규칙을 비교하세요.

기본 경로에서 멈추지 마세요. 앱 예외, 분할 터널 프리픽스, 또는 두 번째 정책 규칙이 기본이 여전히 안쪽을 가리키는 동안 특정 목적지를 터널 밖으로 데려갈 수 있습니다.

시행이 어디에 있어야 하는지 결정하라

세 가지 조건이 클라이언트 측 시행으로 충분한지, 그 밖에 무엇이 필요한지를 결정합니다. 클라이언트가 당신이 쓰는 모든 주소 체계에 대해 경로를 설치하고 지킨다면 기본을 소유한 터널로 보통 충분합니다. 기계가 로컬 자원에 닿아야 하고 나머지는 모두 터널 안에 남아야 한다면, 그 예외는 액세스 네트워크가 광고한 것에 맡기지 말고 나열하고 소유해야 합니다. 그리고 플랫폼이 앱별로 트래픽을 인터페이스에 묶을 수 있다면, 그 묶음은 무엇이든 덮어쓸 수 있는 경로보다 강한 보장입니다.

무엇을 고르든 설정이 있는 곳에 결정을 적으세요. 사고 중에 누군가 입력했기 때문에 존재하는 규칙은 다음 재부팅을 넘기지 못합니다. 로컬 예외와 부트스트랩 예외를 좁게 유지하고 각각이 왜 존재하는지 기록하세요.

클라이언트 업그레이드와 네트워크 변경 때마다 조회 명령을 다시 실행하고 마지막으로 기록한 출력과 비교하세요. 라우팅 테이블이 시행의 경계이니 그렇게 다루세요.