O interruptor de emerxencia só bloquea IPv4: por que IPv6 escapa igual

O túnel cae, o interruptor de emerxencia informa que se activou e unha descarga segue en marcha. Nada está roto nas regras de IPv4. A aplicación simplemente moveuse a unha ruta para a que esas regras nunca se escribiron.

Os dispositivos de dobre pila teñen dúas saídas independentes. Un bloqueo nunha delas é medio bloqueo.

Dous conxuntos de regras, dous valores predeterminados

En Linux, iptables e ip6tables son táboas separadas con políticas separadas. Pór as cadeas INPUT e OUTPUT da táboa IPv4 en DROP non cambia nada na táboa IPv6, onde o valor predeterminado adoita ser ACCEPT. A mesma división existe en nftables, onde podes inspeccionar unha familia e descubrir que só unha delas leva as túas regras. Esa asimetría é normal, e é todo o problema.

Por iso un interruptor de emerxencia pode parecer exhaustivo e comportarse parcialmente. O script que escribiu as regras de IPv4 executouse, os contadores aumentan, a liña de rexistro aparece e un paquete IPv6 sae pola interface física completamente intacto.

Le o que o teu cliente instala realmente en lugar do que promete a páxina de márketing. Algúns clientes encamiñan IPv6 ao túnel, outros bloquéano deliberadamente e outros déixano en paz mentres un bloqueo a nivel de plataforma aplica outra regra. A documentación do provedor é a única fonte na que paga a pena confiar aquí.

Que che di a configuración da interface

A páxina do manual de wg-quick inclúe regras IPv6 na súa configuración de exemplo, e a razón é exactamente este oco. O exemplo non é decoración. Existe porque só as regras de IPv4 deixarían aberta a segunda familia.

Copiar medio exemplo produce media política. Ese é a orixe máis común desta fuga. Unha entrada de blog recortou o exemplo por lonxitude. A versión recortada converteuse entón no modelo que todos reutilizaron.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Se o segundo comando imprime unha política permisiva mentres o primeiro imprime DROP, atopaches a resposta sen tocar o cliente. Esa asimetría é o erro.

Por que unha soa consulta non é toda a historia

Un só nome pode devolver tanto un rexistro A como un rexistro AAAA, e as aplicacións non elixen todas igual. Un navegador pode preferir IPv6 cando a rede o ofrece e retroceder ante un fallo, mentres unha sincronización en segundo plano ou un actualizador usa o seu propio resolvedor e a súa propia preferencia. Por tanto, unha proba exitosa sobre IPv4 demostra unha ruta, non a política.

As transicións de rede tamén cambian a resposta. Unirse a outra rede Wi-Fi, retomar tras a suspensión ou pasar á rede móbil pode dar ao dispositivo un novo prefixo IPv6, e a política que parecía adecuada na LAN da oficina pode non cubrilo.

Proba o estado no que o túnel está caído

Probar mentres estás conectado dinos que o túnel funciona. A proba interesante é o estado non dispoñible, porque é cando se supón que o interruptor de emerxencia debe aguantar. Deter o túnel a propósito e despois proba os destinos que importan desde a aplicación que protexes.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Ambas as familias deberían fallar pechadas. Se a solicitude IPv4 expira e a solicitude IPv6 devolve un código de estado, a política está incompleta, e ningunha cantidade de repetir a proba do túnel o cambiará.

Mantén tamén as excepcións documentadas nesa proba. O descubrimento da rede local, unha renovación de DHCP ou a ruta de arranque ata o punto final da VPN poden necesitar seguir sendo accesibles, e esas excepcións deberían nomearse na política en lugar de descubrirse durante unha interrupción. Unha proba de fuga que falla porque o túnel non pode volver subir non é un achado de seguridade, é un achado de conectividade.