Fuld tunnel i strongSwan kræver 0.0.0.0/0 i begge ender

En strongSwan-forbindelse, der virker til et enkelt privat undernet, sender ikke internettrafik, bare fordi nogen har redigeret én linje. En fuld tunnel er en aftale mellem to parter om, hvilke adresser child SA beskytter, og hver part navngiver den anden side i forhold til sig selv. Få den ene side rigtig og den anden forkert, og child SA kommer enten ikke op eller kommer op smallere end tilsigtet. De fem kontroller nedenfor følger den aftale fra klienten, gennem gatewayen og ud til internettet.

Kontroller først klientens selector

Klienten beskriver, hvad den vil beskytte på den fjerne side, som remote_ts, og alt, hvad den sender, udgår fra dens egen tildelte adresse. For internettrafik skal den værdi dække de destinationer, brugeren faktisk når, hvilket i praksis betyder hele IPv4-rummet. En klient, der stadig angiver ét undernet, beder om en delt tunnel, uanset hvad profilen hedder i grænsefladen. Kildesiden er normalt dynamic, fordi adressen tildeles ved forbindelse. En fast kilde, der skrives der, bryder sammen, så snart puljen ændres.

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

Fragmentet er ikke en komplet forbindelsesfil, og denne forudsætter, at godkendelse, identiteter og puljen af virtuelle adresser allerede er konfigureret. Klientens kildeselector og den adresse, serveren tildeler, skal stadig stemme overens, ellers kommer child SA op med et omfang, som ingen af siderne forventede. Indlæs den med swanctl --load-all og læs outputtet, før du antager succes. En fil, der parser, kan stadig afvises på grund af en selector, der ikke overlapper den anden parts forslag.

Kontroller gatewayens selector på dens egen side

Gatewayen læser det samme begreb fra den modsatte retning. Internetdestinationer er lokale for gatewayen, så dens local_ts er den brede, og remote_ts beskriver klientpuljen. Den inversion er den mest almindelige fejl i en fuld-tunnel-konfiguration, og den overlever gennemgang, fordi begge linjer ser rimelige ud hver for sig.

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

At kopiere klientfragmentet ind i gatewayens fil giver et selectorpar, der ikke beskriver noget nyttigt, fordi begge sider ville gøre krav på samme rolle. strongSwan-vejledningen om forwarding dokumenterer parringen af klient og gateway eksplicit, og den er værd at læse ved siden af forbindelsesfilen i stedet for efter fejlen. Gatewayens fil skal også have den puljedefinition, som remote_ts henviser til. En selector, der navngiver en pulje, der ikke findes, indlæses uden klage og fejler ved forbindelse.

Den ældre ipsec.conf bruger venstre og højre roller med forskellige nøgler, og en rightsubnet-linje er ikke en direkte erstatning for swanctl-værdien. Hold de to syntakser i separate filer i stedet for at indsætte den ene i den anden. At blande dem i én mappe er måden, hvorpå en fungerende forbindelse stille vender tilbage efter en genstart.

Kontroller den forhandlede child SA, ikke filen

En gemt konfiguration beviser hensigt og intet mere. En part kan indsnævre det ønskede, og en eksisterende child SA erstattes ikke blot, fordi filen under den er ændret. Bekræft, hvad der faktisk er installeret, før du ændrer noget andet.

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

Den første kommando viser, hvad daemonen har indlæst, den anden viser de etablerede child SA'er, og den tredje viser de politikker, som kernen vil anvende. Hvis filen siger 0.0.0.0/0, og listen viser et enkelt undernet, har forhandlingen indsnævret omfanget, og det hjælper ikke at læse filen igen. Afslut child, genstart den, og sammenlign alle tre output igen. En child, der vender tilbage med samme snævre omfang, indsnævres af den fjerne side snarere end af den lokale fil, og det er en samtale med den anden administrator i stedet for en lokal ændring.

Læs begge retninger i politiklisten, fordi en tunnel, der installerer den ene retning og ikke den anden, er et routingproblem i konfigurationskostume. Politikkerne frem og tilbage skal navngive det samme selectorpar i spejlvendt form, og et manglende spejl er en defekt i daemonen eller i forslaget snarere end i selectorteksten.

Kontroller forwarding og returvejen

En selector lukker trafik ind til gatewayen; den får ikke gatewayen til at route trafikken videre. Forwarding skal være aktiveret, firewallen skal tillade flowet, og svaret skal finde vej tilbage til klientpuljen. Det er tre separate krav, og hvert af dem fejler med et forskelligt symptom. En manglende forwarding-regel opfører sig som et sort hul, mens en manglende returrute opfører sig som en envejstunnel.

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

Private klientadresser har normalt brug for bevidst kildetranslation, før de kan forlade en offentlig grænseflade, mens en eksplicit routet tildeling kræver en anden behandling. Hvis NAT er involveret, behold de undtagelser, implementeringen understøtter, så trafik, som en sikkerhedspolitik bør inspicere, ikke oversættes forbi den. En bred masquerade-regel kopieret fra en anden gateway ændrer langt flere flows, end dens forfatter havde tænkt. Skriv reglen kun for klientpuljen, og efterlad en kommentar, der forklarer, hvorfor den findes.

Bekræft på klienten de ruter, backend installerede, i stedet for de ruter, du antog. En manager med ruteinstallation deaktiveret har brug for et routingdesign, der vedligeholdes manuelt, og det design skal opdateres, hver gang tunnelen ændres. Kontroller routingtabellen efter en genforbindelse, ikke kun efter en frisk opstart.

Kontroller, hvad tunnelen stadig ikke dækker

Selectorparret dækker IPv4 og intet andet. IPv6, DNS og enhver politik på applikationsniveau er separate beslutninger, som en bred IPv4-selector stiltiende ignorerer. En tunnel, der bærer hver IPv4-pakke, kan stadig lække hvert navneopslag.

Angiv den tilsigtede DNS-vej eksplicit, fordi en fuld tunnel, der stadig opløser navne via den lokale resolver, lækker forespørgsler uden for tunnelen og ødelægger private navne. Hvis klienten tildeles en IPv6-adresse, har den adressefamilie brug for samme behandling, ellers foretrækker værten en vej, som tunnelen ikke beskytter. Test med et navn, som kun den private side kan svare på, og behandl et offentligt svar som en lækage.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bekræft kæden med de to kommandoer plus de forhandlede selectors fra listen ovenfor. Hvis traceroute viser den lokale router som første hop, bruger trafikken ikke tunnelen, uanset hvad selectorerne påstår. Internetadgang er først komplet, når den valgte trafik lukkes ind, videresendes og returneres gennem den designede gateway. At finde 0.0.0.0/0 i en profil er begyndelsen på den kæde snarere end beviset.