UID 규칙으로 Linux 계정 하나를 OpenVPN으로 라우팅하기

계정 기반 라우팅은 한 Linux 사용자가 소유한 모든 IPv4 소켓이 기존 터널을 통해 나가야 할 때 적합하고, 프로그램 수준의 격리가 필요할 때는 적합하지 않습니다. UID로 선택하므로 그 계정으로 실행되는 모든 것이 범위에 들어가며, 잊고 있던 배치 작업도 포함됩니다. 단 하나의 ip rule 도 건드리기 전에 그 질문을 정리하세요.

아래 예시는 UID 1500의 전용 브라우저 계정, 로컬 주소 10.80.0.11을 가진 터널 장치 tun-office, 그리고 해당 목적지를 허용하는 VPN을 가정합니다. 데몬 자체는 그 UID 밖에서 실행됩니다.

메커니즘을 고르는 세 가지 조건

UID 규칙은 작업을 수행하는 주체가 계정이고, 그 모든 트래픽을 옮기는 것이 허용되며, namespace가 작업에 비해 과하게 무거울 때 선택합니다. 네트워크 namespace는 워크로드에 자체 인터페이스, 리졸버, 라우팅 테이블이 필요할 때 선택합니다. 프록시나 프로세스별 바인딩은 정확히 하나의 애플리케이션만 옮겨야 할 때 선택하며, 세션의 나머지는 로컬 경로에 남습니다. 이 셋을 적어 두면 의도보다 조용히 더 많이 덮는 규칙을 막을 수 있습니다.

피해야 할 실수는 런처가 소유자를 정한다고 가정하는 것입니다. 다른 사용자의 세션이 URL을 넘긴 브라우저는 UID 1500 아래에서 소켓을 만들지 않았고, 어떤 규칙도 그것이 만드는 트래픽을 옮기지 않습니다.

테이블, 규칙, 가드

기존 규칙을 확인하고 사용하지 않는 테이블 및 우선순위 번호를 고른 뒤 구성은 짧으며, 터널의 원본 주소를 담은 전용 테이블의 기본 경로, 계정의 조회를 그 테이블로 보내는 규칙, 대체 경로를 막는 종료 규칙으로 이루어집니다. 글로 쓰면 멱등적인 경로 교체 ip -4 route replace default dev tun-office src 10.80.0.11 table 51820 와 그 뒤를 잇는 ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820 입니다.

가드는 ip -4 rule add priority 12101 uidrange 1500-1500 unreachable 이며, 길이가 시사하는 것보다 중요합니다. 그것이 없으면 테이블 51820에서 빠진 경로가 일반 업링크로 떨어져 계정이 정책이 잡아야 할 트래픽을 조용히 흘립니다. 그것이 있으면 같은 실패가 시간 초과가 되어, 대체가 아니라 차단이 됩니다.

일반적인 로컬 주소 규칙을 이들 앞에 두고, LAN이나 관리 예외를 선택한 테이블 앞에 둘지 의식적으로 결정하세요. 거기서 찾은 기본 경로는 나중에 더 구체적인 LAN 경로를 위해 main 를 조회하지 않으며, 최장 프리픽스 일치가 테이블을 넘어 적용된다고 기대하는 사람을 놀라게 합니다. 의도한 예외 목록은 근거가 아직 신선할 때 변경 노트에 적으세요.

UID 라우팅이 빼놓는 것: DNS

리졸버 데몬은 업스트림 소켓을 자기 UID 아래에서 열기 때문에 1500을 선택해도 그 질의가 테이블 51820으로 옮겨지지 않습니다. DNS 통합은 별도의 결정이며, 계정을 터널로 닿는 리졸버로 향하게 하거나, 이름 해석은 호스트 경로를 따르고 트래픽은 그렇지 않다고 받아들이는 것입니다.

로컬 스텁으로의 loopback 질의는 업스트림 질의가 브라우저 경로를 썼다는 증거가 아니며, 캐시에서의 성공적인 페이지 로드도 증거가 아닙니다.

IPv6는 설계에서 자기 문장이 필요합니다

위 규칙은 IPv4만 다룹니다. 요구 사항이 이 계정에서 직접 IPv6가 없는 IPv4 터널이라면 검토된 종료 규칙을, 예를 들어 ip -6 rule add priority 12101 uidrange 1500-1500 unreachable 처럼 추가하고, 그다음 이전 IPv6 규칙과 유지하려는 loopback 예외를 확인하세요.

직접 IPv6를 막는 것은 이중 스택 터널링이 아니라 경계입니다. 그것을 터널링이라고 부르면 정책을 읽는 다음 사람을 혼란스럽게 하고, 그 혼란은 망가진 IPv6 사이트에 대한 헬프데스크 티켓으로 드러납니다.

실제 계정으로 검증하고, 그다음 수명 주기를 책임지세요

ip -4 route get 198.51.100.25 uid 1500 을 같은 목적지를 일반 UID로 조회한 결과와 비교하세요. 그다음 전용 계정으로 허용된 요청을 하고 원격 측이 보는 원본 주소를 확인하세요. 선호 원본 주소는 source NAT가 아니며, 다른 것을 바인딩한 애플리케이션을 덮어쓰지 않습니다. 두 조회가 같은 경로를 돌려준다면 규칙은 생각하는 대로 동작하지 않습니다.

테이블, 규칙, 터널 경로의 수명을 한 소유자 아래 두고, 재연결과 터널 손실을 시험하며, 정책을 폐기할 때는 정확한 항목만 제거하세요. 별도 인터페이스와 별도 상태가 정말 필요하다면 namespace는 여전히 쓸 수 있습니다.