라우터 관리 페이지는 소파에서는 두 초 만에 열리지만 호텔 방에서는 시간 초과가 됩니다. 그동안 VPN 클라이언트는 계속 연결됨을 보고합니다. 당신에게 있는 것은 나가는 길이지 돌아오는 길이 아닙니다. 터널은 트래픽을 인터넷까지 실어 나르고 거기서 멈춥니다. 자신의 LAN 안에 있는 장치에 닿으려면 그쪽으로 경로가 있는 무언가에서 끝나는 세션이 필요합니다. 이것은 설정이 아니라 설계 결정이며, 나머지 작업이 애초에 가능한지를 좌우합니다.

이 구분을 잃기 쉬운 이유는 한 제품이 두 작업을 모두 할 수 있기 때문입니다. 상용 출구 클라이언트와 원격 액세스 서버는 같은 포트에서 같은 프로토콜을 말할 수 있고, 차이는 엔드포인트 뒤의 주소 공간을 어느 쪽이 소유하느냐입니다.

터널의 어느 쪽이 LAN을 소유하는가

관리를 위해서는 엔드포인트가 도달하려는 네트워크 안에 있어야 하거나 그쪽으로 승인된 경로를 가져야 합니다. 자체 VPN 서버를 돌리는 라우터는 조건을 충족합니다. 고정 주소와 LAN으로의 경로를 가진 작은 상시 가동 호스트도 마찬가지입니다. 제삼자가 운영하는 출구 서비스는 충족하지 못합니다. 그 엔드포인트에는 당신의 LAN에 인터페이스가 없고, 하나가 나타나도록 허용하는 규칙도 없기 때문입니다. 다른 무엇을 건드리기 전에 이 확인을 끝내야 합니다.

펌웨어는 이런 차이에 거의 라벨을 붙이지 않으므로 어떤 프로토콜인지가 아니라 그 기능이 무엇을 하는지 읽으세요. WireGuard, OpenVPN 및 IKEv2는 모두 시장 양쪽에 나타납니다. 한 빌드는 가정의 트래픽을 밖으로 보내고, 다른 빌드는 당신의 원격 장치를 받아들입니다. 클라이언트 전용 빌드는 메뉴가 어떻게 쓰였든 설정으로 서버가 될 수 없습니다.

돌아오는 경로를 존재하게 만들기

라우터의 WireGuard 서버에는 10.8.0.1/24 같은 인터페이스 주소와 노트북용 피어 항목이 있습니다. 클라이언트는 어떤 목적지를 터널로 보낼지 결정하며, 터널 서브넷만 담은 목록은 서버가 어떻게 구성되어 있든 LAN을 보이지 않게 남깁니다. 양쪽 끝이 합의해야 하며, 보통은 둘 중 하나만 편집됩니다.

wg show wg0 allowed-ips
ip route get 192.168.1.1

첫 번째 명령은 서버 관점에서 각 피어가 무엇을 보낼 수 있는지 보고합니다. 두 번째는 LAN 주소가 클라이언트에서 실제로 어디로 갈지 보고합니다. 터널 인터페이스로 해석되는 LAN 목적지는 작동하는 라우팅이고, 물리 게이트웨이로 나가는 목적지는 방화벽이 무슨 말을 하든 결코 도착하지 않습니다. 클라이언트의 허용 목록에 LAN 접두사를 추가하면 같은 두 명령이 진단이 아니라 검증 단계가 됩니다.

IPsec 게이트웨이에 대한 같은 도약은 strongSwan의 포워딩 문서가 설명합니다. 여기서 포워딩과 source-NAT 규칙이 터널 클라이언트를 내부 호스트에 연결합니다. 주소 지정은 다르지만 요구 사항은 같습니다.

누가 관리 페이지를 열 수 있는가

접근 제어는 조심하겠다는 의도가 아니라 라우터에 속합니다. 페이지가 필요한 인증된 터널 신원이나 소스 범위에만 허용하고, 라우터 자체의 입력 체인과 전달된 LAN 정책을 함께 읽으세요. 유선 LAN이 관리 페이지에 도달하도록 허용하는 규칙은 터널 인터페이스로 오는 클라이언트에 대해 아무 말도 하지 않습니다. 특정 신원에 대한 예외를 쓰고, 그다음 거부되어야 할 두 번째 신원을 유지하세요.

리스너는 나머지 절반이며 방화벽 출력에서는 보이지 않습니다. ss -ltnp 웹 서버가 바인딩된 주소를 보여주며, LAN 주소에만 바인딩된 서비스는 규칙이 아무리 관대해도 터널 주소에서 응답하지 않습니다. 다시 바인딩하거나 주소를 추가하는 것은 라우터의 구성 변경이지 방화벽 변경이 아닙니다.

인증과 전송 검증을 같은 과정에서 켜 두세요. 도달 가능은 신뢰가 아니다, 터널 안의 모든 장치가 그로 인해 관리자가 되는 것은 아닙니다. 터널 자격 증명과 라우터 계정은 수명 주기가 다른 별개의 권한이므로, 잃어버린 노트북의 키를 모든 관리자의 비밀번호를 재설정하지 않고 폐기할 수 있습니다.

소파가 아니라 외부에서 시험하기

당신이 통제하지 않는 네트워크에서 시험하세요. 승인된 터널로 연결하고 새 관리 세션을 열고, 페이지에 반영되는 것을 볼 수 있는 무해한 변경을 하세요. 소파에서는 LAN이 작동함을 증명하는데, 그것은 의심된 적이 없습니다.

그다음 같은 주의로 거부를 시험하세요. 터널 없이 페이지를 열어 보고 실패하는지 확인하고, 관리 서비스가 WAN 주소에서 전혀 수신하지 않는지 확인하세요. 링크만 없는 페이지는 접근 제어가 아니며, 로그인 양식을 보여주는 WAN 리스너는 여전히 WAN 리스너입니다. 인터넷과 라우터 콘솔 사이에 비밀번호만 있다면 설계는 비밀번호입니다.

그곳에 있는 동안 가정 서비스도 살펴볼 만합니다. 관리 규칙을 강화하면 게스트 네트워크나 가족 장치가 쓰는 리졸버가 자주 깨지고, 그것은 며칠 뒤 무관한 불만으로 드러납니다.

변경하는 동안 돌아올 길을 유지하기

원격에서 경로나 터널 설정을 바꾸기 전에 독립적인 돌아올 길을 준비하세요. 기존 세션은 이미 새 연결을 차단하는 변경을 견딜 수 있으며, 사람들이 아직 작동하는 세션을 보면서 스스로를 잠그는 방식이 바로 이것입니다. 선택지는 구체적입니다. 알려진 구성으로의 예약 재부팅, 콘솔 또는 물리적 접근, 편집 중인 설정에 의존하지 않는 두 번째 터널, 하드웨어가 제공한다면 대역 밖 관리입니다. 하나를 골라 유지보수 창 이전에 증명하세요.

기록은 짧고 최신으로 유지하세요. 어느 호스트가 터널을 종료하는지, 어떤 신원이 페이지에 도달할 수 있는지, 서비스가 어느 주소에 바인딩되는지, 잃어버린 장치를 어떻게 폐기하는지입니다. 그 목록은 복구 계획도 겸합니다. 각 의존성이 어디에 있는지 말해 주기 때문입니다. 빠진 돌아오는 경로는 고쳐야 할 라우팅 문제이며, WAN에 관리를 공개할 이유는 결코 아닙니다.

관련 글