Passarel·la VPN amb Raspberry Pi: una sola NIC o un port de client dedicat

Teniu una Pi, un perfil VPN de sortida que funciona i dos dispositius que haurien d’arribar a internet a través seu. La pregunta que decideix tota la construcció no és quina guia seguir, sinó quanta contenció necessiteu. Un sol port permet que la Pi se segui al costat d’aquests dispositius a la LAN del router i faci de passarel·la addicional; un segon port us permet posar-los en un segment on la Pi és l’única sortida. Tot el que ve després d’aquesta tria — DHCP, abast del tallafoc, DNS, el cas de caiguda — se’n deriva.

En què es diferencien realment els dos dissenys

Tots dos dissenys encaminen. La diferència és qui més és al cable i què passa quan la vostra política és incorrecta.

La contenció és l’eix real. El disseny A és orientatiu: un dispositiu que ignora la passarel·la lliurada per DHCP i tria el router continua funcionant, sense xifrar. El disseny B s’imposa per topologia, perquè no hi ha cap altre salt següent a triar.

Disseny A: la Pi com a passarel·la addicional a la LAN existent

Suposem que el router de l’ISP és 192.168.50.1, la Pi és 192.168.50.2 i els clients triats apunten a la Pi. L’important és que dos fluxos de paquets diferents comparteixen un sol cable. El paquet intern del client arriba a la Pi i ha de sortir pel túnel; el paquet xifrat propi de la Pi cap al parell VPN ha de sortir pel mateix cable cap al router. Viatgen en direccions oposades per la mateixa interfície i necessiten un tractament diferent.

Doneu l’adreça a la Pi a través del gestor de xarxa instal·lat, no amb una recepta antiga de fitxer d’interfície que hi competeix pel dispositiu. Després configureu els clients: una passarel·la estàtica en un dispositiu, o una reserva DHCP que lliura 192.168.50.2 com a router. No canvieu tot l’àmbit DHCP del router per dos dispositius, i no doneu per fet que un client respecta l’opció — verifiqueu-ho.

La feblesa és estructural, no arreglable. Qualsevol client d’aquell segment pot apuntar a 192.168.50.1 i sortir sense xifrar, i un dispositiu amb una segona interfície o una ràdio cel·lular abandona del tot el vostre camí d’aplicació. Si aquesta frase és inacceptable per al dispositiu en qüestió, ja teniu la resposta: feu servir el disseny B.

Disseny B: un port dedicat tanca els dispositius a dins

Aquí la Pi conserva 192.168.50.2 a l’enllaç ascendent amb passarel·la 192.168.50.1, i pren 10.20.0.1/24 en una segona interfície per als dispositius connectats. Ara la Pi és un router amb dues xarxes, i el segment connectat té exactament una sortida.

Comproveu el rang contra tota la resta abans de comprometre-us: la subxarxa pròpia del túnel, altres prefixos entre seus i qualsevol cosa abastable a través de la VPN. Una 10.20.0.0/24 que xoca amb una LAN remota produeix el tipus de resultat mig funcionant que costa una tarda de diagnòstic. Si el segon port és un adaptador USB, confirmeu que és compatible i fixeu el seu nom al gestor de xarxa perquè una reordenació després del reinici no mogui la vostra adreça de LAN.

Executeu l’oient DHCP només en aquesta interfície. Un servidor que respon a l’enllaç ascendent competeix amb el router de l’ISP i lliura les adreces del vostre segment a la resta de la casa. Lligueu-lo a la interfície LAN, limiteu-lo al rang declarat i manteniu l’adreça pròpia de la Pi fora del pool.

Reenviament, traducció i la regla de tancament en fallada

Quatre coses sovint es descriuen com una i no ho són. Activar el reenviament (net.ipv4.ip_forward=1) només diu al nucli que pot moure paquets entre interfícies; no permet res per si mateix i no garanteix cap camí. Triar la sortida és una decisió d’encaminament. Permetre el paquet és una decisió de política a la cadena forward. Reescriure’n la font és una decisió de postrouting. Una construcció que només fa la primera produeix una Pi que reenvia alegrement el trànsit dels clients cap a l’enllaç ascendent.

Limiteu el permís a les fonts que volíeu i a la interfície que el trànsit ha d’utilitzar, i incloeu el camí de tornada i les destinacions que la Pi necessita. Llavors traduïu a la sortida del túnel si el proveïdor no us encamina el prefix de LAN de tornada. manual de nftables tracta el reenviament, la sortida local i la traducció de font com a operacions separades, que és el model mental correcte aquí.

La fallada habitual és una regla masquerade àmplia a la interfície física. Llavors el trànsit arriba a internet pel camí de l’ISP mentre, des del costat del client, sembla exactament una VPN que funciona. No demostra res. Manteniu la traducció lligada a la sortida declarada i manteniu les vostres regles al tallafoc que l’amfitrió ja utilitza, en lloc d’afegir un conjunt de regles competitiu que buida una cadena postrouting compartida.

Després afronteu l’absència del túnel. Un perfil de client que instal·la una ruta per defecte àmplia també vol dir que, quan el túnel cau, la ruta per defecte ordinària pot tornar i el trànsit del client torna silenciosament a l’enllaç ascendent. Allà on la tornada a text clar no és acceptable, la política forward ha de denegar explícitament el trànsit de client a enllaç ascendent, en l’estat en què la ruta VPN ha desaparegut. Escriviu-ho com una regla de rebuig, no com una suposició. El transport xifrat propi de la Pi cap al parell VPN és un flux local-output separat i ha de romandre permès, o el túnel no podrà tornar mai.

DNS i IPv6 necessiten la seva pròpia resposta

Si els clients fan servir la Pi com a resolutor, arriben a un oient local i la Pi origina una consulta nova. Aquesta consulta ascendent segueix la ruta pròpia de la Pi, no la regla forward que heu escrit per als clients, així que un camí de client només pel túnel més un resolutor que surt directament és una fuita sense cap missatge d’error. Decidiu-ho a propòsit: un resolutor abastat pel túnel, o un de local que accepteu com a directe, i feu que la política de sortida pròpia de la Pi coincideixi amb aquesta decisió.

IPv6 torna a ser un cas a part. Una regla forward d’IPv4 no limita res sobre IPv6, i els anuncis de router a l’enllaç ascendent poden donar a la Pi, i a través seu al segment connectat, una segona ruta per defecte que evita la vostra política. O bé doneu a IPv6 el seu propi camí protegit amb el mateix principi, o bé limiteu-lo explícitament al segment de clients i digueu-ho.

Proveu la frontera abans de confiar-hi

Accepteu el disseny només després de quatre comprovacions separades, perquè la prova única temptadora — obrir un navegador en un client — passa en diversos estats trencats.

Confirmeu que un client real arriba a internet pel túnel, i després confirmeu que el mateix client no pot arribar a internet amb el túnel caigut. Confirmeu que la resolució DNS funciona i que la consulta surt on volíeu. Confirmeu que el transport propi de la Pi encara funciona després d’un reinici del túnel, i que la recuperació no requereix reiniciar la màquina. Finalment, comproveu un dispositiu que no heu triat: amb el disseny A hauria de continuar funcionant normalment, i amb el disseny B no hauria d’existir gens en aquell segment.

• Dos ports i una regla de denegació donen aplicació; un port i una opció DHCP donen consell.
• La traducció a la interfície equivocada sembla un èxit i no ho és.
• El trànsit propi de la Pi, el DNS i l’IPv6 necessiten cadascun una decisió, no una inferència.