VPN 변경 후 라우터 관리 화면이 응답을 멈추는 이유

VPN 변경은 라우터의 관리 경로를 끊거나 조용히 넓힐 수 있습니다. 터널을 신뢰하기 전에 경로, 입력 규칙, 리스너를 확인하세요.

라우터에서 터널을 시험하려고 경로나 방화벽 규칙을 바꿨더니, 십 분 전까지 멀쩡하던 노트북에서 관리 화면이 응답하지 않습니다. 반사적으로 VPN을 의심하게 됩니다. 대개 터널은 건강하고 다음 세 가지 중 하나가 깨졌습니다. 라우터 자신의 주소로 돌아가는 경로가 없거나, 입력 정책이 요청을 버리거나, 호출하는 주소에서 웹 서비스가 듣고 있지 않은 경우입니다. 셋 다 브라우저에서는 똑같이 보이기 때문에 사람들은 한 시간 동안 터널을 재시작하고 아무것도 배우지 못합니다.

먼저 죽여야 할 신화는 이것입니다. 동작하는 터널은 다시 들어가는 길이 아닙니다. 그것은 자체적인 신뢰 질문을 가진 새 네트워크 연결이며, 아무도 검토하지 않은 새 경로를 열면서 기존 관리 경로를 조용히 제거할 수 있습니다.

터널은 관리 경로가 아니었다

포워딩과 입력은 다른 일입니다. "클라이언트가 터널을 통해 NAS에 닿을 수 있는가?"는 라우터를 지나가는 패킷에 대한 포워딩 질문입니다. "라우터의 SSH 포트를 열 수 있는가?"는 라우터 자체로 향한 패킷에 대한 입력 질문입니다. 포워딩된 트래픽을 위해 쓴 허용 규칙은 두 번째 질문에 아무 일도 하지 않으며, 트래픽을 완벽히 나르는 터널이 여전히 관리 세션을 거부하는 가장 흔한 이유입니다.

반대의 실수는 인터페이스 이름을 믿는 것입니다. 터널은 피어까지 암호화되며 그 뒤의 모든 서비스까지는 아닙니다. 인터페이스 레이블의 VPN이라는 단어는 어떤 출처가 로그인할 수 있어야 하는지에 대해 아무것도 말해 주지 않습니다.

첫 번째 계층: 라우터 자신의 주소로 가는 경로가 있는가

클라이언트에서 시작해 패킷이 어디로 갈지 커널에 물으십시오. Linux에서는 ip route get 10.6.0.1 가 선택된 경로, 나가는 인터페이스, 원본 주소를 출력합니다. 통신사 방향의 기본 경로가 나온다면 패킷은 터널에 들어가지 않으며, 라우터의 어떤 규칙도 그것을 구할 수 없습니다.

터널 쪽에는 이 질문의 자체 버전이 있습니다. WireGuard는 AllowedIPs를 암호 키 라우팅 테이블로 취급하여, 각 끝에서 피어가 쓸 수 있는 원본 주소와 그 피어로 보내는 목적지를 선언합니다. 클라이언트 항목에 라우터의 터널 주소가 없으면 클라이언트에는 그곳으로 가는 경로가 없습니다. 그 클라이언트에 대한 서버 항목이 클라이언트의 터널 주소를 덮지 않으면 서버는 어떤 방화벽 규칙도 보기 전에 패킷을 버립니다.

정책을 디버그하기 전에 도달하려는 정확한 주소를 확인하십시오. 오래된 DNS 레코드나 변경 전에 캐시된 이웃 항목은 라우터가 한 번도 가져본 적 없는 주소로 보냅니다.

두 번째 계층: 포워딩 정책이 아니라 입력 정책

방화벽은 패킷이 도착하는 인터페이스에서 규칙을 평가합니다. pfSense와 OPNsense에서는 인터페이스 탭과 규칙 순서가 방화벽 자체 서비스로 가는 트래픽의 허용 여부를 결정합니다. LAN 클라이언트를 인터넷으로 내보내는 규칙은 터널 피어에게 웹 GUI를 열게 하는 규칙이 아닙니다. firewall4가 있는 OpenWrt에서는 각 존이 입력 정책을 가지며, option input 'ACCEPT' 또는 'REJECT' 이고, 입력이 REJECT인 존의 터널 인터페이스는 관리 연결을 거부하면서도 포워딩이 허용되면 트래픽은 계속 포워딩합니다.

새 경로가 동작하게 하려고 잠금 방지 규칙을 끄지 마십시오. 그 규칙은 잘못된 규칙이 LAN 관리 주소를 잠그지 못하게 합니다. 보호하는 것은 LAN 서브넷이며, 방금 만든 터널 서브넷이 아닙니다. 관리자 출처에 대한 좁은 규칙 하나를 추가하고 안전망은 그대로 두십시오. pfSense의 관리자 접근 문서 가 그 제어 항목이 어디에 있는지 설명합니다.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

세 번째 계층: 그 주소에서 무언가 듣고 있는가

서비스가 실행 중이어도 하나의 주소에 바인딩되어 있어 도달할 수 없을 수 있습니다. OpenWrt의 uhttpd는 /etc/config/uhttpd 에 명시적 리스너 항목을 둡니다. 예를 들어 list listen_http '0.0.0.0:80' 이며, LAN 주소에만 바인딩하는 빌드는 터널 주소에서 아무것도 받지 않고 리스너 인터페이스 설정을 노출하는 제품도 같은 방식으로 동작하므로, 위의 리스너 명령이 이에 직접 답합니다.

다음으로 거부와 침묵을 구분하십시오. nc -vz 10.6.0.1 443 가 연결 거부를 돌려주면 패킷이 라우터에 도달했고 무언가가 거부한 것이며, 닫힌 포트이거나 명시적 거부 규칙입니다. 타임아웃까지 멈춰 있으면 패킷이 버려졌거나 아예 라우팅되지 않은 것입니다. 이 차이가 다음에 어느 계층을 볼지 알려 주고, 비용은 오 초입니다.

VPN 인터페이스는 경계이지 복구 경로가 아니다

암호화는 회선을 보호하지만 누가 관리 화면을 열 수 있는지에 대해서는 아무것도 말하지 않습니다. 터널이 동작하면 터널 인터페이스에서 모든 것을 허용해 도달성을 해결하려는 충동을 참으십시오. 관리자에게 자신의 터널 주소에 묶인 규칙이나 관리자 전용 별도 터널을 주고, 일반 사용자, NAS, 카메라, 가족 노트북을 관리 포트에서 멀리 두십시오. 파일 공유가 필요한 피어가 라우터 로그인에서 규칙 하나 거리에 있어서는 안 됩니다.

라우터의 역할이 답을 바꿉니다. 터널을 종료하는 라우터는 그곳에서 관리자를 정당하게 받아들일 수 있지만, 터널을 인터넷 출구로만 쓰는 라우터는 보통 그렇게 해서는 안 됩니다. 두 경우 모두 서브넷 허용은 로그인이 아니므로 계정 인증과 전송 보안을 켜 둡니다.

잠긴 뒤 사람들이 하는 보상 조치는 더 나쁩니다. WAN 관리를 켜거나 포트를 웹 GUI로 포워딩하는 것입니다. 이는 짧은 장애를 영구적 노출로 바꾸고, 로그인 페이지는 인터넷의 모든 스캐너에게 열리게 됩니다. 허용되는 쪽만이 아니라 거부되는 쪽도 시험해, 관리 접근이 없어야 할 피어가 로그인 요청 대신 타임아웃이나 거부를 받는지 확인하십시오.

새 연결로도 시험하십시오. 상태 저장 방화벽은 기존 흐름을 상태 테이블에 유지하므로, 이미 열어 둔 SSH 세션은 모든 새 연결을 차단하는 변경을 견딜 수 있습니다. 그래서 잠금은 다음 재부팅이나 다음 절전까지 보이지 않습니다.

정책을 건드리기 전에 돌아오는 길을 준비하십시오

첫 변경 전에 네 가지를 적으십시오. 터널이 죽으면 장치에 어떻게 닿을지, 예를 들어 시리얼 콘솔, 통신사 콘솔, LAN의 머신, 현재 설정을 어디로 내보내는지, 어떤 하나의 규칙이나 경로를 바꿀지, 그리고 그 항목을 정확히 어떻게 되돌릴지. OpenWrt에서는 sysupgrade -b /tmp/backup.tar.gz 이 설정을 잡고 편집은 uci commit 까지 보류되므로, 제때 알아차리면 값싼 되돌리기를 얻습니다. pfSense는 설정 기록을 유지하고 AutoConfigBackup은 이미 켜져 있었을 때만 도움이 됩니다. 라우터가 fail-closed 규칙 집합을 실행한다면 계획한 유지보수 경로가 그 규칙이 막는 트래픽 안에 없는지 확인하고, 재부팅은 지속 규칙을 지우는 것이 아니라 다시 적용한다는 점을 기억하십시오.

시도마다 경계 하나만 바꾸고, 열어 둔 셸이 아니라 새 연결에서 시험하십시오. 시험이 실패하면 다음 계층을 건드리기 전에 그 하나의 변경을 되돌리십시오. 터널은 내내 올라가 있어도 되지만, 초록 상태 아이콘은 여전히 들어갈 수 있다는 증거가 아닙니다.

떠나기 전 빠른 점검:

  • 방금 편집한 규칙에 의존하지 않는 출처에서 라우터에 닿을 수 있습니까?
  • 터널 인터페이스의 입력 정책이 관리자 출처만 허용합니까?
  • 관리 서비스가 터널에 존재하는 주소에 바인딩되어 있습니까?
  • 거부되는 피어 하나와 새 세션 하나를 시험했습니까?
  • WAN 관리 표면은 여전히 닫혀 있습니까?

관련 글