Full tunnel i strongSwan krever 0.0.0.0/0 på begge sider

En full tunnel krever 0.0.0.0/0 som klientens remote_ts og som gatewayens local_ts, i tillegg til videresending, NAT og en returvei. Kontroller alle fire.

En strongSwan-tilkobling som fungerer for ett privat subnett, vil ikke bære internettrafikk bare fordi noen redigerte én linje. En full tunnel er en avtale mellom to parter om hvilke adresser child SA beskytter, og hver part navngir den andre siden i forhold til seg selv. Få den ene siden riktig og den andre feil, og child SA kommer enten ikke opp eller kommer opp smalere enn tiltenkt. De fem kontrollene nedenfor følger den avtalen fra klienten, gjennom gatewayen og ut til internett.

Kontroller først klientens selector

Klienten beskriver det den vil beskytte på den fjerne siden som remote_ts, og alt den sender kommer fra dens egen tildelte adresse. For internettrafikk må verdien dekke destinasjonene brukeren faktisk når, noe som i praksis betyr hele IPv4-rommet. En klient som fortsatt lister ett subnett ber om en delt tunnel, uansett hva profilen heter i grensesnittet. Kildesiden er vanligvis dynamic fordi adressen tildeles ved tilkobling. En fast kilde skrevet der bryter sammen så snart adressepoolen endres.

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

Fragmentet er ikke en fullstendig tilkoblingsfil, og denne forutsetter at autentisering, identiteter og poolen med virtuelle adresser allerede er konfigurert. Klientens kildeselector og adressen serveren tildeler må fortsatt stemme overens, ellers kommer child SA opp med et omfang som ingen av sidene forventet. Last den med swanctl --load-all og les utdataene før du antar suksess. En fil som parses kan fortsatt avvises på grunn av en selector som ikke overlapper den andre partens forslag.

Kontroller gatewayens selector på dens egen side

Gatewayen leser det samme begrepet fra motsatt retning. Internettdestinasjoner er lokale for gatewayen, så dens local_ts er den brede og remote_ts beskriver klientpoolen. Den inversjonen er den vanligste feilen i en fulltunnelkonfigurasjon, og den overlever gjennomgang fordi begge linjene ser rimelige ut hver for seg.

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

Å kopiere klientfragmentet inn i gatewayens fil gir et selectorpar som ikke beskriver noe nyttig, fordi begge sider ville kreve samme rolle. strongSwan-veiledningen for videresending dokumenterer paringen av klient og gateway eksplisitt, og den er verdt å lese ved siden av tilkoblingsfilen i stedet for etter feilen. Gatewayens fil trenger også pooldefinisjonen som remote_ts viser til. En selector som navngir en pool som ikke finnes, lastes uten klage og feiler ved tilkobling.

Den eldre ipsec.conf bruker venstre og høyre roller med forskjellige nøkler, og en rightsubnet-linje er ikke en direkte erstatning for swanctl-verdien. Hold de to syntaksene i separate filer i stedet for å lime den ene inn i den andre. Å blande dem i én mappe er måten en fungerende tilkobling stille faller tilbake etter en omstart.

Kontroller den forhandlede child SA, ikke filen

En lagret konfigurasjon beviser hensikt og ikke noe mer. Den andre parten kan innsnevre det som ble bedt om, og en eksisterende child SA erstattes ikke bare fordi filen under den er endret. Bekreft hva som faktisk er installert før du endrer noe annet.

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

Den første kommandoen viser hva daemonen lastet, den andre viser de etablerte child SA-ene, og den tredje viser policyene kjernen vil bruke. Hvis filen sier 0.0.0.0/0 og oppføringen viser ett subnett, har forhandlingen innsnevret omfanget, og det hjelper ikke å lese filen på nytt. Avslutt child, start den på nytt og sammenlign alle tre utdataene igjen. En child som kommer tilbake med samme snevre omfang, innsnevres av den fjerne siden og ikke av den lokale filen, og det er en samtale med den andre administratoren i stedet for en lokal endring.

Les begge retninger i policyoppføringen, fordi en tunnel som installerer den ene retningen og ikke den andre, er et ruteproblem i konfigurasjonskostyme. Policyene fremover og tilbake skal navngi det samme selector-paret i speilbilde, og et manglende speil er en feil i daemonen eller i forslaget, ikke i selectorteksten.

Kontroller videresending og returveien

En selector slipper trafikk inn til gatewayen, men den får ikke gatewayen til å rute trafikken videre. Videresending må være aktivert, brannmuren må tillate flyten, og svaret må finne veien tilbake til klientpoolen. Dette er tre separate krav, og hvert av dem feiler med et forskjellig symptom. En manglende videresendingsregel oppfører seg som et svart hull, mens en manglende returrute oppfører seg som en enveistunnel.

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

Private klientadresser trenger vanligvis bevisst kildeoversettelse før de kan forlate et offentlig grensesnitt, mens en eksplisitt rutet tildeling krever annen behandling. Hvis NAT er involvert, behold unntakene implementasjonen støtter, slik at trafikk en sikkerhetspolicy skal inspisere, ikke oversettes forbi den. En bred masquerade-regel kopiert fra en annen gateway endrer langt flere flyter enn forfatteren hadde tenkt. Skriv regelen bare for klientpoolen, og legg igjen en kommentar som forklarer hvorfor den finnes.

På klienten, bekreft rutene backend installerte i stedet for rutene du antok. En behandler med ruteinstallasjon deaktivert trenger et rutedesign som vedlikeholdes manuelt, og det designet må oppdateres hver gang tunnelen endres. Kontroller rutetabellen etter en gjentilkobling, ikke bare etter en fersk oppstart.

Kontroller hva tunnelen fortsatt ikke dekker

Selector-paret dekker IPv4 og ingenting annet. IPv6, DNS og enhver policy på applikasjonsnivå er separate beslutninger som en bred IPv4-selector stille ignorerer. En tunnel som bærer hver IPv4-pakke, kan fortsatt lekke hvert navneoppslag.

Oppgi den tiltenkte DNS-veien eksplisitt, fordi en full tunnel som fortsatt løser navn via den lokale resolveren, lekker spørringer utenfor tunnelen og ødelegger private navn. Hvis klienten tildeles en IPv6-adresse, trenger den adressefamilien samme behandling, ellers foretrekker verten en vei tunnelen ikke beskytter. Test med et navn bare den private siden kan svare på, og behandle et offentlig svar som en lekkasje.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bekreft kjeden med de to kommandoene pluss de forhandlede selectorene fra oppføringen ovenfor. Hvis traceroute viser den lokale ruteren som første hopp, bruker trafikken ikke tunnelen, uansett hva selectorene påstår. Internettilgang er bare komplett når den valgte trafikken slippes inn, videresendes og returneres gjennom den designede gatewayen. Å finne 0.0.0.0/0 i en profil er begynnelsen på den kjeden, ikke beviset.

Relaterte artikler