집으로의 접속은 하나의 사설 서비스이며 두 번째 인터넷 출구가 아닙니다. WireGuard는 라우터 뒤의 Linux 상자에서 종료되고, 라우터는 기존 역할을 유지하며, 노트북은 집 프리픽스만 터널로 보냅니다. 어느 장비가 전달하고 어느 장비가 종료하는지가 이후 모든 규칙이 따르는 결정입니다. 이 분담을 잘못하면 추가할 생각이 없던 NAT를 디버깅하게 됩니다.

누가 전달하고 누가 종료하는지 정하십시오

공인 진입점은 라우터가 가집니다: 라우터가 UDP 패킷을 받아 Linux 호스트로 넘깁니다. 그 호스트가 WireGuard 리스너와 LAN으로의 전달 결정을 가집니다. 실제로는 매핑이 UDP 51820을 192.168.50.10으로 보내고, 애플리케이션 자체의 포트는 닫힌 채로 남습니다. 역할을 분리해 두면 방화벽이 짧게 유지됩니다.

인터페이스를 만들기 전에 주소 계획을 작성하십시오. 라우터 192.168.50.1, 게이트웨이 192.168.50.10, 서비스 192.168.50.20, 터널 10.77.0.0/24(게이트웨이 .1, 노트북 .2). 터널 범위는 노트북이 이미 도달하는 네트워크와 겹쳐서는 안 되며, 그러면 목적지가 모호해집니다. 통신사급 NAT나 상위 라우터가 들어오는 접속을 막을 수 있고, 어떤 로컬 포트 포워딩도 그것을 고치지 못합니다.

키를 교환한 다음 AllowedIPs의 크기를 정하십시오

끝점마다 별도의 키 쌍을 만들고 검증된 경로로 공개 키만 옮깁니다. 게이트웨이의 peer 항목은 노트북의 터널 출발지만 허용하는데, 집 LAN이 노트북 뒤가 아니라 게이트웨이 뒤에 있기 때문입니다. 그 항목에 LAN을 넣으면 구축하지 않은 토폴로지를 서술하게 됩니다.

[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64

[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32

AllowedIPs는 집 프리픽스에 게이트웨이의 터널 주소를 더한 것이며 결코 0.0.0.0/0이 아니므로, 평범한 브라우징은 로컬 경로를 유지합니다. 설정 소유자는 한 사람으로 두고, 같은 인터페이스를 두 번째 네트워크 관리자에 절대 연결하지 마십시오.

돌아오는 경로야말로 사람들이 건너뛰는 부분입니다

이 설계는 노트북의 출발 주소 10.77.0.2를 게이트웨이로 위장하지 않고 유지하므로, 집 장비들이 그 주소로 응답하는 방법을 알아야 합니다. 집 라우터에 10.77.0.0/24에 대한 정적 경로를 다음 홉 192.168.50.10으로 추가하고, wg-quick이 AllowedIPs에서 무엇을 이끌어내는지 그 참조 문서에서 읽으십시오. 그 경로가 없으면 완료된 핸드셰이크는 결코 도착하지 않는 애플리케이션 응답과 함께 존재합니다.

라우터가 그 경로를 나를 수 없다면 문서화된 반환 설계를 고르십시오. 조용히 NAT를 더하는 것은 방금 적은 출발 주소 모델을 바꾸는 일입니다.

서비스 하나를 허용하고 서브넷을 허용하지 마십시오

게이트웨이에서 IPv4 전달을 켜고 방화벽의 세 가지 의무를 분리해 두십시오: WireGuard 리스너를 통과시키고, 노트북 출발지를 192.168.50.20으로만 전달하고, 집 네트워크의 나머지는 그 peer에게 닫아 둡니다. 규칙은 이미 쓰는 방화벽 관리자에 통합하고 비우지 마십시오. 집 프리픽스 전체에 대한 경로는 그 안의 모든 장비를 쓸 권한이 아닙니다.

애플리케이션 자체의 인증과 호스트 방화벽은 별개의 관문입니다. 규칙 집합이 허용하는 서비스를 이름으로 지정해, 다음 검토자가 의도한 작업과 대조할 수 있게 하십시오.

밖에서 시험한 뒤 깔끔하게 철수하십시오

프로파일은 소유자의 절차로 올리고 핸드셰이크를 확인한 뒤, 승인된 외부 네트워크에서 의도한 애플리케이션을 실행해 응답을 확인합니다. 허용 규칙은 무엇인가가 쓰기 전까지 보이지 않으므로 거부된 채로 남아야 하는 집 서비스도 시도하십시오. HTTPS에서는 인증서의 이름을 쓰고 검증을 돌리되, 원시 주소를 입력해 경고를 넘기는 일은 경로에 대해 아무것도 증명하지 못합니다. PersistentKeepalive는 선택 사항으로, 유휴 시간 뒤 NAT에 묶인 peer에 도움이 되지만 빠진 경로도 권한 수정도 아닙니다.

동적 공인 주소에는 DNS 갱신이 필요하고, 노트북은 변경 뒤 끝점을 다시 해석해야 하는데, 새 DNS 레코드가 설정된 끝점을 옮기지는 않습니다. 노트북은 저장된 설정과 활성 설정에서 그 peer를 제거해 철수하되, 노트북 프로파일만 지우는 것으로는 게이트웨이의 인가가 취소되지 않습니다.

관련 글