Adreces de túnel estàtiques a pfSense: preferència o reserva?

Dos dissenys semblen iguals sobre el paper i es comporten molt diferent quan una regla depèn d’ells. Un escriu una adreça en una anul·lació de client i confia en l’adreça com a identitat. L’altre tanca del tot l’admissió dinàmica, de manera que un extrem o té una assignació única o no es connecta. Només el segon converteix una adreça en una entrada de política que podeu defensar, i la diferència val la pena entendre-la abans d’escriure una sola regla de tallafocs.

Què promet realment una adreça d’anul·lació

Una anul·lació específica de client porta opcions per client, inclosa una adreça de túnel preferida. Netgate descriu aquesta adreça com una preferència i no com una reserva, cosa que significa que el conjunt dinàmic no cedeix l’adreça a ningú altre.

Això normalment està bé. Una col·lisió és rara, i el client normalment rep el que ha demanat, cosa que prou per a la comoditat i no prou per a l’autorització. Comoditat i autorització són requisits diferents, i només un d’ells sobreviu a una col·lisió.

Amb topologia de subxarxa, el camp pren l’adreça del client juntament amb la màscara de la xarxa del servidor, així que una adreça dins d’un túnel 10.90.0.0/24 s’escriu com a 10.90.0.10/24.

Res d’això no reserva el número. Un client l’anul·lació del qual no coincideix, o una sessió duplicada, pot acabar en un altre lloc del conjunt, i una regla basada en l’adreça descriu llavors algú que no hi és.

Tanqueu la via dinàmica amb un valor per defecte delimitat

L’alternativa és un servidor només estàtic: cada extrem admès té la seva pròpia identitat i la seva pròpia adreça única, i res més no hi entra.

Implementar-ho vol dir una anul·lació DEFAULT limitada a aquest únic servidor amb el bloqueig de connexions activat. Un client sense una anul·lació coincident no pot llavors tornar a l’admissió dinàmica ordinària. Aquesta sola línia és el que converteix una preferència en un conjunt tancat.

L’abast importa. Una anul·lació per defecte aplicada a cada instància VPN de l’equip bloquejarà túnels no relacionats, i aquesta fallada sembla un servei trencat més que una decisió de política. Lligueu-la a l’únic servidor del qual canvieu el model d’admissió. Després anoteu l’abast al registre de canvis, perquè la persona següent no recordarà a quin túnel pertany.

Auditeu després tot el conjunt permès. El bloqueig per defecte no arregla una anul·lació amb nom que s’ha deixat sense adreça, i aquell extrem simplement no es connectarà sense una pista clara de per què.

Coincidiu amb la identitat que el servidor fa servir de debò

Una anul·lació coincideix amb alguna cosa. En un servidor que compara noms comuns de certificat, el nom de l’anul·lació ha de ser aquell nom comú, no el nom visible de la persona. Copieu-lo del certificat en lloc de la llista de comptes.

Un servidor configurat per fer servir el nom d’usuari com a nom comú compara amb una clau completament diferent, i una anul·lació anomenada pel certificat no s’activarà mai. Llegiu el paràmetre en lloc de deduir-lo del que mostra la llista de comptes.

Manteniu els factors d’autenticació addicionals que exigeix el desplegament. Un model d’adreces tancat canvia qui es pot connectar i quina adreça rep; no substitueix la comprovació del certificat ni el segon factor.

Escriviu les regles d’accés quan el mapa sigui sòlid

Un cop el mapa d’identitat a adreça és tancat, les regles poden referir-se a adreces sense fer veure que són persones. Un àlies que agrupa els extrems d’una persona pot arribar a un servei concret mentre un altre àlies arriba a una altra cosa. L’àlies esdevé l’objecte revisable, i l’adreça esdevé un detall d’implementació a dins.

Manteniu explícits els destins i els ports. Permetre tota la xarxa local des de tot el conjunt de túnels és justament el disseny que aquest exercici havia de substituir.

Llegiu les regles flotants, de grup i d’interfície en el seu ordre real d’avaluació, perquè un pas ampli anterior anul·la un pas estret posterior. Desactivar el reenviament intern entre clients manté el trànsit entre iguals a la frontera on es revisen aquestes regles. Una regla que només existeix sobre el paper no és aplicació.

Proveu els casos negatius

Exerciteu quatre connexions noves: un extrem amb nom, un sense cap anul·lació, un servei que hauria de ser abastable i un que no hauria de ser-ho. L’extrem no llistat és el cas important, perquè és el que el disseny existeix per aturar. Si es connecta, el bloqueig per defecte no fa la seva feina.

Comproveu IPv6 per separat, ja que una política d’adreces IPv4 no diu res sobre una segona pila. Després confirmeu que l’aplicació encara autoritza l’usuari, perquè una adreça de túnel és un fet de xarxa i no una prova de qui és al teclat. Les dues comprovacions pertanyen a la nota d’acceptació.

Finalment, planifiqueu la migració. Les anul·lacions noves i les regles estretes no canvien retroactivament les sessions ja establertes, així que els estats existents han de caducar o esborrar-se deliberadament.