El túnel complet a strongSwan necessita 0.0.0.0/0 als dos extrems

Una connexió strongSwan que funciona per a una subxarxa privada no transportarà tràfic d'internet només perquè algú hagi editat una sola línia. Un túnel complet és un acord entre dos extrems sobre quines adreces protegeix el child SA, i cada extrem nomena l'altre respecte de si mateix. Enceneu bé un costat i malament l'altre, i el child SA o no s'aixeca o s'aixeca més estret del previst. Les cinc comprovacions següents segueixen aquest acord des del client, per la passarel·la, fins a internet.

Comproveu primer el selector del client

El client descriu el que vol protegir a l'extrem llunyà com a remote_ts, i tot el que envia s'origina a la seva pròpia adreça assignada. Per al tràfic d'internet, aquest valor ha de cobrir les destinacions que l'usuari realment assolirà, cosa que a la pràctica significa tot l'espai IPv4. Un client que encara llista una subxarxa demana un túnel dividit, sigui quin sigui el nom del perfil a la interfície. El costat d'origen sol ser dynamic perquè l'adreça s'assigna en connectar. Una font fixa escrita allà es trenca tan bon punt canvia el conjunt d'adreces.

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

El fragment no és un fitxer de connexió complet, i aquest dona per fet que l'autenticació, les identitats i el conjunt d'adreces virtuals ja estan configurats. El selector d'origen del client i l'adreça que assigna el servidor encara s'han de correspondre, o el child SA s'aixeca amb un abast que cap dels dos costats esperava. Carregueu-lo amb swanctl --load-all i llegiu la sortida abans de suposar èxit. Un fitxer que es parseja encara pot ser rebutjat per un selector que no se superposa a la proposta de l'altre extrem.

Comproveu el selector de la passarel·la al seu costat

La passarel·la llegeix el mateix concepte des de la direcció oposada. Les destinacions d'internet són locals a la passarel·la, així que el seu local_ts és el ample i el seu remote_ts descriu el conjunt de clients. Aquesta inversió és l'error més habitual en una configuració de túnel complet, i sobreviu a la revisió perquè totes dues línies semblen plausibles per separat.

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

Copiar el fragment del client al fitxer de la passarel·la produeix una parella de selectors que no descriu res d'útil, perquè tots dos costats reclamarien el mateix paper. La guia d'encaminament de strongSwan documenta explícitament l'aparellament de client i passarel·la, i val la pena llegir-la al costat del fitxer de connexió en lloc de després del fracàs. El fitxer de la passarel·la també necessita la definició del conjunt d'adreces a què fa referència remote_ts. Un selector que anomena un conjunt inexistent es carrega sense queixes i falla en connectar.

L'antic ipsec.conf fa servir papers esquerre i dret amb claus diferents, i una línia rightsubnet no és un substitut directe del valor de swanctl. Manteniu les dues sintaxis en fitxers separats en lloc d'enganxar-ne una dins l'altra. Barrejar-les en un sol directori és com una connexió que funciona torna en silenci després d'un reinici.

Comproveu el child SA negociat, no el fitxer

Una configuració desada només demostra la intenció. L'altre extrem pot estrenyer el que es va demanar, i un child SA existent no es reemplaça només perquè el fitxer de sota ha canviat. Confirmeu què hi ha realment instal·lat abans de canviar res més.

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

La primera ordre mostra què ha carregat el dimoni, la segona mostra els child SA establerts i la tercera les polítiques que aplicarà el nucli. Si el fitxer diu 0.0.0.0/0 i el llistat mostra una sola subxarxa, la negociació ha estret l'abast i rellegir el fitxer no ho explicarà. Acabeu el child, torneu-lo a iniciar i compareu de nou les tres sortides. Un child que torna amb el mateix abast estret l'està estrenyent l'altre extrem, no el fitxer local, i això és una conversa amb l'altre administrador, no una edició local.

Llegiu totes dues direccions al llistat de polítiques, perquè un túnel que instal·la una direcció i no l'altra és un problema d'encaminament disfressat de configuració. Les polítiques d'anada i tornada han d'anomenar la mateixa parella de selectors en imatge mirall, i un mirall absent és un defecte del dimoni o de la proposta, no del text del selector.

Comproveu l'encaminament i la ruta de retorn

Un selector admet tràfic cap a la passarel·la; no fa que la passarel·la encamini aquest tràfic més enllà. Cal habilitar l'encaminament, el tallafocs ha de permetre el flux i la resposta ha de trobar el camí de tornada al conjunt de clients. Són tres requisits separats, i cadascun falla amb un símptoma diferent. Una regla d'encaminament absent es comporta com un forat negre, mentre que una ruta de retorn absent es comporta com un túnel d'un sol sentit.

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

Les adreces privades dels clients solen necessitar una traducció d'origen deliberada abans de sortir per una interfície pública, mentre que una assignació encaminada explícitament requereix un tracte diferent. Si hi ha NAT, manteniu les excepcions que la implementació admet perquè el tràfic que una política de seguretat ha d'inspeccionar no es tradueixi més enllà. Una regla masquerade àmplia copiada d'una altra passarel·la canvia molts més fluxos del que el seu autor pretenia. Escriviu la regla només per al conjunt de clients i deixeu un comentari explicant per què existeix.

Al client, confirmeu les rutes que ha instal·lat el backend, no les rutes que heu suposat. Un gestor amb la instal·lació de rutes desactivada necessita un disseny d'encaminament mantingut a mà, i aquest disseny s'ha d'actualitzar sempre que canviï el túnel. Comproveu la taula d'encaminament després de reconnectar, no només després d'un arrencada nova.

Comproveu què continua sense cobrir el túnel

La parella de selectors cobreix IPv4 i res més. IPv6, DNS i qualsevol política a nivell d'aplicació són decisions separades que un selector IPv4 ampli ignora en silenci. Un túnel que transporta cada paquet IPv4 encara pot filtrar cada consulta de nom.

Expliciteu el camí DNS previst, perquè un túnel complet que encara resol noms pel resolutor local filtra consultes fora del túnel i trenca noms privats. Si al client se li assigna una adreça IPv6, aquesta família d'adreces necessita el mateix tracte, o l'amfitrió preferirà un camí que el túnel no protegeix. Proveu amb un nom que només el costat privat pugui respondre, i tracteu una resposta pública com una fuita.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirmeu la cadena amb aquestes dues ordres més els selectors negociats del llistat anterior. Si el traceroute mostra el router local com a primer salt, el tràfic no fa servir el túnel faci el que faci afirmar els selectors. L'accés a internet és complet només quan el tràfic triat s'admet, s'encamina i torna per la passarel·la dissenyada. Trobat 0.0.0.0/0 en un perfil és el començament d'aquesta cadena, no la prova.