Pi의 핫스팟 클라이언트가 TUN VPN을 통해 집 LAN에 도달하지 못합니다

로컬 Wi-Fi 및 Ethernet 클라이언트는 Pi의 핫스팟에 연결되어 DHCP 범위에서 주소를 받고 불평 없이 인터넷 페이지를 불러옵니다. 그런데 같은 클라이언트가 집 LAN의 파일 공유나 웹 UI를 열면 시간 초과가 나고, Pi 자신은 터널을 통해 그 LAN에 도달합니다. 무선 계층에는 아무것도 깨져 있지 않습니다. 빠진 것은 라우팅된 계약입니다. 핫스팟 프리픽스를 TUN 인터페이스로 옮겨야 하고, 집 쪽의 무언가가 응답을 다시 보내는 방법을 알아야 합니다. 패킷 하나가 왕복을 마치려면 두 절반이 모두 있어야 합니다.

세 가지 역할을 하는 세 개의 연결

Linux Ethernet 브리지는 목적지 MAC 주소로 프레임을 전달합니다. OpenVPN TUN 모드에서는 IP 패킷을 나르고 MAC 계층이 전혀 없으므로 로컬 브리지를 추가해도 터널이 포트로 등록되지 않습니다. 커널 TUN/TAP 문서 는 그 분리를 설명합니다. TAP 장치는 Ethernet 인터페이스처럼 보이지만 TUN 장치는 그렇지 않습니다. 두 로컬 포트를 브리지한 뒤 라우팅하는 설계는 인터페이스 이름이 무엇이든 라우터입니다.

그 구분이 소유권을 결정합니다. 클라이언트의 서브넷, 기본 게이트웨이, 그 범위의 DHCP 권한은 Pi의 로컬 계획에 속합니다. 집의 DHCP 브로드캐스트는 라우팅된 터널을 건너지 않으며 어떤 브리지 설정도 그것을 바꾸지 않습니다. 클라이언트를 집 DHCP 서버로 향하게 하는 것은 자체 실패 모드를 가진 별개의 의도적인 릴레이 설계입니다.

모뎀도 클라이언트 브리지 밖에 두세요. PPP 연결은 다른 라벨을 붙인 Ethernet 장치가 아니며, pppd의 문서화된 기본 경로 로직은 IPCP 협상 후에 동작하고 그 링크가 끊기면 경로를 철회합니다. DHCP 템플릿을 복사하고 모든 usb0 를 ppp0 로 이름을 바꿔도 게이트웨이, 메트릭, 수명 주기에 대해 아무것도 증명하지 못합니다.

어떤 구성도 편집하기 전에 프리픽스를 고르세요

중복되는 프리픽스는 방화벽 규칙보다 더 많은 저녁을 낭비합니다. 터널이 건강해도 중복이 경로 조회를 잘못된 인터페이스로 보내기 때문입니다. Pi에 이미 있는 것을 나열하는 것으로 시작하고, 그 결과를 네 개의 별도 풀로 읽으세요.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

첫 번째 풀은 통신사가 모뎀에 준 underlay 주소이며, 클라이언트를 향한 모든 계획에서 빠져 있어야 합니다. 두 번째는 서버가 고른 터널 서브넷으로, 흔히 서버 자신의 사설 /24입니다. 세 번째는 핫스팟 브리지이고, 네 번째는 도달하려는 집 프리픽스입니다. 이번 실습에서 핫스팟은 172.28.90.0/24 를 받고 브리지는 172.28.90.1 에 있으며, 집 서비스 LAN은 192.168.77.0/24 를 유지합니다. 이는 소비자 라우터가 함께 제공하는 192.168.1.0/24 와 10.0.0.0/24 기본값과 통신사 대역 100.64.0.0/10 을 피합니다.

핫스팟의 DHCP 범위에서는 브리지 주소만 게이트웨이로 광고하고 다른 것은 광고하지 마세요. 핫스팟 클라이언트에 집 주소를 게이트웨이로 주면 안 됩니다. 그들은 그 세그먼트로 가는 링크 계층 경로가 없습니다.

각 방향을 그것을 소유한 쪽에서 라우팅하세요

Pi에는 터널을 통해 집 프리픽스로 가는 경로가 필요합니다. 서버 모드의 서버는 보통 그 경로를 푸시하므로 먼저 포워딩이 켜져 있고 커널이 tun0 에서 집 주소를 해석하는지 확인하세요.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get 가 여전히 underlay 인터페이스를 보고하면 거기서 멈추세요. 경로의 더 뒤에서는 잘못된 조회를 고칠 수 없습니다.

집 장치에는 172.28.90.0/24 로 가는 경로가 없으므로 응답은 기본 게이트웨이를 따라 라우터에서 죽습니다. 지원되는 두 가지 수리가 있습니다. 집 라우터에 핫스팟 프리픽스를 VPN 서버의 LAN 주소로 향하는 정적 경로를 추가하거나, 서버 자체가 게이트웨이일 때는 클라이언트 프리픽스를 서버 자체의 라우팅 테이블에 등록합니다. OpenVPN의 다중 클라이언트 모드에서는 클라이언트별 디렉터리가 그 연결을 담당합니다. 클라이언트 인증서의 일반 이름을 딴 파일에 iroute 172.28.90.0 255.255.255.0 와 그것을 서버 커널에 설치하는 대응 route 줄이 들어 있습니다. 서버에서 추측한 커널 경로는 어느 클라이언트가 프리픽스를 소유하는지 서버에 알려 주는 것과 같은 진술이 아닙니다.

이것이 동작하도록 집 네트워크의 DHCP 서비스를 VPN 서버로 옮기지 마세요. 집 전체의 기본 게이트웨이를 바꾸는 것은 사설 반환 경로 하나를 추가하는 것보다 훨씬 큰 변경이며, DNS, 주소 예약, 새 임대를 무시하는 모든 장치를 실패로 끌어들입니다.

방화벽을 추측하지 않고 포워딩을 여세요

포워딩이 켜져 있다고 패킷이 통과해도 된다는 뜻은 아닙니다. 브리지에서 터널로 가는 트래픽은 여전히 필터 규칙에 부딪히고, 기본 drop 포워딩 정책은 핫스팟 트래픽을 버리는 동안 Pi 자체 트래픽은 계속 동작하므로 위에서 설명한 분할 증상이 그대로 생깁니다.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 에서 tun0 로 가는 허용 규칙과 대응 응답 방향, 그리고 출발지를 다시 쓸 수 있는 postrouting 규칙을 찾으세요. 체인 정책이 drop 이고 어떤 규칙도 맞지 않으면 정책을 accept 로 뒤집는 대신 좁은 허용을 추가하고 다시 테스트하세요.

번역은 요구 사항이 아니라 정책 선택입니다. 집 LAN 쪽으로 가는 출발지 NAT는 모든 핫스팟 클라이언트를 Pi의 터널 주소처럼 보이게 하여 집 로그에서 클라이언트별 귀속을 잃고 원래 출발지를 기대하는 서비스를 깨뜨립니다. NAT 없는 라우팅은 클라이언트 주소를 보이게 유지하지만 위의 반환 경로에 의존합니다. 하나를 고르고 DNS와 IPv6도 같은 방식으로 다루세요. IPv4 경로가 동작해도 옆의 IPv6 경로가 깨져 있으면 브라우저에서는 여전히 반쯤 깨진 것으로 읽힙니다.

왕복을 검증한 다음 일부러 깨뜨리세요

핫스팟 클라이언트에서 테스트하고 Pi에서는 절대 테스트하지 마세요. Pi 자체 트래픽은 포워딩 경로와 반환 경로를 모두 우회하기 때문입니다. 한 클라이언트가 집 서비스에 도달하려는 동안 두 인터페이스를 모두 지켜보세요.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

두 캡처를 함께 읽으세요. br0 에 나타나고 tun0 에는 결코 나타나지 않는 요청은 Pi가 포워딩하지 않거나 경로가 다른 곳을 가리킨다는 뜻입니다. tun0 에 응답이 없는 요청은 집 쪽에 반환 경로가 없거나 서버가 패킷을 필터링했다는 뜻입니다. tun0 에 나타나고 br0 에 다시 나타나지 않는 응답은 역방향 필터 규칙이 빠졌다는 뜻이며, 터널은 완벽해 보이는데 클라이언트는 여전히 아무것도 보지 못합니다.

그다음 경로를 의도적으로 깨뜨리세요. 모뎀 연결을 내렸다가 다시 올리고 경로와 캡처 검사를 다시 실행하세요. 터널을 살아남지만 재연결에서 사라지는 경로는 일회성 명령이 아니라 연결 프로필에 들어가야 합니다. 터널의 전송이 여전히 underlay를 통해 나가고 자신을 통해 나가지 않는지 확인하세요. 피어로 가는 호스트 경로 없이 푸시된 기본 경로를 받아들일 때 생기는 고전적인 루프입니다.

핫스팟 클라이언트가 집 이름을 해석하고 TCP 서비스를 열고 모뎀 재연결 한 번을 넘겨 세션을 살려 둘 수 있을 때만 설계를 받아들이세요. 애플리케이션이 정말로 집 세그먼트에서 Ethernet 수준 검색을 요구한다면 로컬 브리지를 브리지되었다고 설명하며 브로드캐스트를 기다리는 대신 지원되는 Layer 2 설계를 고르세요.