브리지 VPN 핫스폿: 휴대폰은 어떤 기본 경로를 사용하는가?
Pi의 기본 경로는 휴대폰의 게이트웨이가 아니다. 두 결정을 분리하고, 업링크를 브리지 밖에 두고, 터널보다 먼저 임대를 시험하라.
브리지 핫스폿에 연결된 휴대폰은 주소와 게이트웨이를 어딘가에서 받으며, 그것은 Pi의 기본 경로가 아닙니다. Pi의 기본 경로를 바꾸면 Pi가 자기 트래픽을 어디로 보내는지가 바뀝니다. 휴대폰은 들은 게이트웨이를 계속 사용하고, 그 게이트웨이가 원격 LAN에 있으면 프레임은 그냥 브리지를 건넙니다. 소비자는 둘, 결정도 둘입니다. 둘을 분리하면 Pi 자체는 멀쩡한데 핫스폿에 인터넷이 없다는 보고의 대부분이 설명됩니다.
두 장치, 두 가지 다른 게이트웨이 결정
Pi에는 자체 IP 스택과 자체 기본 경로가 있습니다. 휴대폰에도 자체 IP 스택과 자체 기본 경로가 있습니다.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
그 표가 모델의 전부입니다. 휴대폰의 게이트웨이는 원격 LAN의 주소이고, 그 프레임은 2계층에서 그 라우터 쪽으로 전달됩니다. Pi의 기본 경로는 Pi 자체의 외부 전송에 관한 것으로, 여행 업링크를 통해 VPN 피어에 도달해야 합니다.
브리지는 프레임을 전달하고 패킷을 라우팅하지 않는다
Linux 브리지는 목적지 MAC으로 Ethernet 프레임을 전달하며, 포트 사이에서 그 이상은 하지 않습니다. 원격 라우터의 MAC으로 향한 휴대폰 프레임은 TAP 포트로 스위칭되어 Pi의 라우팅 테이블을 건드리지 않고 터널을 지납니다. 그래서 Pi의 기본 경로가 깨져도 휴대폰은 계속 동작하고, 올바른 기본 경로라도 잘못된 게이트웨이를 받은 휴대폰은 고칠 수 없습니다.
TAP은 Ethernet 프레임을 나르며 브리지 포트가 될 수 있습니다. TUN은 IP 패킷을 나르며 브리지 포트가 될 수 없습니다. 설계가 둘을 바꿔 놓았다면 브리지는 브리지가 아니며 나머지 내용은 적용되지 않습니다.
휴대폰의 임대를 누가 나눠 줄지 결정하라
DHCP 옵션 3은 라우터 옵션이며, 클라이언트에게 자기 서브넷에 쓸 게이트웨이를 알려 줍니다. 원격 LAN의 DHCP 서버가 유일한 분배자라면 휴대폰은 원격 게이트웨이를 받고 설계는 일관됩니다. 여행 쪽의 다른 무언가가 먼저 응답하면 휴대폰은 로컬 게이트웨이를 받고, 인터넷 트래픽은 여행 업링크로 나가며, 원격 LAN으로 가는 트래픽에는 경로가 전혀 없습니다.
그 브로드캐스트 도메인에는 분배자를 하나만 두고, 무엇을 나눠 주는지 기록하라.
Pi는 같은 임대에서 주소를 받더라도 별개의 경우입니다. 임대가 제안하는 경로를 설치할지 의도적으로 결정하세요. 가져온 원격 기본 경로가 Pi 자체의 VPN 전송을, 살려 두려는 터널 안으로 끌어들일 수 있기 때문입니다. systemd-networkd에서는 DHCP 섹션의 UseRoutes=가 그 결정이고, dhclient에서는 요청 목록의 routers 옵션이 그 결정입니다.
업링크를 브리지 LAN 밖에 두라
Pi의 외부 VPN 연결을 나르는 인터페이스는 브리지 포트가 되어서는 안 됩니다. 그렇게 되면 암호화된 전송이 확장 LAN으로 스위칭되고 터널이 결국 자기 외부 패킷을 나르게 되어, 루프가 아니라 패킷 손실처럼 보이는 방식으로 실패합니다. AP 기능과 브리지 지원도 명시하세요. station 모드의 무선 인터페이스는 보통 브리지 포트가 될 수 없습니다. 802.11 헤더에 브리지가 필요로 하는 두 번째 MAC 주소를 넣을 자리가 없기 때문입니다.
정의하라 확장 브로드캐스트 도메인, 하나의 주소 계획, 그리고 실제로 원하는 프레임 필터링을. Pi에서 VPN 리스너를 허용해도 브리지된 모든 클라이언트가 Pi의 관리 서비스에 접근하는 것은 아닙니다. 그것은 별개의 규칙이며, 둘을 하나로 취급하는 것이 핫스폿이 조용히 열린 문이 되는 길입니다.
깨졌을 때 네 가지를 따로 시험하라
휴대폰이 원격 LAN에 닿지 못할 때, 네 가지 관찰이 원인을 갈라 줍니다. 이 순서로 실행하고 처음 실패하는 지점에서 멈추세요.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp임대부터 시작합니다. 휴대폰이 원격 서브넷의 주소와 게이트웨이를 가지고 있나요? 다음으로 브리지를 보고, AP 포트와 TAP 포트가 모두 전달하는지 확인하세요. 다음으로 이웃 테이블을 읽으세요. 원격 라우터의 항목이 해결되지 않았다면 프레임은 나가지만 아무도 응답하지 않는다는 뜻입니다. 마지막으로 휴대폰이 ping하는 동안 브리지의 프레임을 관찰하세요. 이것이 결함이 IP 아래에 있는지 알려 줍니다.
끝나면 어느 장치가 각 기본 경로를 소유하는지 기록하세요. 문서 한 줄이 로컬과 원격 이그레스 중 무엇을 쓸지 의도적인 클라이언트 결정으로 만들고, 브리지 참조를 그 옆에 두는 것이 좋습니다.