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

Ein full tunnel krev 0.0.0.0/0 som remote_ts til klienten og som local_ts til gatewayen, i tillegg til videresending, NAT og ein returveg. Kontroller alle fire.

Ei strongSwan-tilkopling som fungerer for eitt privat subnett, vil ikkje bera internettrafikk berre fordi nokon redigerte éi line. Ein full tunnel er ein avtale mellom to partar om kva adresser child SA vernar, og kvar part namngir den andre sida i høve til seg sjølv. Få den eine sida rett og den andre feil, og child SA kjem anten ikkje opp eller kjem opp smalare enn tenkt. Dei fem kontrollane nedanfor følgjer den avtalen frå klienten, gjennom gatewayen og ut til internett.

Kontroller fyrst selectoren til klienten

Klienten skildrar det han vil verne på den fjerne sida som remote_ts, og alt han sender kjem frå den eigne tildelte adressa. For internettrafikk må verdien dekkje destinasjonane brukaren faktisk når, noko som i praksis tyder heile IPv4-rommet. Ein klient som framleis listar eitt subnett ber om ein delt tunnel, kva profilen heiter i grensesnittet. Kjeldesida er vanlegvis dynamic fordi adressa blir tildelt ved tilkopling. Ei fast kjelde skriven der bryt saman så snart adressepoolen blir endra.

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

Fragmentet er ikkje ei fullstendig tilkoplingsfil, og denne føreset at autentisering, identitetar og poolen med virtuelle adresser allereie er konfigurert. Kjeldeselectoren til klienten og adressa tenaren tildeler må framleis stemme, elles kjem child SA opp med eit omfang som ingen av sidene venta. Last han med swanctl --load-all og les utdata før du reknar med suksess. Ei fil som blir parsa kan framleis bli avvist på grunn av ein selector som ikkje overlappar forslaget til den andre parten.

Kontroller selectoren til gatewayen på hans eigen side

Gatewayen les det same omgrepet frå motsett retning. Internettdestinasjonar er lokale for gatewayen, så local_ts hans er den breie og remote_ts skildrar klientpoolen. Den inversjonen er den vanlegaste feilen i ein fulltunnelkonfigurasjon, og han overlever gjennomgang fordi begge linjene ser rimelege ut kvar for seg.

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

Å kopiere klientfragmentet inn i gateway-fila gir eit selectorpar som ikkje skildrar noko nyttig, fordi begge sider ville krevje same rolle. strongSwan-veiledninga for videresending dokumenterer paringa av klient og gateway eksplisitt, og ho er verd å lese ved sida av tilkoplingsfila i staden for etter feilen. Gateway-fila treng òg pooldefinisjonen som remote_ts viser til. Ein selector som namngir ein pool som ikkje finst, blir lasta utan klage og feilar ved tilkopling.

Den eldre ipsec.conf brukar venstre og høgre roller med ulike nøklar, og ei rightsubnet-line er ikkje ei direkte erstatning for swanctl-verdien. Hald dei to syntaksane i separate filer i staden for å lime den eine inn i den andre. Å blande dei i éi mappe er måten ei fungerande tilkopling stille fell tilbake etter ein omstart.

Kontroller den forhandla child SA, ikkje fila

Ein lagra konfigurasjon bevisar hensikt og ikkje noko meir. Den andre parten kan snevre inn det som vart bede om, og ein eksisterande child SA blir ikkje erstatta berre fordi fila under han er endra. Stadfest kva som faktisk er installert før du endrar noko anna.

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

Den første kommandoen viser kva daemonen lasta, den andre viser dei etablerte child SA-ane, og den tredje viser policyane kjernen vil bruke. Viss fila seier 0.0.0.0/0 og oppføringa viser eitt subnett, har forhandlinga snevra inn omfanget, og det hjelper ikkje å lese fila på nytt. Avslutt child, start han på nytt og samanlikn alle tre utdataa igjen. Ein child som kjem tilbake med same snevre omfang, blir snevra inn av den fjerne sida og ikkje av den lokale fila, og det er ein samtale med den andre administratoren i staden for ei lokal endring.

Les begge retningar i policyoppføringa, fordi ein tunnel som installerar den eine retninga og ikkje den andre, er eit ruteproblem i konfigurasjonskostyme. Policyane framover og tilbake skal namngi det same selector-paret i spegelbilete, og ein manglande spegel er ein feil i daemonen eller i forslaget, ikkje i selectorteksten.

Kontroller videresending og returvegen

Ein selector slepp trafikk inn til gatewayen, men han får ikkje gatewayen til å rute trafikken vidare. Videresending må vere aktivert, brannmuren må tillate flyten, og svaret må finne vegen tilbake til klientpoolen. Dette er tre separate krav, og kvart av dei feilar med eit ulikt symptom. Ein manglande videresendingsregel oppfører seg som eit svart hol, medan ein manglande returveg oppfører seg som ein einvegstunnel.

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

Private klientadresser treng vanlegvis medvite kjeldeomsetjing før dei kan forlate eit offentleg grensesnitt, medan ei eksplisitt ruta tildeling krev ei anna handsaming. Viss NAT er involvert, hald unntaka implementasjonen støttar, slik at trafikk ein tryggingspolicy skal inspisere, ikkje blir omsett forbi han. Ein brei masquerade-regel kopiert frå ein annan gateway endrar langt fleire flytar enn forfattaren hadde tenkt. Skriv regelen berre for klientpoolen, og legg att ein kommentar som forklarer kvifor han finst.

På klienten, stadfest rutene backend installerte i staden for rutene du antok. Ein behandlar med ruteinstallasjon deaktivert treng eit rutedesign som blir halde ved like manuelt, og det designet må oppdaterast kvar gong tunnelen blir endra. Kontroller rutetabellen etter ei ny tilkopling, ikkje berre etter ein fersk oppstart.

Kontroller kva tunnelen framleis ikkje dekkjer

Selector-paret dekkjer IPv4 og ingenting anna. IPv6, DNS og ein kvar policy på applikasjonsnivå er separate avgjerder som ein brei IPv4-selector stille ignorerer. Ein tunnel som ber kvar IPv4-pakke, kan framleis lekke kvart namneoppslag.

Oppgi den tiltenkte DNS-vegen eksplisitt, fordi ein full tunnel som framleis løyser namn via den lokale resolveren, lek spørjingar utanfor tunnelen og øydelegg private namn. Viss klienten blir tildelt ei IPv6-adresse, treng den adressefamilien same handsaming, elles føretrekk verten ein veg tunnelen ikkje vernar. Test med eit namn berre den private sida kan svare på, og handsam eit offentleg svar som ein lekkasje.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Stadfest kjeda med dei to kommandoane pluss dei forhandla selectorane frå oppføringa ovanfor. Viss traceroute viser den lokale rutaren som første hopp, brukar trafikken ikkje tunnelen, kva selectorane enn påstår. Internettilgang er berre fullstendig når den valde trafikken blir sleppt inn, videresend og returnert gjennom den designa gatewayen. Å finne 0.0.0.0/0 i ein profil er byrjinga på den kjeda, ikkje beviset.

Relaterte artiklar