Áthidalt VPN hotspot: melyik alapértelmezett útvonalat használja a telefon?
A Pi alapértelmezett útvonala nem a telefon átjárója. Válassza szét a két döntést, tartsa az uplinket a hídon kívül, és még az alagút előtt tesztelje a lease-t.
Az áthidalt hotspotján a telefon valahonnan megkapja a címét és az átjáróját, és az nem a Pi alapértelmezett útvonala. A Pi alapértelmezett útvonalának módosítása azt változtatja meg, hová küldi a Pi a saját forgalmát. A telefon továbbra is azt az átjárót használja, amit megkapott, és amikor az az átjáró a távoli LAN-on van, a keretei egyszerűen átkelnek a hídon. Két fogyasztó, két döntés. Szétválasztásuk megmagyarázza a legtöbb internet nélküli hotspot-bejelentést, miközben maga a Pi rendben van.
Két eszköz, két különböző átjáródöntés
A Pi-nek saját IP-vereme és saját alapértelmezett útvonala van. A telefonnak saját IP-vereme és saját alapértelmezett útvonala van.
| 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 |
Ez a táblázat az egész modell. A telefon átjárója a távoli LAN-on lévő cím, és a keretei a 2. rétegben továbbítódnak afelé az útválasztó felé. A Pi alapértelmezett útvonala a Pi saját külső szállítására vonatkozik, amelynek az utazási uplinken keresztül el kell érnie a VPN-partnert.
A híd kereteket továbbít, nem útvonalválaszt csomagokat
A Linux híd az Ethernet-kereteket a cél-MAC szerint továbbítja, és csak ennyit tesz a portjai között. A telefon távoli útválasztó MAC-címére címzett keretét a rendszer a TAP portra kapcsolja, és a Pi útválasztási táblázatának érintése nélkül halad át az alagúton. Ezért hagyhatja működőképesen a telefont egy hibás Pi-alapértelmezett útvonal, és ezért nem tud egy helyes útvonal megjavítani egy rossz átjárót kapott telefont.
A TAP Ethernet-kereteket szállít, és lehet hídport. A TUN IP-csomagokat szállít, és nem lehet az. Ha a terve az egyiket a másikkal helyettesítette, a híd nem híd, és a többi itt nem érvényes.
Döntse el, ki osztja ki a telefon lease-ét
A DHCP 3. opciója az útválasztó opció, és megmondja a kliensnek, melyik átjárót használja az alhálózatához. Ha a távoli LAN DHCP-szervere az egyetlen kiosztó, a telefon távoli átjárót kap, és a terv konzisztens. Ha az utazási oldalon valami más válaszol előbb, a telefon helyi átjárót kap, az internets forgalma az utazási uplinken lép ki, és a távoli LAN felé irányuló forgalmának egyáltalán nincs útvonala.
Futtasson egyetlen kiosztót ahhoz a broadcast-tartományhoz, és jegyezze fel, mit oszt ki.
A Pi külön eset, akkor is, ha ugyanabból a lease-ből kap címet. Döntse el tudatosan, telepítse-e a lease által kínált útvonalakat, mert egy importált távoli alapértelmezett útvonal behúzhatja a Pi saját VPN-szállítását abba az alagútba, amelyet életben akar tartani. A systemd-networkd-nél ez a döntés a DHCP szakaszban a UseRoutes=; a dhclientnél a routers opció a kéréslistában.
Tartsa az uplinket az áthidalt LAN-on kívül
A Pi külső VPN-kapcsolatát szállító interfész nem válhat hídporttá. Ha mégis, a titkosított szállítás átkapcsolódik a kiterjesztett LAN-ba, és az alagút végül a saját külső csomagjait szállítja, ami olyan módon hibázik, ami inkább csomagvesztésnek, mint huroknak látszik. Tartsa az AP-képességet és a híd támogatását is kifejezetten. A station módú vezeték nélküli interfész általában nem lehet hídport, mert a 802.11 fejlécben nincs hely a hídhoz szükséges második MAC-címnek.
Határozza meg a kiterjesztett broadcast-tartományt, egy címtervet és a valóban kívánt keretszűrést. A VPN-figyelő engedélyezése a Pi-n nem ad minden áthidalt kliensnek hozzáférést a Pi felügyeleti szolgáltatásaihoz. Ezek külön szabályok, és egyként kezelésük az, ahogy egy hotspot csendesen nyitott ajtóvá válik.
Tesztelje a négy dolgot külön, amikor elromlik
Amikor a telefon nem éri el a távoli LAN-t, négy megfigyelés választja szét az okokat. Futtassa őket ebben a sorrendben, és álljon meg az elsőnél, amelyik elbukik.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpKezdje a lease-szel: van-e a telefonnak címe és átjárója a távoli alhálózaton? Utána nézze meg a hidat, és erősítse meg, hogy az AP-port és a TAP-port is továbbít. Utána olvassa el a szomszédtáblázatot, mert a távoli útválasztóhoz tartozó feloldatlan bejegyzés azt jelenti, hogy a keretek elmennek, és semmi sem válaszol. Végül figyelje a kereteket a hídon, miközben a telefon pingel, ami megmondja, hogy a hiba egyáltalán az IP alatt van-e.
Jegyezze fel, melyik eszköz birtokolja az egyes alapértelmezett útvonalakat, amikor végzett. Egy sor dokumentáció tudatos kliensdöntéssé teszi a helyi és a távoli kimenet kérdését, és a híd hivatkozása mellett érdemes tartani.