테스트 LAN 하나에 전용 WireGuard 출구를 주는 방법

세 가지 설계가 같은 실험실 문제를 풉니다. 작은 LAN은 WireGuard 피어를 통해 나가야 하고 게이트웨이 자체는 평소의 상향 회선을 유지해야 합니다. 솔깃한 지름길은 라우터의 기본 경로를 터널 안으로 옮기는 것이지만, 그러면 장비 자체의 관리 경로와 그것이 전달하는 나머지 전부가 깨집니다. 흥미로운 선택지는 하나의 인터페이스와 하나의 프리픽스로 한정한 정책 라우팅이며, 실제로 가진 장비에 관한 세 가지 질문에 답해 둘 중에서 고르면 됩니다.

출구가 어디에 살지 정하십시오

첫 번째 질문은 이 호스트가 다른 무엇인가를 위해 전달하는가입니다. 전용 실험실 게이트웨이라면 기본적으로 모두 버리는 전달 정책으로도 살 수 있습니다. 운영 업무를 맡은 라우터는 그럴 수 없고, 관리형 방화벽 위에 경쟁하는 규칙 집합을 겹치는 것은 장애를 일정에 올리는 바로 그 방식입니다. 두 번째는 재부팅을 넘어 두 개의 정책 객체와 그 순서를 소유할 수 있는가입니다. 세 번째는 가진 피어가 터널 소스 주소를 인증 요구하고 인터넷 출구를 제공하는가입니다. 사설 네트워크만 노출하는 피어는 다른 제품이며 어떤 로컬 라우팅 변경으로도 고쳐지지 않습니다. 어느 답이든 아니오라면 출구를 대신 이름 공간이나 일회용 가상 머신에 두십시오.

이름 공간이나 VM은 메모리를 쓰고 깨끗한 폭발 반경을 줍니다. 정책 라우팅은 규칙 두 개를 쓰고 디버깅할 장비 하나를 남깁니다.

소스를 인증 요구하는 출구를 고르십시오

이 실험실의 실패 대부분은 방화벽 규칙이 하나도 생기기 전에 일어납니다. 출구 운영자는 변환 뒤에 패킷이 지니는 소스 주소를 받아들여야 하고, 이 설계에서 그것은 LAN 프리픽스가 아니라 터널 주소입니다. 그래서 매스커레이딩은 나중에 덧붙이는 것이 아니라 처음부터 설계에 들어갑니다.

운영자와 세 가지를 확인하십시오. 피어가 터널 주소를 인증 요구하는지, 스스로 종료하지 않고 IPv4를 전달하는지, 출구 NAT를 적용하는지입니다. 첫째가 없으면 패킷은 도착해 사라지고, 셋째가 없으면 사설 소스로 나가 다음 홉에서 죽습니다. 그다음 wg-quick이 자체 기본 경로를 넣지 않는지 확인해야 하는데, 이를 막는 것이 Table = off이고 이 설정이 억제하는 것은 경로 생성이지 피어의 AllowedIPs 검사나 DNS 처리가 아닙니다.

두 개의 정책 객체가 조향을 맡습니다

조향에는 테이블과 규칙이 필요합니다. 테이블은 LAN 인터페이스로 나가는 LAN 프리픽스와 터널로 나가는 기본 경로, 두 경로를 담습니다. 규칙은 LAN 인터페이스에 도착해 그 프리픽스를 지닌 트래픽을 테이블로 보냅니다. 소스 일치와 함께 iif 선택자를 써야 하는데, 게이트웨이 자체의 WireGuard 패킷은 로컬에서 생기므로 들어오는 인터페이스와 결코 일치하지 않습니다.

가드는 조회 뒤가 아니라 앞에 옵니다. 그 순서가 이 설계의 안전 속성 전부입니다.

가드는 같은 선택자 위의 두 번째 규칙이고 그 판정은 unreachable입니다. 터널이 올라와 있는 동안 조회가 계속 이기도록 더 높은 숫자 우선순위를 주십시오. 터널 경로가 사라지면 조회는 아무것도 돌려주지 않고, 가드가 탐색을 멈추어 메인 테이블의 WAN 기본 경로로 빠지지 않게 합니다.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

폴백 틈은 열기 전에 닫으십시오

가드를 먼저 설치하고 조회를 나중에 설치하십시오. 반대로 하면 몇 초짜리 창이 남고, 그동안 테스트 클라이언트의 트래픽이 상향 회선에 닿을 수 있습니다.

필터가 그림을 완성합니다. forward 훅에서 테스트 프리픽스에 대해 LAN에서 터널로 가는 방향과 이미 성립된 반환 방향을 허용하고 나머지는 모두 버리며, 그 프리픽스를 터널 인터페이스로 보내는 NAT는 postrouting에 둡니다. 포워드 체인에 policy drop을 남기는 것이 사라진 경로를 유출이 아니라 침묵으로 바꿉니다. 역경로 필터링은 캡슐이 벗겨져 도착하는 공인 소스의 최선의 역경로가 WAN 쪽에 있기 때문에 터널 인터페이스에서 느슨한 모드를 요구합니다. Linux는 all 값과 인터페이스별 값 중 높은 쪽을 택하므로, 터널 인터페이스를 설정하는 것은 모든 곳에서 검증을 약화하는 것과 같지 않습니다.

실패 사례로 증명하십시오

클라이언트의 소스 주소와 그것이 도착하는 인터페이스를 지목해 커널에 정확한 질문을 던지십시오. 둘 다 없이 하는 조회는 다른 질문에 답하므로 어느 경우든 맞아 보입니다. 그다음 방화벽 카운터, 피어의 전송 상태, 클라이언트 자체의 서비스를 보십시오.

철거를 제대로 시험하십시오. 규칙과 필터를 그대로 둔 채 터널을 멈추면 클라이언트는 멈추고 게이트웨이 자체 트래픽은 계속 동작해야 합니다. 다음으로 로컬 인터페이스를 건드리지 않고 피어를 멈추는 것이, 경로의 존재만 믿는 설계를 잡아내는 바로 그 경우입니다. 마지막으로 재부팅하고 규칙 순서를 다시 확인해야 하는데, 가드를 제거하는 철거 훅이 설계 전체를 메인 테이블로 되돌리기 때문입니다. 테이블 번호, 우선순위, 인터페이스 이름은 다음에 규칙을 추가하는 사람이 이것을 깨뜨릴 사람이므로 변경 티켓에 기록하십시오.