VPN 주소에 바인딩한 앱이 계속 잘못된 경로를 쓰는 이유

애플리케이션이 VPN 주소에 바인딩했는데도 연결은 일반 기본 경로로 나갑니다. 바인딩에서 실패한 것은 없습니다. 바인딩이 하는 일을 정확히 했을 뿐입니다. 소켓을 로컬 주소에 바인딩하면 커널이 헤더에 넣을 소스 주소가 선택됩니다. 경로를 설치하지도 않고, 그 소스를 가진 패킷을 특정 터널로 보내는 정책 규칙을 만들지도 않습니다.

이 런북의 나머지는 제가 쓰는 점검 순서와 각 관찰을 만들어 내는 명령입니다.

바인딩이 실제로 결정하는 것

바인딩은 소켓에 로컬 주소를 할당합니다. 그다음 커널은 정책 규칙이 그 조회가 읽는 테이블을 바꾸지 않는 한, 평소와 같은 경로 조회를 수행합니다.

그래서 패킷이 물리 인터페이스에서 VPN 소스 주소를 달고 나갈 수 있습니다. 반대편에서는 네트워크가 그 경로에서 전혀 예상하지 못한 사설 대역에서 도착하고, 돌아오는 트래픽에는 되돌아갈 경로가 없으며, 연결은 멈추거나 재설정됩니다.

Linux IP 소켓 레퍼런스가 바인딩의 의미를 문서화합니다. 라우팅 쪽 절반은 ip-rule과 ip-route에 있고, 이들이 별도 매뉴얼인 데에는 이유가 있습니다.

주소가 이 네임스페이스에 속하는지 확인하세요

바인딩할 수 있는 주소는 애플리케이션이 실행되는 네트워크 네임스페이스 안의 인터페이스에 존재해야 합니다. 피어 주소, 게이트웨이 주소, 또는 다른 네임스페이스에만 있는 주소는 바인딩할 수 없고, 호출은 EADDRNOTAVAIL로 실패합니다.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

그 세 가지를 애플리케이션과 같은 컨텍스트에서 실행하세요. 같은 네임스페이스이고, 가능하면 같은 사용자입니다. 오래된 net30 다이어그램은 현재 토폴로지가 클라이언트에 어떤 주소를 할당했는지에 대한 증거가 아닙니다. 실제로 살아 있는 인터페이스를 읽으세요.

그 소스와 목적지에 대한 조회를 읽으세요

명령 하나가 바인딩이 답하지 않은 질문에 답합니다.

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

첫 줄은 그 소스에서 그 목적지로 가는 패킷이 탈 경로를, 나가는 인터페이스와 선호 소스를 포함해 출력합니다. 물리 인터페이스를 지목한다면 바인딩과 경로가 서로 어긋나고, 패킷은 경로가 돌아올 수 없는 소스로 나갑니다.

이어서 ip rule show가 다른 테이블을 선택할 규칙이 있었는지 알려 줍니다. 여기서는 우선순위가 중요합니다. 처음 일치하는 규칙이 이기고, 내 규칙 위에 있는 포괄 규칙은 내 규칙을 보이지 않게 만들기 때문입니다.

정책 규칙은 그것이 설계일 때만 넣으세요

소스 기반 라우팅은 의도된 설계이지 한 애플리케이션을 위한 수리가 아닙니다. 정책 소유자가 터널 서브넷의 트래픽이 터널을 쓰길 원한다면, 규칙은 그 소유자의 구성에 속하고 노트북의 일회성 명령에 속하지 않습니다.

실용적인 형태는 터널을 지나는 기본 경로가 있는 전용 테이블과, VPN 소스 대역을 그 테이블로 보내는 규칙입니다. 설계에 필요한 예외를 더하세요. 터널 기본값만 있는 테이블은 로컬에 남아야 하거나 물리 경로로 도달해야 하는 목적지까지 붙잡습니다.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del과 ip route flush table 100으로 되돌립니다. 이렇게 추가한 것은 관리자가 기록하지 않는 한 재부팅 때 사라지며, 이는 안전 속성이자 유일한 사본을 셸 기록에 두지 않을 이유입니다.

세 가지 관찰로 검증하세요

애플리케이션이 요청한 소스, 조회가 선택한 경로, 서버가 실제로 본 소스를 기록하세요.

이 셋은 어긋날 수 있고, 각각의 불일치는 다른 곳을 가리킵니다. 터널 인터페이스에서의 캡처는 패킷이 올바른 소스로 나갔음을 증명합니다. 물리 인터페이스에서의 캡처는 잘못된 길로 나갔음을 증명합니다. 경로를 끝에서 끝까지 증명하는 것은 서버 쪽 시점뿐입니다.

애플리케이션이 장치 바인딩 옵션이나 앱별 라우팅 모드를 제공한다면, 다른 제약이 있는 다른 메커니즘으로 다루세요. 비슷해 보이는 설정이 모두 같은 커널 결정으로 이어지지는 않습니다.