O túnel completo en strongSwan necesita 0.0.0.0/0 nos dous extremos

Un túnel completo necesita 0.0.0.0/0 como remote_ts do cliente e como local_ts da porta de enlace, ademais de reenvío, NAT e unha ruta de retorno. Comprobe as catro.

Unha conexión strongSwan que funciona para unha soa subrede privada non transportará tráfico de internet só porque alguén editou unha liña. Un túnel completo é un acordo entre dous extremos sobre que enderezos protexe a child SA, e cada extremo nomea o outro respecto de si mesmo. Acerta un lado e falla o outro, e a child SA ou non levanta ou levanta máis estreita do previsto. As cinco comprobacións seguintes seguen ese acordo desde o cliente, a través da porta de enlace, ata internet.

Comprobe primeiro o selector do cliente

O cliente describe o que quere protexer no lado remoto como remote_ts, e todo o que envía parte do seu propio enderezo asignado. Para o tráfico de internet ese valor debe cubrir os destinos que o usuario acadará realmente, o que na práctica significa todo o espazo IPv4. Un cliente que aínda enumera unha subrede pide un túnel dividido, chámese como se chame o perfil na interface. O lado de orixe adoita ser dynamic porque o enderezo se asigna ao conectar. Unha orixe fixa escrita alí rompe en canto cambia o conxunto de enderezos.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

O fragmento non é un ficheiro de conexión completo, e este supón que a autenticación, as identidades e o conxunto de enderezos virtuais xa están configurados. O selector de orixe do cliente e o enderezo que asigna o servidor aínda deben coincidir, ou a child SA levanta cun alcance que ningún dos dous lados esperaba. Cárgueo con swanctl --load-all e lea a saída antes de supor éxito. Un ficheiro que se analiza pode seguir sendo rexeitado por un selector que non se solapa coa proposta do outro extremo.

Comprobe o selector da porta de enlace no seu propio lado

A porta de enlace le o mesmo concepto desde a dirección oposta. Os destinos de internet son locais para a porta de enlace, así que o seu local_ts é o amplo e o seu remote_ts describe o conxunto de clientes. Esa inversión é o erro máis común nunha configuración de túnel completo, e sobrevive á revisión porque ambas as liñas parecen plausibles por separado.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copiar o fragmento do cliente ao ficheiro da porta de enlace produce un par de selectores que non describe nada útil, porque ambos os lados reclamarían o mesmo papel. A guía de reenvío de strongSwan documenta explicitamente o emparellamento de cliente e porta de enlace, e paga a pena lela xunto ao ficheiro de conexión en lugar de despois do fallo. O ficheiro da porta de enlace tamén necesita a definición do conxunto ao que fai referencia remote_ts. Un selector que nomea un conxunto inexistente cárgase sen queixa e falla ao conectar.

O antigo ipsec.conf usa papeis esquerdo e dereito con claves distintas, e unha liña rightsubnet non é un substituto directo do valor de swanctl. Manteña as dúas sintaxes en ficheiros separados en lugar de pegar unha dentro da outra. Mesturalas nun mesmo directorio é como unha conexión que funciona volve en silencio tras un reinicio.

Comprobe a child SA negociada, non o ficheiro

Unha configuración gardada demostra a intención e nada máis. O outro extremo pode estreitar o solicitado, e unha child SA existente non se substitúe só porque o ficheiro debaixo cambiou. Confirme que hai realmente instalado antes de cambiar calquera outra cousa.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

O primeiro comando mostra o que cargou o demonio, o segundo mostra as child SA establecidas e o terceiro as políticas que aplicará o núcleo. Se o ficheiro di 0.0.0.0/0 e a listaxe mostra unha soa subrede, a negociación estreitou o alcance e reler o ficheiro non o explicará. Termine a child, vólvaa iniciar e compare as tres saídas de novo. Unha child que volve co mesmo alcance estreito está a ser estreitada polo outro extremo e non polo ficheiro local, e iso é unha conversa co outro administrador en lugar dunha edición local.

Lea ambas as direccións na listaxe de políticas, porque un túnel que instala unha dirección e non a outra é un problema de encamiñamento disfrazado de configuración. As políticas de ida e volta deben nomear o mesmo par de selectores en imaxe espello, e un espello ausente é un defecto do demonio ou da proposta, non do texto do selector.

Comprobe o reenvío e a ruta de retorno

Un selector admite tráfico cara á porta de enlace; non fai que a porta de enlace encamiñe ese tráfico máis alá. O reenvío debe estar habilitado, a devasa debe permitir o fluxo e a resposta debe atopar o camiño de volta ao conxunto de clientes. Son tres requisitos separados, e cada un falla cun síntoma distinto. Unha regra de reenvío ausente compórtase como un burato negro, mentres que unha ruta de retorno ausente compórtase como un túnel dun só sentido.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Os enderezos privados dos clientes adoitan necesitar unha tradución de orixe deliberada antes de saír por unha interface pública, mentres que unha asignación encamiñada explicitamente require outro trato. Se hai NAT, manteña as excepcións que admite a implementación para que o tráfico que unha política de seguridade debe inspeccionar non se traduza por riba dela. Unha regra masquerade ampla copiada doutra porta de enlace cambia moitos máis fluxos do que o seu autor pretendía. Escriba a regra só para o conxunto de clientes e deixe un comentario explicando por que existe.

No cliente, confirme as rutas que instalou o backend en lugar das rutas que supuxo. Un xestor coa instalación de rutas desactivada necesita un deseño de encamiñamento mantido a man, e ese deseño debe actualizarse sempre que cambie o túnel. Comprobe a táboa de encamiñamento tras reconectar, non só tras un arranque limpo.

Comprobe o que segue sen cubrir o túnel

O par de selectores cobre IPv4 e nada máis. IPv6, DNS e calquera política a nivel de aplicación son decisións separadas que un selector IPv4 amplo ignora en silencio. Un túnel que transporta cada paquete IPv4 aínda pode filtrar cada consulta de nome.

Declare explicitamente a ruta DNS prevista, porque un túnel completo que aínda resolve nomes polo resolvedor local filtra consultas fóra do túnel e rompe nomes privados. Se ao cliente se lle asigna un enderezo IPv6, esa familia de enderezos necesita o mesmo trato, ou o host preferirá unha ruta que o túnel non protexe. Probe cun nome que só o lado privado poida responder, e trate unha resposta pública como unha fuga.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirme a cadea con eses dous comandos máis os selectores negociados da listaxe anterior. Se o traceroute mostra o router local como primeiro salto, o tráfico non usa o túnel, digan o que digan os selectores. O acceso a internet está completo só cando o tráfico elixido se admite, se reenvía e volve pola porta de enlace deseñada. Atopar 0.0.0.0/0 nun perfil é o comezo desa cadea, non a súa proba.

Artigos relacionados