Visas tunelis strongSwan reikalauja 0.0.0.0/0 abiejose pusėse

strongSwan ryšys, veikiantis vienam privačiam potinkliui, neperduos interneto srauto vien todėl, kad kažkas pakeitė vieną eilutę. Visas tunelis yra dviejų pusių susitarimas dėl to, kokius adresus saugo child SA, ir kiekviena pusė kitą įvardija savęs atžvilgiu. Sutvarkykite vieną pusę teisingai, o kitą neteisingai – child SA arba nepakils, arba pakils siauriau nei numatyta. Penki patikrinimai žemiau seka šį susitarimą nuo kliento per šliuzą iki interneto.

Pirmiausia patikrinkite kliento selektorių

Klientas aprašo, ką nori apsaugoti tolimoje pusėje, kaip remote_ts, ir viskas, ką jis siunčia, kyla iš jo paties priskirto adreso. Interneto srautui ši reikšmė turi apimti paskirties vietas, kurias vartotojas iš tikrųjų pasieks, o tai praktiškai reiškia visą IPv4 erdvę. Klientas, kuris vis dar išvardija vieną potinklį, prašo padalinto tunelio, kad ir kaip profilis būtų vadinamas sąsajoje. Šaltinio pusė paprastai yra dynamic, nes adresas priskiriamas jungiantis. Ten įrašytas fiksuotas šaltinis sugenda, kai tik pasikeičia adresų rinkinys.

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

Šis fragmentas nėra visas ryšio failas, ir jis daro prielaidą, kad autentifikavimas, tapatybės ir virtualių adresų rinkinys jau sukonfigūruoti. Kliento šaltinio selektorius ir serverio priskirtas adresas vis tiek turi sutapti, kitaip child SA pakils tokiu mastu, kurio nė viena pusė nesitikėjo. Įkelkite jį su swanctl --load-all ir perskaitykite išvestį prieš manydami, kad pavyko. Failas, kuris išanalizuojamas, vis tiek gali būti atmestas dėl selektoriaus, kuris nesutampa su kitos pusės pasiūlymu.

Patikrinkite šliuzo selektorių jo paties pusėje

Šliuzas tą pačią sąvoką skaito iš priešingos krypties. Interneto paskirties vietos šliuzui yra vietinės, todėl jo local_ts yra platusis, o remote_ts aprašo klientų rinkinį. Šis apvertimas yra dažniausia viso tunelio konfigūracijos klaida, ir ji išlieka peržiūroje, nes abi eilutės atskirai atrodo įtikinamai.

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

Kliento fragmento kopijavimas į šliuzo failą sukuria selektorių porą, kuri nieko naudingo neaprašo, nes abi pusės pretenduotų į tą patį vaidmenį. strongSwan persiuntimo vadovas aiškiai dokumentuoja kliento ir šliuzo poravimą, ir verta jį skaityti šalia ryšio failo, o ne po gedimo. Šliuzo failui taip pat reikia rinkinio apibrėžimo, į kurį nurodo remote_ts. Selektorius, įvardijantis neegzistuojantį rinkinį, įkeliamas be priekaištų ir nepavyksta jungiantis.

Senas ipsec.conf naudoja kairįjį ir dešinįjį vaidmenis su skirtingais raktais, o rightsubnet eilutė nėra tiesioginis swanctl reikšmės pakaitalas. Laikykite dvi sintakses atskiruose failuose, o ne įklijuokite vieną į kitą. Jų sumaišymas viename kataloge yra būdas, kuriuo veikiantis ryšys tyliai grįžta po perkrovimo.

Patikrinkite suderėtą child SA, o ne failą

Išsaugota konfigūracija įrodo ketinimą ir nieko daugiau. Kita pusė gali susiaurinti prašomą, o esamas child SA nepakeičiamas vien todėl, kad failas po juo pasikeitė. Patvirtinkite, kas iš tikrųjų įdiegta, prieš keisdami ką nors kita.

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

Pirmoji komanda parodo, ką įkėlė daemonas, antroji – nustatytus child SA, o trečioji – politikas, kurias taikys branduolys. Jei faile nurodyta 0.0.0.0/0, o sąraše matomas vienas potinklis, derybos susiaurino mastą, ir failo peržiūra to nepaaiškins. Užbaikite child, paleiskite iš naujo ir dar kartą palyginkite visas tris išvestis. Child, kuris grįžta su tuo pačiu siauru mastu, susiaurinamas tolimosios pusės, o ne vietinio failo, ir tai pokalbis su kitu administratoriumi, o ne vietinis pakeitimas.

Skaitykite abi kryptis politikų sąraše, nes tunelis, kuris įdiegia vieną kryptį, o kitos ne, yra maršruto problema konfigūracijos kostiumu. Pirmyn ir atgal politikos turi įvardyti tą pačią selektorių porą veidrodiniu atspindžiu, o trūkstamas veidrodis yra daemono ar pasiūlymo defektas, o ne selektoriaus teksto.

Patikrinkite persiuntimą ir grąžinimo maršrutą

Selektorius įleidžia srautą į šliuzą, bet nepriverčia šliuzo toliau maršrutizuoti to srauto. Turi būti įjungtas persiuntimas, ugniasienė turi leisti srautą, o atsakymas turi rasti kelią atgal į klientų rinkinį. Tai trys atskiri reikalavimai, ir kiekvienas nepavyksta su skirtingu simptomu. Trūkstama persiuntimo taisyklė elgiasi kaip juodoji skylė, o trūkstamas grąžinimo maršrutas – kaip vienkryptis tunelis.

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

Privatūs klientų adresai paprastai reikalauja sąmoningo šaltinio vertimo prieš išeinant per viešąją sąsają, o aiškiai maršrutizuotas priskyrimas reikalauja kitokio apdorojimo. Jei dalyvauja NAT, išsaugokite įgyvendinimo palaikomas išimtis, kad srautas, kurį turėtų tikrinti saugumo politika, nebūtų verčiamas pro ją. Plati masquerade taisyklė, nukopijuota iš kito šliuzo, pakeičia daug daugiau srautų, nei jos autorius ketino. Rašykite taisyklę tik klientų rinkiniui ir palikite komentarą, kodėl ji egzistuoja.

Kliente patvirtinkite maršrutus, kuriuos įdiegė backend, o ne tuos, kuriuos numatėte. Valdytojas su išjungtu maršrutų diegimu turi rankiniu būdu prižiūrimą maršrutizavimo projektą, ir jis turi būti atnaujinamas kiekvieną kartą keičiantis tuneliui. Patikrinkite maršrutizavimo lentelę po pakartotinio prisijungimo, o ne tik po naujo paleidimo.

Patikrinkite, ko tunelis vis dar neapima

Selektorių pora apima IPv4 ir nieko daugiau. IPv6, DNS ir bet kokia taikomosios programos lygmens politika yra atskiri sprendimai, kurių platus IPv4 selektorius tyliai nepaiso. Tunelis, perduodantis kiekvieną IPv4 paketą, vis tiek gali nutekinti kiekvieną vardo paiešką.

Aiškiai nurodykite numatytą DNS kelią, nes visas tunelis, kuris vis dar sprendžia vardus per vietinį resolverį, nutekina užklausas už tunelio ribų ir sugadina privačius vardus. Jei klientui priskirtas IPv6 adresas, tai adresų šeimai reikia tokio pat apdorojimo, kitaip hostas pirmenybę teiks keliui, kurio tunelis neapsaugo. Testuokite vardu, į kurį gali atsakyti tik privati pusė, ir viešą atsakymą laikykite nutekėjimu.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Patvirtinkite grandinę tomis dviem komandomis ir suderėtais selektoriais iš sąrašo aukščiau. Jei traceroute rodo vietinį maršrutizatorių kaip pirmą šuolį, srautas nenaudoja tunelio, kad ir ką teigtų selektoriai. Interneto prieiga yra visiška tik tada, kai pasirinktas srautas įleidžiamas, persiunčiamas ir grąžinamas per suprojektuotą šliuzą. 0.0.0.0/0 radimas profilyje yra tos grandinės pradžia, o ne įrodymas.