Full tunnel i strongSwan kräver 0.0.0.0/0 på båda sidor

En full tunnel kräver 0.0.0.0/0 som klientens remote_ts och som gatewayens local_ts, plus vidarebefordran, NAT och en returväg. Kontrollera alla fyra.

En strongSwan-anslutning som fungerar för ett privat subnät kommer inte att bära internettrafik bara för att någon redigerade en rad. En full tunnel är en överenskommelse mellan två parter om vilka adresser child SA skyddar, och varje part namnger den andra sidan i förhållande till sig själv. Få ena sidan rätt och den andra fel, och child SA kommer antingen inte upp eller kommer upp smalare än tänkt. De fem kontrollerna nedan följer den överenskommelsen från klienten, genom gatewayen och ut till internet.

Kontrollera först klientens selector

Klienten beskriver vad den vill skydda på den bortre sidan som remote_ts, och allt den skickar kommer från dess egen tilldelade adress. För internettrafik måste det värdet täcka de destinationer som användaren faktiskt når, vilket i praktiken betyder hela IPv4-rymden. En klient som fortfarande listar ett subnät begär en delad tunnel, vad profilen än heter i gränssnittet. Källsidan är vanligtvis dynamic eftersom adressen tilldelas vid anslutning. En fast källa som skrivs där går sönder så snart adresspoolen ändras.

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

Fragmentet är inte en fullständig anslutningsfil, och detta förutsätter att autentisering, identiteter och poolen med virtuella adresser redan är konfigurerade. Klientens källselector och adressen som servern tilldelar måste fortfarande stämma överens, annars kommer child SA upp med en omfattning som ingen av sidorna förväntade sig. Läs in den med swanctl --load-all och läs utdata innan du antar framgång. En fil som parsas kan ändå avvisas på grund av en selector som inte överlappar den andra partens förslag.

Kontrollera gatewayens selector på dess egen sida

Gatewayen läser samma begrepp från motsatt riktning. Internetdestinationer är lokala för gatewayen, så dess local_ts är den breda och remote_ts beskriver klientpoolen. Den inversionen är det vanligaste felet i en fulltunnelkonfiguration, och den överlever granskning eftersom båda raderna ser rimliga ut var för sig.

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

Att kopiera klientfragmentet till gatewayens fil ger ett selectorpar som inte beskriver något användbart, eftersom båda sidorna skulle göra anspråk på samma roll. strongSwans vägledning för vidarebefordran dokumenterar parningen av klient och gateway explicit, och den är värd att läsa vid sidan av anslutningsfilen i stället för efter felet. Gatewayens fil behöver också pooldefinitionen som remote_ts refererar till. En selector som namnger en pool som inte finns laddas utan klagomål och misslyckas vid anslutning.

Den äldre ipsec.conf använder vänster och höger roller med olika nycklar, och en rightsubnet-rad är inte en direkt ersättning för swanctl-värdet. Håll de två syntaxerna i separata filer i stället för att klistra in den ena i den andra. Att blanda dem i en mapp är hur en fungerande anslutning tyst faller tillbaka efter en omstart.

Kontrollera den förhandlade child SA, inte filen

En sparad konfiguration bevisar avsikt och inget mer. Den andra parten kan snäva in det som begärdes, och en befintlig child SA ersätts inte bara för att filen under den har ändrats. Bekräfta vad som faktiskt är installerat innan du ändrar något annat.

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

Det första kommandot visar vad daemonen laddade, det andra visar de etablerade child SA och det tredje de policyer som kärnan kommer att tillämpa. Om filen säger 0.0.0.0/0 och listningen visar ett enda subnät har förhandlingen snävat in omfattningen, och det hjälper inte att läsa filen igen. Avsluta child, starta den igen och jämför alla tre utdata igen. En child som kommer tillbaka med samma snäva omfattning snävas in av den bortre sidan och inte av den lokala filen, och det är ett samtal med den andra administratören i stället för en lokal ändring.

Läs båda riktningarna i policylistningen, eftersom en tunnel som installerar en riktning och inte den andra är ett routingproblem i konfigurationskostym. Policyerna framåt och bakåt ska namnge samma selectorpar i spegelbild, och en saknad spegel är en defekt i daemonen eller i förslaget, inte i selectortexten.

Kontrollera vidarebefordran och returvägen

En selector släpper in trafik till gatewayen, men den får inte gatewayen att routa trafiken vidare. Vidarebefordran måste vara aktiverad, brandväggen måste tillåta flödet, och svaret måste hitta vägen tillbaka till klientpoolen. Det är tre separata krav, och varje krav misslyckas med ett annat symptom. En saknad vidarebefordringsregel beter sig som ett svart hål, medan en saknad returväg beter sig som en enkelriktad tunnel.

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

Privata klientadresser behöver vanligtvis medveten källöversättning innan de kan lämna ett offentligt gränssnitt, medan en explicit routad tilldelning kräver annan behandling. Om NAT är inblandat, behåll de undantag som implementeringen stöder så att trafik som en säkerhetspolicy ska inspektera inte översätts förbi den. En bred masquerade-regel kopierad från en annan gateway ändrar långt fler flöden än författaren avsåg. Skriv regeln bara för klientpoolen, och lämna en kommentar som förklarar varför den finns.

På klienten, bekräfta de rutter som backend installerade i stället för de rutter du antog. En hanterare med ruttinstallation avstängd behöver en design för routing som underhålls manuellt, och den designen måste uppdateras varje gång tunneln ändras. Kontrollera routingtabellen efter en återanslutning, inte bara efter en ny start.

Kontrollera vad tunneln fortfarande inte täcker

Selectorparet täcker IPv4 och inget annat. IPv6, DNS och varje policy på applikationsnivå är separata beslut som en bred IPv4-selector tyst ignorerar. En tunnel som bär varje IPv4-paket kan fortfarande läcka varje namnsökning.

Ange den avsedda DNS-vägen explicit, eftersom en full tunnel som fortfarande löser namn via den lokala resolvern läcker frågor utanför tunneln och bryter privata namn. Om klienten tilldelas en IPv6-adress behöver den adressfamiljen samma behandling, annars föredrar värden en väg som tunneln inte skyddar. Testa med ett namn som bara den privata sidan kan svara på, och behandla ett offentligt svar som en läcka.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bekräfta kedjan med de två kommandona plus de förhandlade selectorerna från listningen ovan. Om traceroute visar den lokala routern som första hopp använder trafiken inte tunneln, vad selectorerna än påstår. Internetåtkomst är bara fullständig när den valda trafiken släpps in, vidarebefordras och returneras genom den designade gatewayen. Att hitta 0.0.0.0/0 i en profil är början på den kedjan, inte beviset.

Relaterade artiklar