WireGuard 터널 밖으로 웹사이트 하나를 라우팅하는 방법

호스트 이름을 제외하는 것은 터널이 할 수 없는 일이다. 하지만 경로는 단일 주소 하나를 터널 밖으로, 집 게이트웨이를 통해 내보낼 수 있고, 사이트 하나라면 보통 그걸로 충분하다. 걸림돌은 경로 이후의 모든 것이 합의해야 한다는 점이다. 방화벽은 패킷을 내보내야 하고, DNS는 라우팅한 주소를 돌려줘야 하며, 사이트는 계속 그 주소를 사용해야 한다. 셋 중 하나라도 어긋나면 예외는 스스로 알리지 않은 채 작동을 멈춘다.

터널을 건드리기 전에 목적지 주소를 읽어라

터널을 켠 상태에서 사이트를 한 번 불러오고, 브라우저가 실제로 연결한 피어 주소를 확인한다. Linux에서는, ss -tunp 열린 모든 소켓의 원격 주소를 나열하고, dig +short 같은 이름에 대해 리졸버가 무엇을 반환했는지 보여 준다. 두 숫자를 모두 눈앞에 두어라.

두 응답은 자주 일치하지 않으며, 그 불일치가 문제의 전부다. 대형 사이트는 원본 앞에 콘텐츠 네트워크를 두므로, 리졸버가 지금 반환하는 주소가 브라우저가 일 분 전에 사용한 주소가 아닐 수 있다. 예전 안내서에 적힌 것이 아니라 소켓에서 관찰한 것을 라우팅하라. 응답이 지역마다 계속 돌아간다면, 그 특정 사이트에는 주소 예외가 잘못된 도구다.

다른 네트워크에서 조회를 한 번 더 실행하고, IPv4 응답과 함께 IPv6 응답도 기록한다. 두 체계를 모두 전달하는 터널은 양쪽 모두에 예외가 필요하다. 그렇지 않으면 브라우저는 건드린 적 없는 IPv6 경로로 조용히 되돌아간다. 주소와 날짜는 나중에 다시 볼 곳에 적어 두어라.

클라이언트에 호스트 경로 하나를 놓아라

인터페이스 이름이 home-wg이고 LAN 라우터가 192.168.1.1에 있다고 하자. NetworkManager는 게이트웨이가 그 라우터이고 프리픽스 길이가 32비트 전체를 덮는 경로를 받아들이며, 커널은 가장 긴 프리픽스가 이기기 때문에 그 경로를 선호한다.

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

게이트웨이는 터널 없이 도달할 수 있어야 하고, 다음 홉을 터널 주소로 지정하면 피하려는 인터페이스로 패킷이 다시 들어가기 때문에 목적이 무너진다. 연결이 다시 올라오면, ip route get 예외에 대해서는 LAN 게이트웨이가 출력되어야 하고, 공용 리졸버에 대한 같은 명령은 여전히 터널 장치를 출력해야 한다.

wg-quick 프로필에는 경로 필드가 없으므로, 같은 예외는 PostUp 줄에 들어 있다. 이 줄은 호스트 경로를 LAN 인터페이스를 장치로 삼아 메인 테이블에 추가한다. 편집한 뒤에는 실행 중인 인터페이스가 파일을 다시 읽지 않으므로 인터페이스를 내렸다가 다시 올려야 한다. wg-quick이 설치하는 fwmark 규칙은 자신이 캡슐화한 패킷만 인도하므로, 일반 브라우저 트래픽은 여전히 메인 테이블을 따라가 /32를 찾는다.

킬 스위치가 다음으로 그것을 막는다

터널 인터페이스에서만 트래픽을 허용하는 방화벽 정책은 경로가 정확히 맞더라도 예외를 버린다. 스위치를 믿는 대신 스위치 뒤의 규칙을 읽어라. 킬 스위치를 구현하는 규칙은 보통 인터페이스 이름으로 한정되기 때문이다.

원하는 것은 물리 인터페이스와 그 하나의 목적지에 대한 좁은 허가를 드롭 앞에 두는 것이며, 기본 정책은 그대로 두어야 한다. 킬 스위치를 전부 일시 중지하면 요점은 증명되지만, 다시 켜는 것을 잊는 동안 기계를 노출시킨다.

두 방향을 따로 시험하라. 예외 주소로의 요청은 성공해야 하고, 무관한 사이트로의 요청은 여전히 터널을 통해 나가야 한다. 둘 다 성공하지만 두 번째가 집 주소를 보고한다면, 잘못된 것은 방화벽 규칙의 순서이지 경로가 아니다.

브라우저가 어느 주소로 접속할지는 DNS가 결정한다

이름이 터널 안에서 해석되면, 제공자의 리졸버는 로컬 리졸버가 준 것과 다른 주소로 응답할 수 있다. 그러면 경로는 브라우저가 접속하지 않는 주소에 적용되고, 페이지는 아무것도 바뀌지 않은 듯 터널을 통해 로드된다. 라우팅 테이블이 맞더라도 이 실패는 깨진 예외처럼 보인다.

그 이름의 쿼리도 로컬 리졸버를 통해 보내거나, 이름을 완전히 건너뛰고 주소를 직접 시험하라. DNS를 터널 안에 둔 채 주소를 분리하는 것은 이 설정에서 가장 흔한 반쯤 끝난 형태이며, 알아채기도 가장 어렵다. 사이트는 계속 작동하되, 의도한 방식대로만 작동하지 않기 때문이다.

라우터에서도 같은 예외를, 한 번, 모든 장치에

터널이 라우터에서 실행 중이면 호스트 경로는 라우터의 정책 라우팅 테이블에 속하며 LAN 게이트웨이 대신 WAN 게이트웨이를 가리킨다. 그 뒤의 모든 장치가 예외를 상속하며, 이는 스트리밍 박스나 네트워크 설정을 바꿀 수 없는 업무용 노트북에 중요하다.

다른 모든 클라이언트에는 터널을 기본 출구로 남겨 두고, 라우터 콘솔이 아니라 클라이언트 머신에서 확인하라. 같은 브라우저 세션에서 예외 사이트와 두 번째 사이트를 불러오고 출구 주소를 비교하라. 두 번째가 여전히 터널을 보여 준다면, 정책 테이블은 요청한 대로 동작하는 것이다.

라우터의 메모에 주소, 날짜, 이유를 적어 두어라. 나중에 옮겨 가는 주소를 둘러싸고 만든 예외는 일 년 뒤 아무도 설명할 수 없는 결함이 되며, 누군가 옛 메모를 찾을 때까지 수정은 늘 수수께끼처럼 보인다.