두 번째 공유기를 VPN 게이트웨이로 쓸 때: 해결하지 못하는 것

메인 공유기 뒤에 두 번째 공유기를 두는 것은 일부 기기에 다른 출구를 주는 깔끔한 방법입니다. 동시에 기기가 제공하는 것보다 더 많은 격리를 기대하게 되는 지점이기도 합니다. 메인 네트워크는 평소 경로를 유지하고, 하위 네트워크는 두 번째 공유기의 정책을 따릅니다. 둘 사이에서 무슨 일이 일어나는지, 그리고 터널이 끊길 때 무슨 일이 일어나는지가 계획해 둘 만한 부분입니다.

구성은 동작합니다. 신화는 그것이 무엇을 보호하는지에 관한 것입니다. 여전히 유용한 설계이지만, 그 자체로 보안 경계는 아닙니다.

신화: 두 번째 공유기가 터널을 완전히 격리한다

두 번째 게이트웨이 뒤의 기기는 그 정책을 따릅니다. 메인 네트워크의 기기는 그 터널을 상속하지 않으며, 바로 그게 핵심입니다. 그러나 두 번째 공유기에는 여전히 첫 번째를 거치는 상류 경로가 있고, 그 경로는 관리해야 하는 관계입니다.

두 번째 공유기에는 VPN 클라이언트 프로필도 필요합니다. 들어오는 VPN 연결만 받아들이는 기능은 공급자로 나가는 터널을 만들지 않습니다. 하드웨어를 사기 전에 펌웨어의 클라이언트 지원을 확인하세요.

하위 네트워크에는 겹치지 않는 서브넷을 주세요. 기존 네트워크를 확인하지 않고 예제 범위를 복사하는 것은 라우팅 퍼즐을 만드는 확실한 방법입니다.

신화: 이중 NAT는 VPN 자체의 캡슐화일 뿐이다

라우팅되는 두 게이트웨이는 이중 NAT를 만들 수 있으며, 이는 VPN 자체의 캡슐화와는 별개입니다. 일반적인 나가는 트래픽은 대개 동작합니다. 들어오는 서비스 접근에는 의도적인 설계가 필요하며, 흔히 두 기기 모두에서 포트 포워딩을 하거나 전혀 다른 접근 방식을 씁니다.

추가 번역 계층은 로그 읽기도 어렵게 만듭니다. 메인 공유기 로그의 출발지 주소가 디버깅 중인 기기가 아니라 두 번째 공유기의 것일 수 있습니다. 유령 기기를 쫓기 전에 알아 둘 만합니다.

무엇이든 켜기 전에 주소 계획을 적어 두세요.

신화: 두 LAN 모두 브라우징이 잘 되니 검색도 통과한다

두 네트워크 모두 인터넷을 브라우징할 수 있지만 그들 사이의 검색은 실패합니다. 메인 Wi-Fi의 휴대폰이 VPN 게이트웨이 뒤의 TV를 찾지 못할 수 있는데, 멀티캐스트 검색이 기본적으로 라우팅 경계를 넘지 않기 때문입니다. 그것이 중요하다면 리플렉터나 다른 토폴로지가 필요합니다. 브라우징 성공은 로컬 검색의 증거가 아닙니다.

두 번째 공유기의 관리 인터페이스를 WAN에 공개하지 않고 승인된 경로에서 접근할 수 있게 유지하세요. 경로를 바꾸기 전에 두 게이트웨이의 구성을 저장하세요.

보이는 출구 주소뿐 아니라 DNS와 IPv6도 시험하세요. IPv4만 전달하는 터널은 다른 체계를 누설할 수 있습니다. 두 결과를 변경 기록에 적으세요.

두 번째 게이트웨이가 실제로 주는 것

범위를 눈에 보이게 만듭니다. 기기 하나를 가리켜 어느 네트워크가 터널을 따르는지 말할 수 있고, 가정은 평소 경로를 유지합니다. 그 명확성은 많은 가정에서 추가 하드웨어의 값어치가 있습니다.

자격 증명, 펌웨어, 복구 절차를 갖춘 또 하나의 관리 대상 기기입니다. VPN이 끊길 때 하위 기기가 멈춰야 하는지 되돌아가야 하는지 정하고 그 동작을 시험하세요. 게이트웨이는 운영 작업을 없애지 않고 집중시킵니다. pfSense WireGuard 클라이언트 레시피는 흔한 한 플랫폼에서 터널 쪽을 다룹니다.