Amfitrió iptables només amb VPN: anomeneu el dispositiu tun, no tun+

Escriure -o tun+ sembla una instrucció precisa i en realitat és un comodí que abasta cada túnel que té el nucli. Un segon client VPN, un pont de contenidors o una interfície deixada per una sessió que s’ha penjat, tots el satisfan, i llavors l’amfitrió permet trànsit que la política volia impedir. El procediment de sota fixa un nom de dispositiu, ordena les excepcions perquè el túnel es pugui formar de debò i us deixa una via de tornada si les regles queden malament. Cada pas és prou curt per desfer-lo sol.

Pas 1: anoteu les regles que teniu ara

Abans de canviar una política per defecte, deseu l’estat actual perquè la reversió sigui una ordre i no un record. iptables-save > /root/iptables.pre escriu cada taula en un fitxer que podeu restaurar, i un segon terminal amb una sessió root oberta no és paranoia quan la política que esteu a punt de fixar talla la connexió que la transporta. Si treballeu en remot, programeu també un flush com a interruptor d’home mort.

Després llisteu les interfícies, perquè un nom que heu suposat és un nom que hauríeu d’haver llegit: ip -br link mostra què existeix ara mateix, i el túnel no apareixerà fins que estigui aixecat. Apunteu els noms dels dispositius a mesura que els llegiu.

Pas 2: doneu al túnel el seu propi nom

OpenVPN accepta dev tun_work a la configuració del client, i llavors Linux crea una interfície exactament amb aquest nom en lloc d’assignar tun0. El nom es manté estable entre reconnexions mentre res més no el reclami, i això és el que fa significativa una regla que anomena el dispositiu.

On el nom no es pot controlar, feu coincidir l’adreça del túnel o una marca de paquet. Tots dos funcionen, tots dos són més difícils de llegir i tots dos fallen més en silenci quan el túnel canvia la numeració. De qualsevol manera, feu coincidir una sola cosa i sigueu explícits sobre quina.

Pas 3: escriviu la política amb l’excepció de l’endpoint primer

Un amfitrió només amb VPN és un amfitrió de denegació per defecte amb una llista curta d’excepcions, i l’excepció que més importa és la que permet que el túnel existeixi. Construïu-lo en aquest ordre, amb la regla de l’endpoint abans de la regla del dispositiu del túnel, perquè l’intercanvi de salutacions tingui on anar:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

L’adreça i el port literals de l’endpoint són del vostre proveïdor, no d’aquesta pàgina. Si l’endpoint és un nom d’amfitrió, resoleu-lo una vegada i fixeu el resultat, perquè una regla no pot consultar un nom i una resposta que rota trencarà la política en silenci després del següent canvi de DNS. Comproveu també el port, perquè els proveïdors que us passen a TCP 443 necessitaran altrament una regla que ningú no ha escrit. Un túnel que només funciona amb un protocol és normalment aquesta omissió i no un defecte del tallafoc.

En un encaminador la mateixa forma va a la cadena FORWARD per als clients que hi ha darrere, i el trànsit propi de l’encaminador necessita les seves pròpies regles. Un conjunt de regles que només cobreix paquets reenviats deixa SSH i DNS pel camí antic, i així és com un encaminador es torna inabastable en el moment que el túnel s’aixeca.

Pas 4: comproveu l’ordre, no només la presència

Les regles s’avaluen en seqüència, així que un ACCEPT que arriba abans simplement amaga el REJECT que heu afegit després. La coincidència established i related és la que deixa tornar les respostes a les vostres pròpies peticions de sortida sense obrir un camí d’entrada general, i posar-la després de l’acceptació del túnel vol dir que un túnel caigut encara deixa passar trànsit de tornada per la seva interfície.

Mantingueu el recompte de regles prou petit per llegir-lo en una pantalla. Un conjunt de regles que no podeu auditar és un que pedaçareu afegint excepcions a dalt, i així és com les polítiques de denegació per defecte adquireixen a poc a poc una vora de permetre per defecte. Compteu els ACCEPT abans i després del canvi.

Pas 5: feu que sobrevisqui a l’arrencada i a la família d’adreces

Les regles introduïdes a mà desapareixen en reiniciar, així que carregueu-les des del servei de tallafoc de la distribució o des d’una unitat que s’executa després que existeixi la interfície del túnel. Referenciar tun_work en un script que s’executa abans que OpenVPN arrenqui és una manera habitual de produir un bucle d’arrencada de trànsit descartat.

Després comproveu IPv6 per separat, perquè una bona política de denegació per defecte per a IPv4 no diu res sobre l’altra família. ip -6 route us dirà si l’amfitrió té una ruta que pogués portar trànsit al voltant d’un túnel que només gestiona IPv4, i ip6tables o nftables necessita les seves pròpies regles equivalents. Proveu amb una destinació IPv6-only en lloc de confiar en la simetria del conjunt de regles.

Pas 6: verifiqueu i estigueu a punt per restaurar

Aixequu el túnel, confirmeu que el servei previst funciona i després proveu una cosa que la política hauria de refusar. Restaureu amb iptables-restore < /root/iptables.pre si la resposta us sorprèn, i només llavors comenceu a editar regles. La persistència més una via de restauració provada és el que fa que això sigui un canvi que podeu fer dues vegades.