VPN을 통한 Dante SOCKS: 전체 터널과 소스 라우팅 비교

SOCKS 프록시의 트래픽은 VPN으로 나가고 호스트의 나머지는 평소 경로를 유지하기를 원합니다. 이를 수행하는 설계는 두 가지이며, 문제가 생겼을 때 무엇이 깨지는지가 다릅니다. 하나는 기본 경로를 터널로 밀어 넣은 뒤 우회하고, 다른 하나는 메인 테이블을 그대로 두고 하나의 소스 주소를 두 번째 테이블로 보냅니다. 두 번째가 더 깔끔하지만 나름의 함정이 있습니다.

두 설계, 두 가지 피해 범위

전체 터널 설계는 대부분의 VPN 클라이언트가 기본으로 하는 방식입니다. 기본 경로를 바꿔 모든 것이 터널을 따르게 한 다음, 따르지 않아야 할 것을 제외합니다. 이해하기는 쉽지만 좁게 유지하기는 어렵습니다. 추가하는 모든 로컬 서비스가 제외하기 전까지 터널을 물려받기 때문입니다. 실패 양상은 넓습니다. 잘못된 경로 하나가 호스트 자체의 연결까지 가져갑니다.

소스 선택 설계는 반대 방향으로 갑니다. 메인 테이블은 그대로 두고, 정책 규칙 하나가 특정 로컬 주소에서 나온 패킷을 터널 기본 경로가 있는 테이블로 보냅니다. 다른 것은 바뀌지 않으므로 피해 범위는 주소 하나입니다.

이 좁음이 곧 제약입니다. 프록시의 나가는 패킷이 실제로 그 주소를 실어야만 이 설계가 동작합니다.

Dante의 external 설정이 하는 일

external 설정은 프록시가 나가는 연결에 사용할 주소를 고릅니다. 커널의 라우팅 정책은 건드리지 않습니다. 이 분리가 두 번째 설계를 가능하게 하며, 바로 이 지점에서 사람들이 문서를 잘못 읽습니다. external을 터널 주소로 지정하면 프록시가 그 주소에서 연결을 시작하고, 그다음 라우팅 테이블이 그 패킷의 목적지를 결정합니다.

리스너는 별개의 문제입니다. internal은 프록시를 사용해야 하는 클라이언트로 제한하고, 인증을 요구하고, 포트를 방화벽으로 닫으십시오. 열린 리스너는 VPN 출구의 기능이 아닙니다.

설정한 주소가 프록시의 네트워크 네임스페이스 안에서 실제로 터널에 속하는지 확인하십시오.

소스 선택 테이블 만들기

TUN 주소가 10.90.0.2/24이고 10.90.0.1에서 피어에 도달할 수 있으며, 다른 무엇도 쓰지 않는 테이블 번호를 쓴다면 배치는 다음과 같습니다.

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

도달 불가 경로가 사람들이 건너뛰는 부분입니다. 이것이 없으면 터널 경로가 사라진 테이블이 일반 기본 경로로 떨어져 프록시가 조용히 WAN으로 나갑니다. 이것이 있으면 조회가 실패하는데, 이는 조용한 누출이 아니라 눈에 보이는 실패입니다. 규칙의 우선순위도 그 소스와 일치하는 다른 무엇보다 앞에 있어야 합니다.

이 값들은 하나의 토폴로지를 설명합니다. 지점 간 피어, net30 주소 지정, 다른 프리픽스를 나눠 주는 클라이언트는 모두 자체 경로가 필요하므로 주소가 아니라 형태를 복사하십시오.

소스 규칙이 새는 곳

소스 주소와 일치하는 규칙은 프록시뿐 아니라 그 주소를 쓰는 모든 프로세스에 영향을 줍니다. 다른 데몬이 같은 주소를 묶으면 그 트래픽도 터널을 타고, 실패는 무관한 서비스 문제처럼 보입니다. 프록시에 다른 무엇도 쓰지 않는 주소를 주거나, 범위가 프로세스가 아니라 주소임을 받아들이십시오.

DNS가 또 다른 누출입니다. 리졸버 소켓이 반드시 프록시의 external 데이터 연결 소스를 쓰는 것은 아니므로 이름 조회는 여전히 WAN으로 나갈 수 있습니다. 연결 수립과 별도로 해석을 시험하고, 그 결과가 허용 가능한지 결정하십시오.

IPv6에는 자체 규칙과 경로가 필요합니다. IPv4 배치는 그것에 대해 아무것도 증명하지 않습니다.

감당할 수 있는 실패로 고르십시오

호스트 전체를 보호해야 하고 제외 목록을 유지할 수 있다면 전체 터널을 고르십시오. 호스트가 자체 경로를 유지해야 하고 하나의 서비스만 우회시켜야 한다면 소스 기반 라우팅을 고르십시오. 둘 다 타당합니다. 잘못은 하나를 고른 뒤 다른 것인 양 시험하는 것입니다.

어느 쪽을 고르든 양쪽에서 검증하십시오. 프록시를 통한 요청과 호스트에서의 직접 요청을 보내고, 각각 관찰된 출구 주소를 기록하십시오.

터널이 끊기면 프록시가 실패해야 하는지 물러나야 하는지 미리 결정하고, 라우팅 테이블이 그 결정을 표현하게 하십시오.