Bridged VPN hotspot: aling default route ang ginagamit ng telepono?

Ang telepono sa iyong bridged hotspot ay kumukuha ng address at gateway nito mula sa kung saan, at hindi ito ang default route ng Pi. Ang pagbabago ng default ng Pi ay nagbabago kung saan ipinapadala ng Pi ang sarili nitong trapiko. Patuloy na ginagamit ng telepono ang gateway na sinabi rito, at kapag ang gateway na iyon ay nasa malayong LAN, dumadaan lang ang mga frame nito sa bridge. Dalawang consumer, dalawang desisyon. Ang paghihiwalay sa kanila ay nagpapaliwanag sa karamihan ng ulat tungkol sa hotspot na walang internet habang ang Pi mismo ay maayos.

Dalawang device, dalawang magkaibang desisyon sa gateway

Ang Pi ay may sariling IP stack at sariling default route. Ang telepono ay may sariling IP stack at sariling default route.

Ang talahanayang iyon ang buong modelo. Ang gateway ng telepono ay isang address sa malayong LAN, at ang mga frame nito ay ipinapasa sa layer 2 patungo sa router na iyon. Ang default route ng Pi ay tungkol sa sarili nitong panlabas na transport, na kailangang makarating sa VPN peer sa pamamagitan ng travel uplink.

Ang bridge ay nagpapasa ng frame, hindi ito nagru-route ng packet

Ang Linux bridge ay nagpapasa ng Ethernet frame ayon sa destination MAC, at iyon lang ang ginagawa nito sa pagitan ng mga port nito. Ang frame ng telepono na nakadirekta sa MAC ng malayong router ay inililipat sa TAP port at tumatawid sa tunnel nang hindi hinahawakan ang routing table ng Pi. Kaya nga ang sirang default route ng Pi ay maaaring mag-iwan sa teleponong gumagana, at kaya nga ang tamang default route ay hindi kayang ayusin ang teleponong binigyan ng maling gateway.

TAP ay nagdadala ng Ethernet frame at maaaring maging bridge port. TUN ay nagdadala ng IP packet at hindi maaari. Kung pinalitan ng disenyo mo ang isa sa isa pa, ang bridge ay hindi bridge at hindi naaangkop ang iba pa rito.

Magpasya kung sino ang namamahagi ng lease ng telepono

Ang opsyon 3 ng DHCP ay ang router option, at sinasabi nito sa kliyente kung aling gateway ang gagamitin para sa subnet nito. Kapag ang DHCP server ng malayong LAN ang tanging nagbabahagi, nakakakuha ang telepono ng malayong gateway at pare-pareho ang disenyo. Kapag may ibang sumagot muna sa panig ng paglalakbay, nakakakuha ang telepono ng lokal na gateway, lumalabas ang internet traffic nito sa travel uplink, at ang traffic nito sa malayong LAN ay walang landas.

Magpatakbo ng isang tagapamahagi para sa broadcast domain na iyon, at itala kung ano ang ibinabahagi nito.

Ang Pi ay hiwalay na kaso kahit kumukuha ito ng address mula sa parehong lease. Sadyang magpasya kung dapat nitong i-install ang mga rutang iniaalok ng lease, dahil ang na-import na malayong default ay maaaring hilahin ang sariling VPN transport ng Pi papasok sa tunnel na sinusubukan nitong panatilihing buhay. Sa systemd-networkd ang desisyong iyon ay UseRoutes= sa seksyong DHCP; sa dhclient ito ay ang routers option sa listahan ng kahilingan.

Ilagay ang uplink sa labas ng bridged LAN

Ang interface na nagdadala ng panlabas na VPN koneksyon ng Pi ay hindi dapat maging bridge port. Kung maging, ang naka-encrypt na transport ay inililipat sa pinalawak na LAN at ang tunnel ay nagdadala ng sarili nitong panlabas na packet, na nabigo sa paraang mukhang packet loss kaysa loop. Panatilihing tahasan din ang AP capability at bridge support. Ang wireless interface sa station mode ay karaniwang hindi maaaring maging bridge port, dahil walang puwang sa 802.11 header para sa ikalawang MAC address na kailangan ng bridge.

Tukuyin ang pinalawak na broadcast domain, isang plano ng address, at ang pag-filter ng frame na talagang gusto mo. Ang pagpayag sa VPN listener sa Pi ay hindi nagbibigay sa bawat bridged client ng access sa mga serbisyo ng pamamahala ng Pi. Magkahiwalay na tuntunin iyon, at ang pagtrato sa kanila bilang isa ay kung paano tahimik na nagiging bukas na pinto ang isang hotspot.

Subukan ang apat na bagay nang hiwalay kapag nasira

Kapag hindi maabot ng telepono ang malayong LAN, apat na obserbasyon ang naghihiwalay sa mga sanhi. Patakbuhin ang mga ito sa ganitong pagkakasunod-sunod at huminto sa unang nabigo.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Magsimula sa lease: may address at gateway ba ang telepono sa malayong subnet? Pagkatapos tingnan ang bridge, at tiyakin na ang AP port at TAP port ay parehong nagpapasa. Pagkatapos basahin ang neighbour table, dahil ang hindi naresolbang entry para sa malayong router ay nangangahulugang lumalabas ang frame at walang sumasagot. Sa huli panoorin ang frame sa bridge habang nagpi-ping ang telepono, na nagsasabi kung ang sira ay nasa ilalim ng IP.

Itala kung aling device ang may-ari ng bawat default kapag tapos ka na. Ang isang linya ng dokumentasyon ay ginagawang sadyang desisyon ng kliyente ang lokal kumpara sa malayong egress, at sulit na itago ang sanggunian ng bridge sa tabi nito.