VPN Pi amb diversos encaminadors: poseu cada ruta al dispositiu que decideix
Un encaminador descendent afegeix una segona subxarxa de clients, i cadascun dels quatre dispositius té una decisió. Col·loqueu les rutes, comproveu l'origen i després proveu-ho des d'un client real.
Posar una caixa Wi-Fi darrere del Pi converteix una decisió d'encaminament en quatre, i el pla es trenca quan les quatre es prenen en un sol dispositiu. La primera pregunta no és quina ruta afegir. És si la caixa nova fa pont o encamina, perquè aquesta resposta decideix quantes subxarxes existeixen i quins dispositius n'han d'aprendre. Trieu primer el model d'unió; cada ruta en deriva.
Pont o encaminament: l'elecció que fixa el recompte
Un pont posa els clients nous a la mateixa subxarxa que el Pi ja serveix. Una subxarxa, una autoritat DHCP i cap traspàs per encaminar. Aquesta és la disposició més simple i la correcta quan una xarxa de clients separada no va ser mai un requisit. Un enllaç encaminat és un disseny diferent: la caixa conserva la seva subxarxa, i aquest prefix s'ha de portar a tot arreu on va el trànsit.
La resta d'aquest pla conserva l'encaminador descendent i preserva les adreces d'origen dels clients. L'objectiu és una xarxa VPN privada, no una sortida completa a internet. Escriviu el model abans de les adreces, perquè la llista de sota només és un exemple d'una unió encaminada.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Qui decideix què
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Cada dispositiu pren una decisió, i cap no pot prendre la d'un altre. El Pi necessita dues entrades, no una, i el camí de tornada és el que la gent oblida. El trànsit reenviat arriba correctament a la xarxa privada i després mor a la tornada, perquè el Pi no té ni idea d'on viu 10.41.0.0/24. Això sembla un problema de tallafocs i en realitat és una ruta que falta.
El costat remot també necessita la seva pròpia ruta. Si el servei de l'extrem llunyà no sap que 10.41.0.0/24 és accessible pel vostre túnel, les respostes s'aturen al primer salt que no té resposta. Afegiu les dues direccions abans de llegir filtres de paquets.
Els salts següents vénen de la unió
El salt següent ha de ser una adreça en una xarxa a la qual el dispositiu pugui arribar realment. L'adreça pública del parell VPN no és el salt següent per a una subxarxa privada, i la xarxa de servei remota no és cap salt següent. Una ruta cap a una passarel·la inabastable sembla correcta en un llistat i descarta cada paquet. Comproveu que la passarel·la respon abans de culpar la destinació.
Mantingueu el parell VPN exterior del Pi abastable a través de la seva pròpia ruta de subcapes. Aquesta entrada és separada de les rutes de càrrega útil, i barrejar-les dona un túnel que no es pot restablir després d'un canvi de camí.
La documentació d'rutes estàtiques aclareix la distinció entre destinació i passarel·la, tot i que cada plataforma etiqueta els seus menús de manera diferent. Llegiu la documentació del dispositiu que teniu davant en lloc de copiar la pantalla d'un altre fabricant. Les ordres de sota mostren la forma de les entrades a Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Què fa la traducció a l'origen
Si l'encaminador descendent ja tradueix els seus clients a l'adreça de trànsit, el Pi veu un sol origen traduït en lloc de l'adreça pròpia de cada client. Aquest és un disseny diferent del que preserva l'origen de dalt. Canvia la política basada en origen, els registres i quin costat pot iniciar connexions. Tots dos dissenys funcionen; responen a preguntes diferents.
Quan un servei VPN anterior es nega a encaminar el prefix de client de tornada, una traducció estreta a la sortida del túnel del Pi pot ser una solució legítima. No és cap prova que la ruta que falta fos innecessària. Anoteu quina adreça veu realment la xarxa remota i quin camí de tornada en resulta.
La selecció de ruta, el permís de reenviament i la traducció d'origen continuen sent tres feines separades. Buidar una cadena NAT compartida o permetre cada interfície perquè un client per cable funciona és com una prova que funciona es converteix en un reenviador obert.
Demostrar-ho des d'una màquina client
Envieu una sol·licitud des d'una màquina a la LAN descendent, i després seguiu-ne l'origen cap a fora i de tornada. Un ping llançat pel Pi no exerceix mai la ruta de tornada descendent, i per això un ping correcte demostra menys del que sembla. Afegiu una segona prova des d'un client per cable a la LAN pròpia del Pi perquè els dos camins es puguin comparar. Repetiu-les totes dues després de reiniciar qualsevol dels dispositius.
Les rutes afegides a mà i les traduccions que mai es van desar desapareixen juntes. Llavors la parella sembla una avaria nova en lloc d'una feina inacabada.
Deseu el model d'unió amb les rutes, el servei privat permès i qualsevol traducció en una sola nota. Aquesta nota és el que impedeix que la propera persona tracti la ubicació sense fils com una qüestió de política d'encaminament.