Bloquear IPv6 para asegurar WireGuard rompe o servidor

O obxectivo é razoable: só os usuarios do túnel deberían chegar aos servizos desta máquina. A implementación á que se recorre é unha cadea de entrada IPv6 que descarta todo agás WireGuard, o que tamén descarta o tráfico que mantén o servidor unido á súa propia ligazón. O descubrimento de veciños e as mensaxes de mantemento da ruta non son acceso a servizos, e eliminalos produce unha máquina inalcanzable por motivos alleos á túa política. O túnel lévase, os servizos están ben acoutados e nada máis da ligazón funciona.

Tres responsabilidades, un conxunto de regras

A primeira responsabilidade é a operación da rede externa: o servidor debe seguir unido á súa ligazón, resolver veciños e coñecer os límites de ruta desa ligazón. A segunda é o oínte cifrado, que acepta UDP na dirección e no porto que escolliches. A terceira é o conxunto de servizos descifrados que queres que acaden os usuarios do túnel.

Son tres políticas distintas, e só a segunda e a terceira teñen que ver coa VPN. Un conxunto de regras que as trata como unha soa herda un modo de fallo no que apertar a fronteira da aplicación rompe en silencio a unión do servidor.

Mantenas en cadeas separadas ou polo menos en comentarios separados, para que a seguinte persoa vexa que liña existe e por que.

Que fai ICMPv6 polo servidor

IPv6 depende de ICMPv6 para moito máis que o eco. A solicitude e o anuncio de veciño substitúen ARP e son necesarios para a entrega local. Packet Too Big transporta información de MTU de ruta, e ignoralo produce transferencias que se atascan con paquetes grandes. Os anuncios de encamiñador levan a ruta por defecto e a información de prefixo cando a ligazón usa configuración automática.

RFC 4890 separa as mensaxes que un filtro de servidor debe permitir das que son unha decisión administrativa, e faino nunha sección de servidor distinta das regras para un encamiñador que reenvía entre redes. Ler só a sección de reenvío produce unha política de entrada demasiado estrita para o servidor que protexe.

A regra práctica é permitir as mensaxes esenciais de erro e configuración na interface que as necesita, acoutadas por tipo e orixe onde a plataforma o permita, e tomar unha decisión explícita sobre o resto.

Substituír todo iso por un permiso xeral de ICMPv6 resolve o problema de dispoñibilidade e renuncia ao filtrado. Substituílo por un descarte xeral resolve o problema de filtrado e renuncia ao servidor.

Admite o túnel, despois o servizo

Acepta o transporte WireGuard na dirección externa prevista e no porto UDP, e acepta o tráfico de volta mediante seguimento de conexións. Despois permite os servizos de aplicación pola interface do túnel, desde as fontes que realmente autorizas.

Un permiso para o porto UDP externo non autoriza as peticións descifradas dentro del. Esa distinción é o motivo enteiro polo que a interface do túnel aparece nas regras de servizo.

Le o conxunto de regras tal como é, non como o describe o ficheiro:

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

Un oínte nunha dirección física é unha exposición separada do mesmo servizo na dirección do túnel. Se a máquina tamén reenvía tráfico a outra, iso é unha decisión de cadea de reenvío e non esta política de entrada, e necesita o seu propio razoamento.

Proba a ligazón, non só o túnel

Un túnel que funciona tras o cambio demostra menos do que parece, porque unha entrada de veciño existente e unha conexión establecida poden ocultar unha mensaxe de control que a política agora descarta.

Comproba a unión directamente e despois comproba que a ruta excluída segue fallando:

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

Unha táboa de veciños que permanece completa tras un reinicio é o sinal de que o descubrimento segue funcionando. Unha táboa que se baleira e nunca se volve encher é o sinal de que a filtrastes. O terceiro comando valida a sintaxe do conxunto de regras sen aplicalo, algo que paga a pena facer mentres aínda tes sesión.

Recupera un servidor do que quedaches fóra

Antes de cambiar regras de devasa que transportan a túa propia sesión de administración, mantén unha segunda canle: unha consola, unha conexión serie ou unha reversión programada que elimine as regras novas se non a cancelas.

Se un cambio te deixa fóra, a recuperación pasa por esa canle e non pola rede que acabas de quitar. Restaura o conxunto de regras anterior desde unha copia gardada, confirma que o servidor volve ser alcanzable e só entón reaplica a política prevista en pezas máis pequenas.

A política final non é universal. O enderezo, o encamiñamento e a implementación da devasa son entradas de despregamento, pero a fronteira é a mesma en todas partes: denega o acceso non desexado ás aplicacións mentres mantés o tráfico de control que transporta o túnel autorizado.