Pi 한 대에서 hostapd와 OpenVPN: 기본 경로는 누구 것인가?

hostapd와 OpenVPN 클라이언트는 브리지가 자체 기본 경로를 유지하고 터널이 서버로 가는 경로를 유지할 때 Pi 한 대를 공유할 수 있습니다. 명령과 롤백.

휴대폰은 액세스 포인트에 연결되어 주소를 받은 뒤 터널이 올라오면 아무것도 도달하지 못합니다. 그 상태에서 hostapd는 대개 정상이고 OpenVPN도 마찬가지이고, 깨지는 것은 기본 경로인데, 브리지에 아예 없었거나 터널이 VPN 서버 자체로 가는 경로를 남기지 않고 바꿔 버린 경우입니다. 이 문서는 그 경로를 제자리로 돌려놓고 결과를 Pi가 아니라 클라이언트에서 증명합니다. 모든 단계는 되돌릴 수 있으며, 여기서는 터널 안에 어떤 트래픽을 넣을지 알기 전까지 터널 설정을 바꾸지 않습니다.

무엇이든 편집하기 전에 인터페이스를 조사하세요

익숙한 구성은 무선 라디오와 유선 포트를 br0 안에 두고, hostapd를 브리지에 대해 시작하며, dnsmasq에서 임대를 나눠 주고, OpenVPN 클라이언트가 tun0을 만듭니다. 그러면 세 가지 별개 요구가 하나처럼 보이는데, 액세스 포인트 클라이언트에는 게이트웨이로서 Pi가 필요하고, Pi에는 서버에 닿기 위한 인터넷 경로가 필요하며, 브리지에는 그 클라이언트가 쓸 수 있는 게이트웨이 주소가 필요합니다.

바꾸기 전에 현재 상태를 읽으세요, 이 네 명령이 인터페이스 문제와 라우팅 문제를 구분해 주기 때문입니다.

ip -br addr
ip route show
ip link show master br0
bridge link show

br0에 주소가 있어도 기본 경로가 없으면 클라이언트는 Pi까지만 도달하고 그 너머로는 아무것도 못 갑니다. 터널이 내려간 상태에서 기본 경로가 tun0을 가리키면 Pi에는 동작하는 경로가 전혀 없고, 클라이언트 증상은 똑같아 보입니다. 두 경우 모두 휴대폰에서는 동일하게 보이므로 라우팅 테이블을 직접 읽어야 합니다.

브리지에 자기 몫의 기본 경로를 주세요

Raspberry Pi OS는 인터페이스 파일을 쓴 뒤에 브리지가 생긴 경우 브리지를 기본 경로 없이 두는 일이 많습니다. 스탠자는 /etc/dhcpcd.conf에 들어가야 하며, Pi가 아니라 상위 라우터를 지목해야 합니다.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

그 예에서 192.168.50.1은 기존 라우터이고 192.168.50.2은 같은 서브넷에 있는 Pi의 브리지 주소이므로, 숫자를 복사하지 말고 자신의 계획으로 바꾸세요. 브리지 멤버도 라우터를 요청해서는 안 되며, 그렇지 않으면 Pi에 경쟁하는 기본 경로가 남아 승자가 의도가 아니라 메트릭과 타이밍에 따라 결정됩니다.

systemctl restart dhcpcd 후에 ip route show default은 br0을 한 번만 표시해야 하고 유선 포트에서 중복이 없어야 합니다. 테이블이 아니라 조회를 확인하세요, 오래된 항목이 승리한 항목 옆에 남을 수 있기 때문입니다, 즉 ip -4 route get 203.0.113.10은 br0을 지목해야 합니다. 그 주소는 TEST-NET-3 문서용 대역에서 오므로, 이 글을 읽는 동안 실제 서버와 충돌할 수 없습니다.

터널이 자기 서버로 가는 경로를 가로채지 못하게 하세요

redirect-gateway을 받아들이는 OpenVPN 클라이언트는 기본 경로를 넘겨받아 터널로 보냅니다. 모든 액세스 포인트 클라이언트가 VPN을 써야 할 때는 맞고, 일부 목적지만 써야 할 때는 틀립니다. 어느 쪽이든 Pi 자신의 서버 연결은 아직 만드는 중인 터널 안을 지나가서는 안 됩니다. OpenVPN은 기본 경로를 재지정할 때 원래 게이트웨이를 통해 원격지로 가는 호스트 경로를 추가하며, 이것이 전송을 살아 있게 하는 바로 그 동작이며, 그 경로가 없으면 터널은 연결되는 즉시 무너집니다.

연결 전후의 그 전송 경로를 빠르게 비교하는 것은 그 십 초의 값어치가 있습니다. ip -4 route get 203.0.113.10은 두 상태 모두에서 하위 장치를 지목해야 하며, 바뀌는 것은 메트릭뿐입니다. 터널이 올라온 뒤 tun0을 지목하면 호스트 경로가 설치된 적이 없고 다음 재연결은 실패합니다.

선택한 프리픽스만 터널을 지나야 할 때는 route-nopull을 쓰고 원하는 경로를 직접 추가하거나, 서버에서 더 좁은 집합을 밀어 넣으세요. 그 설계에서 브리지는 기본 경로를 유지하고, DNS가 다음 결정이 됩니다, 즉 dnsmasq를 가정용 리졸버로 전달하는 것은 실제로 거기에 사는 이름에만 의미가 있습니다.

포워딩과 NAT 이야기를 정하세요

전체 터널에는 Pi에서 포워딩이 켜져 있어야 하고, 액세스 포인트 서브넷을 라우팅할 의사가 있는 반대편 게이트웨이가 필요합니다. 무엇보다 먼저 포워딩을 확인하세요, 포워딩이 꺼져 있으면 모든 경로 변경이 무의미해집니다.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT 규칙은 서버가 액세스 포인트 프리픽스를 받아들이지 않을 때 통하는 지름길이지만, 그 대가로 반대편 로그에서 모든 클라이언트가 Pi의 터널 주소로 보입니다. NAT 없이 프리픽스를 라우팅하면 주소가 그대로 보입니다 그리고 집 쪽에서 192.168.50.0/24에 대한 반환 경로가 필요합니다.

방화벽 규칙 옆에 선택을 적어 두세요, 설계에서 보이지 않는 NAT 규칙은 여섯 달 뒤 설명할 수 없게 됩니다. IPv6도 같은 결정에 넣으세요, 깨진 IPv6 경로 옆의 동작하는 IPv4 경로는 브라우저에서 여전히 반쯤 깨진 것으로 읽힙니다.

클라이언트에서 검증한 뒤 깔끔하게 롤백하세요

액세스 포인트의 휴대폰이나 노트북에서 이 순서로 시험하세요, dnsmasq에서 임대, 브리지 주소로 ping, 그다음 터널 반대편의 목적지. 각 단계가 한 계층을 분리하므로 쓸모없는 단일 실패가 되지 않습니다.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

그다음 Pi에 여전히 자기 나가는 경로가 있는지 확인하세요, ip route get 203.0.113.10은 하위 장치를 지목해야 하고, 서버가 ICMP를 허용하면 ping -c 3 -I br0 203.0.113.10가 응답해야 합니다. 클라이언트의 처음 두 단계가 통과하고 세 번째가 실패하면 결함은 포워딩이나 NAT에 있습니다. 두 번째 단계가 실패하면 브리지나 DHCP가 아직 불완전합니다.

롤백은 파일 편집 한 번과 명령 두 개입니다, 스탠자를 지우고, dhcpcd를 다시 시작하고, 기본 경로를 ip route replace default via 192.168.50.1 dev br0으로 명시적으로 바꾸세요. 유지보수 시간 창이 닫히기 전에 하세요, 기본 경로를 잃은 Pi는 고치려고 쓸 네트워크에서 도달할 수 없습니다.

관련 글