Túnel completo de WireGuard: AllowedIPs 0.0.0.0/0 non abonda

Pór 0.0.0.0/0, ::/0 nos AllowedIPs dun par é o paso que todos lembran, e só decide que tráfico se lle permite transportar ao par. Eses prefixos non crean rutas, non reenvían nada no outro extremo e deixan o resolutor de cada aplicación exactamente onde estaba. Catro cousas separadas teñen que cumprirse á vez para que un túnel completo sexa completo, e o mellor é comprobalas na orde de abaixo, porque unha comprobación posterior non pode rescatar unha anterior. Cada comprobación de abaixo é un feito que se pode ler dunha máquina, non un axuste que esperas que se aplicase.

Que selecciona o prefixo do par e que non

AllowedIPs é á vez un selector e unha autorización. Di ao lado local que destinos se poden enviar a este par, e di ao lado receptor que enderezos de orixe pode presentar este par. Ese é todo o traballo. Nada nesa descrición crea unha ruta no host, activa o reenvío no lado remoto nin toca a resolución de nomes.

Por iso unha configuración pode parecer completa e comportarse como un túnel dividido. O prefixo di que o par aceptaría todo; a táboa de rutas do host decide que chega realmente alí, e a pasarela decide se sae algo. Ningunha desas tres decisións vive na estrofa do par.

Encamiñar o cliente, non só a lista de pares

Xestores como wg-quick programan a táboa de rutas do host por ti, e por iso dous ficheiros de configuración idénticos compórtanse distinto segundo como subise a interface. Un perfil mínimo é o bastante curto para lelo dunha vez:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Dous detalles levan o traballo. O campo Address é un único prefixo de host en lugar dunha subrede que o cliente cre posuír, e é o xestor o que converte os AllowedIPs por defecto nunha ruta por defecto real. Levanta o mesmo ficheiro con ip link e wg setconf e non aparecerá ningunha ruta, o que parece un túnel roto e en realidade é un san co paso de encamiñamento omitido. O manual de wg-quick documenta o encamiñamento e o Table comportamento que engaden eses xestores.

Le o resultado en lugar do ficheiro: ip route get 1.1.1.1 debería nomear a interface do túnel, e wg show debería informar dun handshake recente cun contador de transferencia que se move. Un handshake sen ruta significa que o xestor nunca se executou, e editar o perfil outra vez non o arranxará. Arranca a interface como o fará o usuario, ou a proba mide a túa shell en lugar do despregamento.

Manter o extremo fóra do túnel

Un túnel completo captura cada destino, incluído aquel co que debe falar para existir. Os xestores resólveno engadindo unha ruta de host para o extremo a través da pasarela orixinal, e por iso unha configuración correcta case sempre contén unha excepción deliberada. Aplicar a metade da configuración cun xestor e a outra metade a man é a forma habitual de que esa excepción se perda.

Se o extremo é un nome de host que resolve a varios enderezos, ou a unha familia que non transportas, a excepción envellece mal e o túnel pode fallar tras unha reconexión que parecía rutineira. Fixa o extremo a un enderezo que controlas, ou confirma que o xestor a reavalia, e volve ler a ruta de host despois de cada cambio de rede.

O mesmo mecanismo explica por que un túnel completo e un portal cativo se pelexan. O portal espera interceptar o tráfico que agora captura o teu túnel, así que en redes de hotel e aeroporto levantas o túnel despois do inicio de sesión do portal, nunca antes.

Reenvío e camiño de volta na pasarela

Na pasarela, activa o reenvío para a familia que transportas, permite a cadea forward en ambos os sentidos cando traduces, e confirma o camiño de volta cunha consulta específica de orixe. Nada diso se deduce dun handshake correcto, porque un handshake só demostra que os dous pares poden intercambiar UDP. Non di nada sobre que pasa despois co paquete desencapsulado.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

A consulta execútase na pasarela e non no cliente, ou lerás outra táboa de rutas. Se nomea a interface equivocada, ou informa de que non hai ruta, entón ningún cambio do lado do cliente producirá unha saída a internet. Cando a pasarela traduce os enderezos dos clientes á saída, a resposta depende dese estado de tradución, así que a regra ten que existir para os dous sentidos do fluxo e non só para o saínte.

DNS e o estado de fallo, probados por separado

O protocolo en si non configura o resolutor de ningunha aplicación. wg-quick aplica a liña DNS a través da integración do resolutor da distribución, os contedores e os navegadores coas súas propias pilas poden ignoralo, e por iso un nome pode fallar mentres o túnel leva paquetes perfectamente. Proba cun nome de host en lugar dun enderezo, e anota que servidor respondeu en lugar de supoñer que o fixo o do perfil.

As familias de enderezos son unha proba aparte cunha resposta aparte. Unha ruta por defecto v4 non di nada sobre o que fará a conexión v6 dunha aplicación, e un túnel que filtra en silencio a segunda familia é peor que un que falla ruidosamente. Consulta un nome por cada familia, le a interface que usou cada petición, e comproba os contadores de tradución antes e despois, porque unha regra que non coincide con nada vese idéntica a unha regra que falta.

Por último, proba o estado que queres cando o túnel se detén. Un túnel completo debería fallar pechado para o tráfico que reclama: se a interface cae e as aplicacións seguen en silencio pola ligazón física, o deseño é un túnel dividido con pasos extra. Escribe o comportamento de fallo previsto, compróbao a propósito, e remata rexistrando as catro respostas — que xestor levanta a interface, que ruta leva a predeterminada, quen reenvía e traduce na pasarela, e que resolutor responde.