가정용 NAT가 VPN 인터페이스를 보호하지 못하는 이유
가정용 라우터는 터널을 전달하지만, 복호화된 패킷을 판단하는 것은 호스트입니다. 리스너, 내부 경로, 인바운드 정책을 따로 읽으십시오.
가정용 라우터 뒤에서 포트 포워딩을 하지 않은 노트북도 VPN으로 들어오는 SSH 연결은 여전히 받아들입니다. 이것은 모순이 아니라, 서로 다른 두 장치가 서로 다른 두 패킷을 판단하기 때문입니다. 라우터는 암호화된 전송을 전달하고, 호스트는 자신의 터널 인터페이스에 도착한 복호화된 패킷을 어떻게 처리할지 결정합니다. 이 두 결정을 분리해서 보는 것이 이 연습의 전부입니다.
라우터는 터널을 전달하고, 호스트는 패킷을 판단한다
규칙을 하나라도 보기 전에 원격 출발지에서 서비스까지의 경로를 그려 보십시오. 바깥 구간은 VPN 전송이며 라우터와 게이트웨이가 처리합니다. 안쪽 구간은 엔드포인트가 터널 계층을 벗겨 내고 호스트가 자신의 VPN 주소로 향한 패킷을 받을 때 시작됩니다.
이 두 구간을 합치면 호스트가 내리는 결정의 공은 라우터에게 돌아갑니다. 포트 포워딩 페이지나 라우터 로그는 바깥 대화만 설명하며, 어느 것도 호스트가 어떤 복호화된 트래픽을 받아들일지 말하지 않습니다. 호스트는 내부 패킷에 자신의 인바운드 정책을 적용하고, 인터페이스에 도착하는 어느 패킷에나 마찬가지입니다. 노출 문제가 실제로 판가름 나는 곳이 바로 그 정책입니다.
와일드카드 리스너는 공개 서비스가 아니다
Linux에서 INADDR_ANY에 바인딩한다는 것은 모든 로컬 주소를 뜻하므로, 서비스는 한 번도 이름 붙이지 않은 터널 인터페이스에서 응답할 수 있습니다. IP 소켓 참조 문서가 그 바인딩을 설명하며, 리스너 목록에서 결론을 내리기 전에 읽어 볼 가치가 있습니다. 와일드카드 항목은 소켓에 관한 사실이고, 도달 가능성에 관한 주장이 아닙니다.
아래 두 줄은 같은 서비스의 서로 다른 두 바인딩이며, 그 차이가 인터페이스가 중요한지에 대한 답의 전부입니다. 무엇보다 먼저 소켓이 어느 주소에 앉아 있는지 읽으십시오.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))그 포트에 닿을 수 있는 배치를 지목한다
세 가지 배치가 그 인터페이스에 패킷을 올리며, 소유자가 각각 다릅니다. 올바른 것을 지목하는 일이 누가 정책을 바꿔야 하는지를 결정합니다.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
공인 출구 주소를 보여 주는 브라우저 결과는 세 가지 중 어느 것에 대해서도 말해 주지 않습니다 — 나가는 트래픽이 어떻게 나가는지를 설명할 뿐, 들어오는 트래픽에 무엇이 허용되는지는 말하지 않기 때문입니다. 대신 리스너와 서비스 로그의 출발지 주소에서 거꾸로 작업하십시오. 출발지가 다른 터널 피어라면 흥미로운 문서는 게이트웨이 정책입니다. 변환된 주소라면 규칙을 바꾸기 전에 변환을 찾으십시오.
서비스를 의도한 경로로 한정한다
SSH가 관리 경로에서만 필요하다면 그 경로를 출발지 범위와 인터페이스로 적어 두십시오. 그다음 호스트의 인바운드 규칙을 네트워크 이름이 아니라 인터페이스, 목적지, 출발지로 한정하십시오 — 사설처럼 보이는 이름이 어떤 주소든 가리킬 수 있기 때문입니다. 다음 문제를 고칠 사람을 위해 경로를 남겨 두십시오.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input터널 인터페이스와 관리 범위를 지목하는 규칙은 의도를 한곳에 적습니다. Wi-Fi 네트워크를 위해 쓴 규칙과 비교해 보십시오 — 그 규칙은 복호화된 터널 트래픽에 대해 아무 말도 하지 않습니다. 두 계층이 어긋날 때 패킷이 마주치는 것은 호스트 정책입니다.
로그인과 패치는 있는 그대로 두고, 포트에 닿는 것은 그것을 쓸 허가를 받는 것과 결코 같지 않았습니다. 낯선 출발지마다 주소 체계와 시각을 기록하고, 기능이나 취약점을 탓하기 전에 조사하십시오. 모든 터널 피어를 들이는 규칙은 관리 서브넷을 들이는 규칙과 다른 설계이며, 어느 쪽이 의도였는지 로그 한 줄이 알려 주지는 않습니다.
성공 하나와 거부 하나로 수정을 받아들인다
두 절반을 모두 증명하십시오 — 승인된 연결 하나는 성공하고, 배제된 경로 하나는 거부되어야 합니다. 거부는 사람들이 건너뛰는 절반이며, 규칙이 허용적인 기본값 옆에 있는 것이 아니라 일하고 있음을 보여 주는 쪽입니다. 그것에 대해 따져 보는 대신 배제된 쪽에서 시험하십시오.
다시 연결한 뒤 이 쌍을 반복하십시오 — 다른 인터페이스 이름으로 돌아온 터널은 예전 이름에 한정된 규칙을 조용히 우회할 수 있기 때문입니다. 중요한 경계는 호스트가 실제로 받는 패킷에 적용하는 경계입니다.