VPN 밖으로는 로컬 웹 서비스 하나만, 포트 기준으로 라우팅

호스트의 서비스 하나는 물리 업링크로 인터넷에 응답하고, 나머지는 모두 터널을 계속 사용해야 합니다. 정책 기반 라우팅이 그 부하를 감당할 수 있는지는 세 가지 조건이 결정하며, 각각은 규칙을 쓰기 전에 저렴하게 확인할 수 있습니다. 서비스가 DNAT나 전달된 포트 뒤가 아니라 이 호스트에서 종료되어야 하고, VPN 자체 규칙이 예외를 허용해야 하며, 요청이 아니라 응답을 일치시켜야 합니다. 세 가지 중 하나라도 어긋나면 아래 명령은 오류 없이 로드되지만 아무 쓸모도 없습니다.

규칙을 쓰기 전에 세 가지 조건을 확인하세요

DNAT로 포트를 게시하는 컨테이너나 포트 포워딩 뒤에 있는 서버는 이 호스트에서 생기지 않는 패킷을 만듭니다. 그 패킷은 전달되므로 호스트 로컬 입력에 걸린 규칙은 그것들을 결코 보지 못합니다 그리고 트래픽은 계속 기본 경로를 탑니다. 계속하기 전에, 사람들이 가장 자주 틀리는 조건이므로, 서비스가 실제로 어디에서 실행되는지 확인하세요.

두 번째 조건은 기계가 아니라 정책입니다. 터널을 우회하는 모든 경로는 터널의 목적에 대한 예외이며, 관리되는 호스트에서는 그 결정이 정책을 소유한 사람의 것이지 시간 초과를 디버깅하는 사람의 것이 아닙니다.

응답을 일치시키세요. 클라이언트의 목적지 포트가 아닙니다

TCP 443에서 수신하는 서버의 응답은 출발지 포트 443으로 호스트를 떠납니다. 같은 호스트의 브라우저가 원격 HTTPS 사이트에 연결할 때는 임시 출발지 포트와 목적지 포트 443을 보냅니다. 둘 다 포트 443 트래픽이고 그중 하나만 WAN 테이블을 써야 하므로, 목적지 포트 일치는 반대쪽 절반을 잡게 됩니다.

구분할 수 있는 것은 응답 방향입니다. 출발지 포트를 일치시키고 규칙을 로컬에서 생성된 패킷으로 한정하면, 규칙은 브라우저 요청을 건드리지 않고 서비스 자체의 응답을 덮습니다.

규칙이 가리키기 전에 완전한 반환 테이블을 만드세요

빈 테이블은 경로가 없음을 뜻하며, 이는 깨진 정책보다 깨진 서비스처럼 보입니다. 먼저, 호스트의 다른 무엇도 차지하지 않은 테이블 번호와 우선순위로 채우세요:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

숫자는 복사하지 말고 실행 중인 호스트에서 읽으세요. ip -4 rule show은 어떤 우선순위가 사용 중인지 알려 주고, 이미 있는 우선순위에 규칙을 추가하면 각각 따로 보면 멀쩡한 두 규칙의 순서가 조용히 바뀝니다.

여기서 실제 작업은 두 선택자가 합니다. iif lo은 호스트가 스스로 만든 패킷을 커널이 보고하는 방식이라, 규칙이 밖에서 들어오는 전달 트래픽을 실수로 잡을 수 없습니다. ipproto tcp sport 443은 이를 하나의 전송과 하나의 포트로 좁히며, 요구 사항이 허용하는 만큼 빡빡합니다. 프로토콜 선택자를 빼면 규칙이 UDP 443도 잡는데, 이는 동작이 다른 다른 서비스입니다.

사설 응답은 터널 안에 두세요

같은 리스너가 사설 쪽 클라이언트에도 응답하면, 테이블 100의 모든 것을 잡는 WAN 기본 경로가 그 응답을 업링크로 되돌리려 합니다. WAN 기본을 따르면 안 되는 사설 접두사를 추가하거나, 다음 정책 규칙으로 넘어가게 하세요:

ip -4 route add table 100 throw 10.90.0.0/24

throw 경로는 이 테이블에서 조회를 끝내고 패킷을 규칙 목록으로 돌려보내므로, 뒤따르는 VPN 정책이 기회를 얻습니다. 그 자체로는 터널로 아무것도 라우팅하지 않으며, 이후 규칙에 일치하는 경로가 없으면 패킷은 여전히 실패하므로, throw를 해결책으로 가정하지 말고 다음 정책을 검증하세요.

역방향 경로 필터링과 호스트 방화벽 규칙은 들어오는 요청에 여전히 적용되므로, 검증을 느슨하게 하기 전에 실제 판정을 보세요. 라우팅 예외가 rp_filter이 불가능하다고 보는 반환 경로를 받아들이게 만들지는 않습니다.

TCP, 그다음 QUIC, 그다음 재부팅을 시험하세요

승인된 외부 클라이언트에서 하나, 사설 쪽에서 하나 연결을 열고, 실제 주소와 포트로 응답 조회를 검사하세요. 외부 응답이 테이블 100을 쓰고 사설 응답이 쓰지 않는다면, 정책은 요청한 대로 동작합니다.

HTTP/3는 UDP로 제공되며 TCP 규칙과 일치하지 않으므로 QUIC 리스너에는 자체 선택자가 필요합니다. 그렇지 않으면 HTTPS가 동작하는 동안에도 터널을 계속 씁니다. 정한 규칙은 인터페이스를 소유한 구성 요소에 저장하고 다시 연결하거나 DHCP 갱신 후에 확인하되, 재부팅 후 경쟁 관리자가 런타임 경로를 제거한다면 그것은 원천에서 고쳐야 할 소유권 문제이지 더 넓은 NAT 규칙을 위에 얹을 이유가 아닙니다.