Мост VPN хотспот: коју подразумевану руту користи телефон?

Телефон на вашем мостовном хотспоту добија адресу и шљуз негде, и то није подразумевана рута на Pi. Промена подразумеване руте на Pi мења где Pi шаље сопствени саобраћај. Телефон наставља да користи шљуз који му је речен, и када тај шљуз стоји на удаљеном LAN-у, његови оквири једноставно прелазе мост. Два потрошача, две одлуке. Њихово раздвајање објашњава већину извештаја о хотспоту без интернета док је сам Pi исправан.

Два уређаја, две различите одлуке о шљужу

Pi има сопствени IP стек и сопствену подразумевану руту. Телефон има сопствени IP стек и сопствену подразумевану руту.

Та табела је цео модел. Шљуз телефона је адреса на удаљеном LAN-у, а његови оквири се прослеђују на слоју 2 ка том рутеру. Подразумевана рута на Pi тиче се сопственог спољашњег транспорта Pi, који мора да стигне VPN партнера преко путног uplink-а.

Мост прослеђује оквире, не рутира пакете

Linux мост прослеђује Ethernet оквире према одредишном MAC-у и то је све што ради између својих портова. Оквир телефона адресиран на MAC удаљеног рутера пребацује се на TAP порт и прелази тунел без додиривања Pi табеле рутирања. Зато неисправна Pi подразумевана рута може оставити телефон радним и зато исправна не може поправити телефон који је добио погрешан шљуз.

TAP носи Ethernet оквире и може бити порт моста. TUN носи IP пакете и не може. Ако је ваш дизајн заменио једно другим, мост није мост и остатак овога не важи.

Одлучите ко додељује lease телефона

DHCP опција 3 је опција рутера и говори клијенту који шљуз да користи за своју подмрежу. Када је DHCP сервер удаљеног LAN-а једини додељивач, телефон добија удаљени шљуз и дизајн је доследан. Када нешто друго на путној страни одговори прво, телефон добија локални шљуз, његов интернет саобраћај излази преко путног uplink-а, а његов саобраћај ка удаљеном LAN-у нема никакав пут.

Покрените један додељивач за тај broadcast домен и забележите шта додељује.

Pi је посебан случај чак и када узима адресу из истог lease-а. Свесно одлучите да ли треба да инсталира руте које lease нуди, јер увезена удаљена подразумевана рута може да повуче сопствени VPN транспорт Pi у тунел који покушава да одржи живим. У systemd-networkd та одлука је UseRoutes= у одељку DHCP; у dhclient то је опција routers на списку захтева.

Држите uplink ван мостовног LAN-а

Интерфејс који носи спољашњу VPN везу Pi не сме да постане порт моста. Ако постане, шифровани транспорт се пребацује у проширени LAN и тунел на крају носи сопствене спољашње пакете, што отказује на начин који личи на губитак пакета, а не на петљу. Држите и способност AP-а и подршку моста експлицитнима. Бежични интерфејс у station режиму обично не може бити порт моста, јер заглавље 802.11 нема места за другу MAC адресу која је потребна мосту.

Дефинишите проширени broadcast домен, један план адреса и филтрирање оквира које стварно желите. Дозвољавање VPN слушаоца на Pi не даје сваком мостовном клијенту приступ Pi услугама управљања. То су одвојена правила, а њихово третирање као једног је начин на који хотспот тихо постаје отворена врата.

Тестирајте четири ствари одвојено када се поквари

Када телефон не може да стигне удаљени LAN, четири запажања раздвајају узроке. Изведите их овим редом и зауставите се на првом које не успе.

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

Почните од lease-а: држи ли телефон адресу и шљуз на удаљеној подмрежи? Затим погледајте мост и потврдите да AP порт и TAP порт оба прослеђују. Затим прочитајте табелу суседа, јер нерешен унос за удаљени рутер значи да оквири одлазе и ништа не одговара. На крају гледајте оквире на мосту док телефон пингује, што вам каже да ли је квар уопште испод IP-а.

Забележите који уређај поседује сваку подразумевану руту када завршите. Један ред документације претвара локални наспрам удаљеног излаза у свесну одлуку клијента, а референцу моста вреди држати уз то.