Bloquejar IPv6 per assegurar WireGuard deixa el host trencat

L’objectiu és raonable: només els usuaris del túnel haurien d’arribar als serveis d’aquesta màquina. La implementació a què es recorre és una cadena d’entrada IPv6 que descarta tot excepte WireGuard, cosa que també descarta el trànsit que manté el host enganxat a la seva pròpia enllaç. La descoberta de veïns i els missatges de manteniment de camí no són accés a serveis, i eliminar-los produeix una màquina inabastable per motius aliens a la vostra política. El túnel s’aixeca, els serveis estan ben acotats i res més de l’enllaç funciona.

Tres responsabilitats, un conjunt de regles

La primera responsabilitat és l’operació de la xarxa externa: el host ha de romandre enganxat a la seva enllaç, resoldre veïns i conèixer els límits de camí d’aquesta enllaç. La segona és l’oient xifrat, que accepta UDP a l’adreça i el port que heu triat. La tercera és el conjunt de serveis desxifrats que voleu que assoleixin els usuaris del túnel.

Són tres polítiques diferents, i només la segona i la tercera tracten de la VPN. Un conjunt de regles que les tracta com una sola hereta un mode de fallada en què estrènyer la frontera de l’aplicació trenca en silenci l’adhesió del host.

Manteniu-les en cadenes separades o almenys en comentaris separats, perquè la propera persona vegi quina línia existeix per quin motiu.

Què fa ICMPv6 pel host

IPv6 depèn d’ICMPv6 per a molt més que l’eco. La sol·licitud i l’anunci de veïns substitueixen ARP i calen per al lliurament local. Packet Too Big transporta informació d’MTU de camí, i ignorar-lo produeix transferències que s’encallen amb paquets grans. Els anuncis d’encaminador porten la ruta per defecte i la informació de prefix quan l’enllaç fa servir configuració automàtica.

RFC 4890 separa els missatges que un filtre de host ha de permetre dels que són una decisió administrativa, i ho fa en una secció de host diferent de les regles per a un encaminador que reenvia entre xarxes. Llegir només la secció de reenviament produeix una política d’entrada massa estricta per al host que protegeix.

La regla pràctica és permetre els missatges essencials d’error i configuració a la interfície que els necessita, acotats per tipus i origen on la plataforma ho permeti, i prendre una decisió explícita sobre la resta.

Substituir tot això per un permís general d’ICMPv6 resol el problema de disponibilitat i renuncia al filtratge. Substituir-lo per un descart general resol el problema de filtratge i renuncia al host.

Admeteu el túnel, després el servei

Accepteu el transport WireGuard a l’adreça exterior prevista i al port UDP, i accepteu el trànsit de tornada mitjançant el seguiment de connexions. Després permeteu els serveis d’aplicació per la interfície del túnel, des de les fonts que realment autoritzeu.

Un permís per al port UDP exterior no autoritza les peticions desxifrades a dins. Aquesta distinció és el motiu sencer pel qual la interfície del túnel apareix a les regles de serveis.

Llegiu el conjunt de regles tal com és, no com el descriu el fitxer:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Un oient en una adreça física és una exposició separada del mateix servei a l’adreça del túnel. Si la màquina també reenvia trànsit a una altra, és una decisió de cadena de reenviament i no aquesta política d’entrada, i necessita el seu propi raonament.

Proveu l’enllaç, no només el túnel

Un túnel que funciona després del canvi demostra menys del que sembla, perquè una entrada de veí existent i una connexió establerta poden amagar un missatge de control que la política ara descarta.

Comproveu l’adhesió directament, i després comproveu que el camí exclòs encara falla:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Una taula de veïns que roman completa després d’un reinici és el senyal que la descoberta encara funciona. Una taula que s’buida i no es torna a omplir és el senyal que l’heu filtrada. La tercera ordre valida la sintaxi del conjunt de regles sense aplicar-lo, cosa que val la pena fer mentre encara teniu sessió.

Recupereu un host del qual us heu quedat fora

Abans de canviar regles de tallafocs que porten la vostra pròpia sessió d’administració, manteniu un segon canal: una consola, una connexió sèrie o una reversió programada que elimini les regles noves si no la cancel·leu.

Si un canvi us deixa fora, la recuperació passa per aquest canal i no per la xarxa que acabeu de treure. Restaureu el conjunt de regles anterior des d’una còpia desada, confirmeu que el host torna a ser abastable i només llavors reapliqueu la política prevista en peces més petites.

La política final no és universal. L’adreçament, l’encaminament i la implementació del tallafocs són entrades de desplegament, però la frontera és la mateixa a tot arreu: denegueu l’accés no desitjat a les aplicacions mentre manteniu el trànsit de control que porta el túnel autoritzat.