Sujungtas VPN prieigos taškas: kokį numatytąjį maršrutą naudoja telefonas?
Pi numatytasis maršrutas nėra telefono šliuzas. Atskirkite du sprendimus, laikykite uplink už tilto ribų ir išbandykite lease prieš tunelį.
Jūsų sujungto prieigos taško telefonas savo adresą ir šliuzą gauna kažkur, ir tai nėra Pi numatytasis maršrutas. Pakeitus Pi numatytąjį maršrutą, pasikeičia, kur Pi siunčia savo paties srautą. Telefonas toliau naudoja šliuzą, apie kurį jam buvo pasakyta, o kai tas šliuzas yra nuotoliniame LAN, jo kadrai tiesiog pereina tiltą. Du vartotojai, du sprendimai. Jų atskyrimas paaiškina daugumą pranešimų apie prieigos tašką be interneto, kai pats Pi veikia.
Du įrenginiai, du skirtingi šliuzo sprendimai
Pi turi savo IP dėklą ir savo numatytąjį maršrutą. Telefonas turi savo IP dėklą ir savo numatytąjį maršrutą.
| 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 |
Ši lentelė yra visas modelis. Telefono šliuzas yra adresas nuotoliniame LAN, o jo kadrai 2 lygmenyje persiunčiami tam maršrutizatoriui. Pi numatytasis maršrutas susijęs su Pi pačio išoriniu transportu, kuris turi pasiekti VPN partnerį per kelionės uplink.
Tiltas persiunčia kadrus, jis nemaršrutizuoja paketų
Linux tiltas persiunčia Ethernet kadrus pagal paskirties MAC, ir tai yra viskas, ką jis daro tarp savo prievadų. Telefono kadras, adresuotas nuotolinio maršrutizatoriaus MAC, perjungiamas į TAP prievadą ir praeina tunelį neliesdamas Pi maršrutizavimo lentelės. Todėl sugedęs Pi numatytasis maršrutas gali palikti telefoną veikiantį, ir todėl teisingas negali pataisyti telefono, kuriam buvo duotas neteisingas šliuzas.
TAP perduoda Ethernet kadrus ir gali būti tilto prievadas. TUN perduoda IP paketus ir negali. Jei jūsų projektas pakeitė vieną kitu, tiltas nėra tiltas ir likusi dalis čia netaikoma.
Nuspręskite, kas dalija telefono lease
DHCP 3 parinktis yra maršrutizatoriaus parinktis, ir ji pasako klientui, kurį šliuzą naudoti jo potinklyje. Kai nuotolinio LAN DHCP serveris yra vienintelis dalintojas, telefonas gauna nuotolinį šliuzą ir projektas yra nuoseklus. Kai kažkas kita kelionės pusėje atsako pirmas, telefonas gauna vietinį šliuzą, jo interneto srautas išeina per kelionės uplink, o jo srautas į nuotolinį LAN neturi jokio kelio.
Paleiskite vieną dalintoją tam transliacijos domenui ir užrašykite, ką jis dalija.
Pi yra atskiras atvejis, net kai paima adresą iš to paties lease. Sąmoningai nuspręskite, ar jis turi įdiegti maršrutus, kuriuos siūlo lease, nes importuotas nuotolinis numatytasis maršrutas gali įtraukti Pi paties VPN transportą į tunelį, kurį jis bando išlaikyti gyvą. Su systemd-networkd tas sprendimas yra UseRoutes= DHCP skiltyje; su dhclient tai yra routers parinktis užklausų sąraše.
Laikykite uplink už sujungto LAN ribų
Sąsaja, kuri perduoda Pi išorinį VPN ryšį, neturi tapti tilto prievadu. Jei ja tampa, šifruotas transportas perjungiamas į išplėstą LAN ir tunelis galiausiai perduoda savo pačio išorinius paketus, o tai nepavyksta taip, kad atrodo kaip paketų praradimas, o ne kilpa. Taip pat aiškiai laikykite AP galimybę ir tilto palaikymą. Belaidė sąsaja station režimu paprastai negali būti tilto prievadu, nes 802.11 antraštėje nėra vietos antram MAC adresui, kurio reikia tiltui.
Apibrėžkite išplėstą transliacijos domeną, vieną adresų planą ir kadrų filtravimą, kurio tikrai norite. Leidimas VPN klausytojui Pi sistemoje nesuteikia kiekvienam sujungtam klientui prieigos prie Pi valdymo paslaugų. Tai atskiros taisyklės, o jų traktavimas kaip vienos yra būdas, kuriuo prieigos taškas tyliai tampa atviromis durimis.
Kai sugenda, išbandykite keturis dalykus atskirai
Kai telefonas negali pasiekti nuotolinio LAN, keturi stebėjimai atskiria priežastis. Atlikite juos šia tvarka ir sustokite prie pirmo, kuris nepavyksta.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpPradėkite nuo lease: ar telefonas turi adresą ir šliuzą nuotoliniame potinklyje? Tada pažiūrėkite į tiltą ir patvirtinkite, kad AP prievadas ir TAP prievadas abu persiunčia. Tada perskaitykite kaimynų lentelę, nes neišspręstas įrašas nuotoliniam maršrutizatoriui reiškia, kad kadrai išeina ir niekas neatsako. Galiausiai stebėkite kadrus tilte, kol telefonas pingina, ir tai pasakys, ar gedimas apskritai yra žemiau IP.
Baigę užrašykite, kuris įrenginys valdo kiekvieną numatytąjį maršrutą. Viena dokumentacijos eilutė paverčia vietinį ir nuotolinį išėjimą sąmoningu kliento sprendimu, o tilto nuorodą verta laikyti šalia.