정책 라우팅이 켜지기 전까지 LAN 클라이언트는 라우터 VPN을 무시한다

라우터는 터널을 통해 인터넷에 나가는데, 그 뒤의 노트북은 여전히 ISP 주소를 보고한다. 허용 규칙을 더해도 소용이 없고, 이 실패는 시사하는 바가 크다: 필터링은 패킷이 통과해도 되는지를 답할 뿐 어디로 가는지는 답하지 않는다. 인터페이스 선택은 클라이언트 목록을 전혀 모르는 라우팅 조회가 이미 끝낸 일이다. 조회를 고치면 방화벽은 더 이상 용의자가 아니다.

필터 규칙은 인터페이스를 고를 수 없다

리눅스 라우터의 패킷 흐름은 먼저 라우팅 결정을 수행하고 그다음 forward 훅을 지난다. 규칙이 나가는 터널 장치와 일치할 때쯤이면 커널은 이미 터널이 출구라고 정해 둔 상태다. 메인 테이블이 여전히 WAN 기본 경로를 선호하면 패킷은 ISP로 향하고, 방금 쓴 허용 규칙은 그것을 보지도 못한다. 이 한 가지 순서 사실이 새 방화벽 규칙 한 페이지가 아무것도 바꾸지 못하는 이유를 설명한다.

아래 예시는 br-lan의 192.168.8.0/24 LAN, 터널 장치 tun0, 그리고 터널을 써야 하는 192.168.8.23의 셋톱박스 하나를 사용한다.

규칙을 고치기 전에 조회 결과를 읽어라

커널에 그 클라이언트를 대신해 경로를 풀어 달라고 요청한다. 응답에는 나가는 장치와 선택될 소스 주소가 들어 있고, 진단을 확인하는 데 필요한 것은 그게 전부다. 응답이 WAN 장치를 지목하면 패킷은 당신의 규칙에 닿을 기회조차 없었다.

ip -4 route get 198.51.100.7 from 192.168.8.23

평소 경로에 남아야 할 클라이언트로 같은 질의를 반복한다. 두 응답이 같은 장치를 지목하면 소스별 정책은 아직 작동하지 않으며, 고칠 곳은 필터링이 아니라 라우팅이다.

대상으로 삼을 클라이언트에 테이블을 붙인다

정책 라우팅은 메인 테이블 앞에 규칙 조회를 끼워 넣는다. 기본 경로가 터널인 테이블을 만들고, 그 테이블을 선택자에 묶는다: 입력 인터페이스, 소스 주소 또는 방화벽 마크. 우선순위가 순서를 정하고 메인 테이블은 목록에서 훨씬 아래인 32766에 있어서 번호가 낮은 규칙이 먼저 조회된다. 인터페이스 선택자는 브리지의 모든 클라이언트를 덮고, 주소 선택자는 한 대의 기계를 덮는다.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

펌웨어 화면은 보통 정책 라우팅이나 VPN 정책 페이지와 같은 객체를 보여 준다. 거기의 장치 목록은 손으로 쓴 규칙보다 관리하기 쉽고 규칙 문법을 바꾸는 업그레이드에서도 대개 살아남는다.

선택자를 의도적으로 고른다. 인터페이스 규칙은 짧고 미래에도 안전하지만 그 브리지로 들어오는 라우터 자체의 관리 트래픽도 잡는다. 소스 규칙은 정확하지만 장치 목록이 바뀔 때마다 편집이 필요하다. 선택을 적어 두어라, 한 장치가 왜 다르게 동작하는지 묻는 다음 사람이 그것을 필요로 한다.

로컬 목적지를 터널 밖에 둔다

새 테이블은 당신이 넣은 경로만 안다. LAN 접두사가 없으므로 프린터와 NAS 트래픽은 터널 기본 경로를 따라가 사라졌을 것이다. throw 경로는 이 테이블에서 조회를 끝내고 결정을 메인 테이블로 되돌린다.

ip -4 route add throw 192.168.8.0/24 table 200

그 경로를 빼면 로컬 공유가 깨지고, 선택자가 의도보다 넓으면 라우터 자체의 관리 세션도 사라질 수 있다. 다음으로 소스 문제를 정리하는데, LAN 주소를 아직 지닌 터널 패킷은 반대편이 돌아올 경로를 알아야 하고, 터널에서 masquerading을 하면 그 요구가 사라지는 대신 반대편이 보던 클라이언트 신원도 사라진다.

실행 중에 추가한 규칙과 경로는 재부팅이나 펌웨어 업데이트 후 사라진다. 라우터의 시작 절차에 넣고 한 번 재부팅한 뒤 클라이언트에서 공인 주소, WAN에 남아야 할 두 번째 클라이언트, 새 연결 중의 터널 카운터를 다시 시험한다.