Bloquegeu un rang de destinació per a cada pool de clients VPN

Una regla pot mantenir un pool VPN admès allunyat d'un rang de destinació sense alterar res més del que fa la passarel·la. La regla en si és curta; les parts que decideixen si funciona són el hook on viu i la seva posició a la cadena. Si us equivoqueu en aquestes dues, obteniu un tallafoc que sembla correcte i es comporta de manera inconsistent. Comenceu pel que fa el paquet quan la regla el veu.

Què coincideix realment la regla

La regla coincideix amb tres coses alhora: una interfície d'entrada, un prefix d'origen i un prefix de destinació. Les tres han de ser certes abans que s'apliqui el drop, i això és el que la manté estreta. Llegir-la com una sola expressió és més fàcil que llegir-la com tres polítiques separades.

La coincidència d'interfície és el que distingeix el trànsit reenviat dels clients de les connexions pròpies de la passarel·la. Sense ella, una regla que només anomenés el pool d'origen també afectaria paquets que la passarel·la mateixa genera des d'aquella adreça, si mai ho fa. El prefix d'origen limita la política als clients admesos, i el prefix de destinació la limita a un sol rang. Llegiu la regla com una intersecció i no com una llista.

Anoteu els tres valors abans d'editar res: el nom de la interfície del túnel, el pool que reparteix el servidor i el prefix que voleu denegar. Una errata en qualsevol d'ells produeix una regla que s'analitza neta i no protegeix res. Guardeu aquests tres valors al registre de canvis al costat de la regla.

El hook decideix a qui s'aplica la regla

Una cadena de netfilter s'adjunta a un hook, i el hook decideix quins paquets arriba a veure la cadena. El hook forward veu el trànsit encaminat a través de la passarel·la, que és el que és el trànsit de client a destinació. Tota la resta de la cadena apunta a un públic diferent.

El hook input veu el trànsit adreçat a la mateixa passarel·la, així que una regla col·locada allà governa l'accés als seus propis serveis i no el trànsit. El hook output veu el trànsit que origina la passarel·la, que és el contrari del que necessita una política de pool de clients. Els noms de cadena són etiquetes arbitràries triades per qui va escriure el conjunt de regles, així que no deduïu el hook del nom. Comproveu on s'adjunta la cadena abans de suposar què pot coincidir.

Llegir l'adjunció és una comprovació d'una línia que evita que una regla acabi en una cadena que mai no veu el paquet.

Col·loqueu la regla abans de l'acceptació àmplia

Les regles s'avaluen en ordre, i el primer veredicte guanya. Una acceptació àmplia abans a la cadena acaba l'avaluació per als paquets que coincideix, així que un drop afegit després no s'executa mai per a ells. Aquesta regla d'ordenació és tota la raó per la qual una regla que sembla correcta pot no tenir cap efecte.

Inseriu la regla abans de l'acceptació en lloc d'afegir-la al final. Si la cadena ja conté una acceptació general per a la interfície del túnel, la regla nova ha de precedir-la o és decorativa. Comproveu l'ordre resultant i no el fitxer que heu editat, perquè un conjunt de regles muntat a partir de diversos fitxers pot no coincidir amb cap d'ells. Després confirmeu-ho amb un paquet de prova del pool.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

La tercera ordre analitza el fitxer sense aplicar-lo, cosa que atrapa errors de sintaxi abans que es converteixin en una caiguda. Apliqueu-ho amb un pla de reversió, perquè una regla equivocada en una cadena forward pot tallar el túnel pel qual treballeu.

Els fluxos existents no fan cas de la vostra regla nova

Una entrada de conntrack creada abans que existís la regla continua coincidint amb l'acceptació anterior. Per això un drop nou de vegades sembla funcionar per a connexions noves i no fa res per a la que s'està provant.

Llegiu la coincidència d'estat a la part superior de la cadena. Si accepta trànsit established i related abans de la vostra regla, cada flux ja en curs continua fluint fins que es tanca. Normalment aquest és el comportament que voleu per a una regla d'emergència, i és confús quan espereu un tall immediat. Decidiu quin efecte voleu abans de desplegar. Una prova que reutilitza una connexió oberta us explicarà una història equivocada.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

La primera ordre mostra si existeix un flux, i la segona mostra si una regla d'estat primerenca continua acceptant-lo. Totes dues són de només lectura i segures durant un incident.

Què no és aquesta regla

La regla no és una llista negra de dominis, una política IPv6 ni una restricció sobre un compte d'aplicació individual.

Cadascuna d'aquestes coses necessita el seu propi mecanisme. Un bloc de domini ha de resoldre noms, cosa que un filtre de paquets no fa. El trànsit IPv6 necessita la seva pròpia coincidència, perquè una expressió ip no diu res sobre paquets ip6. Una restricció a nivell d'aplicació pertany al servei o a un proxy autenticat, no a una coincidència de prefix. Mantenir aquests requisits separats és el que evita demanar a una regla estreta que faci quatre feines.

El contracte que lliura aquesta regla és precís: el trànsit d'un pool admès cap a un prefix de destinació es denega, mentre que el trànsit no relacionat de la passarel·la conserva la seva política existent. Escriviu aquesta frase al costat de la regla, i la propera persona sabrà per a què servia.