Punt d'accés VPN pont: quina ruta per defecte fa servir el telèfon?
La ruta per defecte del Pi no és la porta d'enllaç del telèfon. Separeu les dues decisions, manteniu l'enllaç ascendent fora del pont i proveu la concessió abans del túnel.
El telèfon del vostre punt d'accés en pont obté la seva adreça i la seva porta d'enllaç d'algun lloc, i no és la ruta per defecte del Pi. Canviar la ruta per defecte del Pi canvia on el Pi envia el seu propi trànsit. El telèfon continua fent servir la porta d'enllaç que se li va indicar, i quan aquesta porta d'enllaç és a la LAN remota, les seves trames simplement creuen el pont. Dos consumidors, dues decisions. Separar-les explica la majoria d'informes d'un punt d'accés sense internet mentre el Pi mateix funciona bé.
Dos dispositius, dues decisions diferents de porta d'enllaç
El Pi té una pila IP i una ruta per defecte pròpies. El telèfon té una pila IP i una ruta per defecte pròpies.
| 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 |
Aquesta taula és tot el model. La porta d'enllaç del telèfon és una adreça a la LAN remota, i les seves trames es reenvien a la capa 2 cap a aquest encaminador. La ruta per defecte del Pi afecta el transport exterior propi del Pi, que ha d'arribar al parell VPN per l'enllaç ascendent de viatge.
Un pont reenvia trames, no encamina paquets
Un pont de Linux reenvia trames Ethernet per MAC de destinació, i això és tot el que fa entre els seus ports. La trama del telèfon adreçada a la MAC de l'encaminador remot es commuta al port TAP i creua el túnel sense tocar la taula d'encaminament del Pi. Per això una ruta per defecte espatllada del Pi pot deixar el telèfon funcionant, i per això una de correcta no pot arreglar un telèfon que va rebre la porta d'enllaç equivocada.
TAP transporta trames Ethernet i pot ser un port de pont. TUN transporta paquets IP i no pot ser-ho. Si el vostre disseny va substituir l'un per l'altre, el pont no és un pont i la resta d'això no s'aplica.
Decidiu qui reparteix la concessió del telèfon
L'opció 3 de DHCP és l'opció d'encaminador, i diu al client quina porta d'enllaç ha de fer servir per a la seva subxarxa. Quan el servidor DHCP de la LAN remota és l'únic assignador, el telèfon obté una porta d'enllaç remota i el disseny és coherent. Quan alguna altra cosa al costat de viatge respon primer, el telèfon obté una porta d'enllaç local, el seu trànsit d'internet surt per l'enllaç ascendent de viatge i el seu trànsit a la LAN remota no té cap camí.
Executeu un sol assignador per a aquest domini de difusió, i anoteu què reparteix.
El Pi és un cas a part fins i tot quan pren una adreça de la mateixa concessió. Decidiu deliberadament si ha d'instal·lar les rutes que ofereix la concessió, perquè una ruta per defecte remota importada pot arrossegar el transport VPN propi del Pi dins del túnel que intenta mantenir viu. Amb systemd-networkd aquesta decisió és UseRoutes= a la secció DHCP; amb dhclient és l'opció routers a la llista de peticions.
Manteniu l'enllaç ascendent fora de la LAN en pont
La interfície que transporta la connexió VPN exterior del Pi no ha de convertir-se en port de pont. Si ho fa, el transport xifrat es commuta a la LAN estesa i el túnel acaba transportant els seus propis paquets exteriors, cosa que falla d'una manera que sembla pèrdua de paquets més que no pas un bucle. Manteniu també explícites la capacitat d'AP i el suport de pont. Una interfície sense fil en mode estació normalment no pot ser port de pont, perquè la capçalera 802.11 no té lloc per a la segona adreça MAC que necessita un pont.
Definiu el domini de difusió estès, un pla d'adreces i el filtratge de trames que realment voleu. Permetre l'oient VPN al Pi no atorga a cada client en pont accés als serveis de gestió del Pi. Són regles separades, i tractar-les com una sola és com un punt d'accés es converteix silenciosament en una porta oberta.
Proveu les quatre coses per separat quan falla
Quan el telèfon no pot arribar a la LAN remota, quatre observacions separen les causes. Executeu-les en aquest ordre i pareu a la primera que falli.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpComenceu per la concessió: té el telèfon una adreça i una porta d'enllaç a la subxarxa remota? Després mireu el pont i confirmeu que el port AP i el port TAP tots dos reenvien. Després llegiu la taula de veïns, perquè una entrada no resolta per a l'encaminador remot significa que les trames surten i res no respon. Finalment observeu les trames al pont mentre el telèfon fa ping, cosa que us diu si la fallada és per sota d'IP o no.
Anoteu quin dispositiu posseeix cada ruta per defecte quan hàgiu acabat. Una línia de documentació converteix la sortida local enfront de la remota en una decisió conscient del client, i la referència del pont val la pena tenir-la al costat.