Encamina una subxarxa LAN per OpenVPN i conserva la ruta per defecte
Conserva la ruta per defecte de la LAN mentre una subxarxa passa pel túnel. Compara una taula de polítiques amb edicions de la taula principal i tria NAT o una ruta al servidor.
Els equips que fan encaminament per a una LAN i alhora marquen una VPN acaben en la mateixa discussió amb ells mateixos: el túnel vol posseir la ruta per defecte i la LAN la necessita de tornada. Quan OpenVPN es connecta, pot instal·lar una ruta per defecte pel túnel o un parell de mitges rutes per defecte, cosa correcta per a un portàtil i incorrecta per a una passarel·la els veïns de la qual esperen respostes des de la seva adreça LAN. La resposta no és saltar-se la VPN. La resposta és donar a les dues decisions taules diferents.
Una ruta per defecte, dos propietaris
El trànsit reenviat i el trànsit originat localment no han de seguir el mateix camí. Els clients de la LAN només necessiten el túnel per a les destinacions que trieu, mentre que les sessions de gestió del mateix amfitrió i les seves respostes a aquests clients necessiten la ruta per defecte de la LAN. Barrejar les dues coses a la taula principal obliga una sola resposta a respondre dues preguntes diferents.
OpenVPN té un commutador just per a això. route-noexec impedeix que el client toqui la taula principal, i els valors que hauria fet servir s’exporten a un script route-up com a route_vpn_gateway, dev i les adreces de la interfície. Després decidiu quina taula rep quina ruta, en codi que podreu llegir més endavant.
Taula de polítiques enfront de reescriure la principal
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
La taula separada és l’única opció que escala més enllà d’una subxarxa. Doneu-li un nom un cop i després referiu-vos-hi pel nom perquè ningú no hagi de recordar un número:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnLes adreces d’aquí són marcadors. Substituïu el prefix LAN, la passarel·la del túnel i el nom del dispositiu del vostre desplegament abans d’executar res.
La regla també ha de coincidir amb l’amfitrió
Una regla que només coincideix amb el prefix LAN cobreix els paquets reenviats. No cobreix el trànsit que origina la mateixa passarel·la ni les respostes que envia als clients de la LAN, que porten l’adreça LAN de la passarel·la com a origen. Aquestes consultes cauen a main i encara poden sortir pel túnel.
Afegiu una segona regla per a l’adreça LAN pròpia de la passarel·la o amplieu la primera regla a un conjunt que inclogui totes dues. L’ordre importa: poseu primer la regla més específica i comproveu el resultat amb una consulta que anomeni l’origen explícitament.
ip route get 203.0.113.9 from 192.168.50.1Si això informa del dispositiu del túnel per a una destinació que hauria de quedar local, el conjunt de regles és incorrecte independentment del que contingui la taula.
NAT o una ruta a l’altra banda
El servidor VPN coneix la subxarxa del túnel i res més. Els paquets que arriben amb una adreça d’origen LAN no tenen camí de tornada llevat que algú l’aporti, i hi ha exactament dues maneres d’aportar-lo. Afegir una ruta per al prefix LAN al servidor manté l’origen original visible d’un extrem a l’altre, que és el que sol voler un disseny auditat. L’emmascarament a la passarel·la reescriu l’origen a l’adreça del túnel i no necessita cap cooperació del servidor.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADETrieu NAT quan no controleu el servidor i no hi podeu afegir rutes. Trieu la ruta al servidor quan importin els registres, el control d’accés o la simetria del camí de tornada, perquè l’emmascarament esborra l’adreça original de tot el que registra l’altra banda.
En qualsevol cas, el reenviament ha d’estar activat, i el filtratge estricte del camí invers pot descartar la resposta quan main no hauria triat el túnel per a aquest origen. Comproveu el valor efectiu abans de culpar el túnel.
Feu que la divisió sobrevisqui a una reconnexió
Les regles i rutes afegides a mà desapareixen quan es recrea la interfície, i una entrada de taula obsoleta pot sobreviure a la sessió que la justificava. Posa la regla de taula, la ruta del túnel i l’entrada d’emmascarament dins del script route-up del client, i buida la taula a l’inici del script perquè una passarel·la antiga no pugui sobreviure a la nova sessió.
Verifiqueu des dels dos extrems: una consulta a la passarel·la amb l’origen LAN i una petició real d’un client de la LAN a una destinació que hagi de travessar el túnel. Una ruta que existeix però que mai no es tria es comporta exactament com cap ruta fins que llegiu els comptadors.