Pilnam tunelim strongSwan vajag 0.0.0.0/0 abās pusēs

strongSwan savienojums, kas darbojas vienam privātam apakštīklam, nepārvadās interneta trafiku tikai tāpēc, ka kāds rediģēja vienu rindu. Pilns tunelis ir divu pušu vienošanās par to, kuras adreses aizsargā child SA, un katra puse nosauc otru attiecībā pret sevi. Izlabojiet vienu pusi un otru nepareizi – child SA vai nu nepaceļas, vai paceļas šaurāk nekā paredzēts. Piecas pārbaudes zemāk seko šai vienošanās no klienta, caur vārteju, līdz internetam.

Vispirms pārbaudiet klienta selektoru

Klients apraksta, ko vēlas aizsargāt attālajā pusē, kā remote_ts, un viss, ko tas sūta, nāk no tā paša piešķirtās adreses. Interneta trafikam šai vērtībai jāaptver galamērķi, kurus lietotājs faktiski sasniegs, kas praksē nozīmē visu IPv4 telpu. Klients, kas joprojām uzskaita vienu apakštīklu, pieprasa sadalītu tuneli, lai kā profils tiek saukts saskarnē. Avota puse parasti ir dynamic, jo adrese tiek piešķirta savienošanās laikā. Tur ierakstīts fiksēts avots salūzt, tiklīdz mainās adrešu kopa.

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

Šis fragments nav pilnīga savienojuma datne, un tas pieņem, ka autentifikācija, identitātes un virtuālo adrešu kopa jau ir konfigurēta. Klienta avota selektoram un servera piešķirtajai adresei joprojām jāsakrīt, citādi child SA paceļas ar tvērumu, ko negaidīja neviena puse. Ielādējiet to ar swanctl --load-all un izlasiet izvadi, pirms pieņemat panākumus. Datne, kas tiek parsēta, tomēr var tikt noraidīta selektora dēļ, kas nepārklājas ar otras puses priekšlikumu.

Pārbaudiet vārtejas selektoru tās pašas pusē

Vārteja to pašu jēdzienu lasa pretējā virzienā. Interneta galamērķi vārtejai ir lokāli, tāpēc tās local_ts ir platais un remote_ts apraksta klientu kopu. Šī inversija ir visbiežākā kļūda pilna tuneļa konfigurācijā, un tā iztur pārskatīšanu, jo abas rindas atsevišķi izskatās ticamas.

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

Klienta fragmenta kopēšana vārtejas datnē rada selektoru pāri, kas neapraksta neko noderīgu, jo abas puses pieprasītu vienu un to pašu lomu. strongSwan pārsūtīšanas rokasgrāmata skaidri dokumentē klienta un vārtejas savienošanu pārī, un to ir vērts lasīt blakus savienojuma datnei, nevis pēc neveiksmes. Vārtejas datnei vajadzīga arī tās kopas definīcija, uz kuru norāda remote_ts. Selektors, kas nosauc neesošu kopu, ielādējas bez iebildumiem un neizdodas savienojoties.

Vecais ipsec.conf izmanto kreiso un labo lomu ar dažādām atslēgām, un rightsubnet rinda nav tiešs swanctl vērtības aizstājējs. Turiet abas sintakses atsevišķās datnēs, nevis ielīmējiet vienu otrā. To sajaukšana vienā direktorijā ir veids, kā strādājošs savienojums pēc pārstartēšanas klusi atgriežas iepriekšējā stāvoklī.

Pārbaudiet saskaņoto child SA, nevis datni

Saglabāta konfigurācija pierāda nodomu un neko vairāk. Otra puse var sašaurināt pieprasīto, un esošais child SA netiek aizstāts tikai tāpēc, ka datne zem tā ir mainījusies. Apstipriniet, kas faktiski ir instalēts, pirms maināt ko citu.

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

Pirmā komanda parāda, ko ielādēja dēmons, otrā – izveidotos child SA, trešā – politikas, ko piemēros kodols. Ja datnē teikts 0.0.0.0/0, bet saraksts rāda vienu apakštīklu, sarunas ir sašaurinājušas tvērumu, un datnes atkārtota lasīšana to neizskaidros. Pārtrauciet child, startējiet to no jauna un vēlreiz salīdziniet visas trīs izvades. Child, kas atgriežas ar to pašu šauro tvērumu, tiek sašaurināts no attālās puses, nevis no vietējās datnes, un tā ir saruna ar otru administratoru, nevis vietēja izmaiņa.

Lasiet abus virzienus politiku sarakstā, jo tunelis, kas instalē vienu virzienu un ne otru, ir maršrutēšanas problēma konfigurācijas kostīmā. Uz priekšu un atpakaļ vērstajām politikām jānosauc viens un tas pats selektoru pāris spoguļattēlā, un trūkstošais spogulis ir dēmona vai priekšlikuma defekts, nevis selektora teksta.

Pārbaudiet pārsūtīšanu un atgriešanās maršrutu

Selektors ielaiž trafiku vārtejā, bet tas neliek vārtejai to tālāk maršrutēt. Pārsūtīšanai jābūt ieslēgtai, ugunsmūrim jāatļauj plūsma, un atbildei jāatrod ceļš atpakaļ uz klientu kopu. Tie ir trīs atsevišķi nosacījumi, un katrs neizdodas ar citu simptomu. Trūkstošs pārsūtīšanas noteikums uzvedas kā melnais caurums, bet trūkstošs atgriešanās maršruts – kā vienvirziena tunelis.

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

Privātām klientu adresēm parasti vajadzīga apzināta avota tulkošana pirms iziešanas no publiskās saskarnes, bet skaidri maršrutētam piešķīrumam vajadzīga cita apstrāde. Ja iesaistīts NAT, saglabājiet implementācijas atbalstītos izņēmumus, lai trafiks, ko drošības politikai jāpārbauda, netiktu tulkots tai garām. Plašs masquerade noteikums, kas nokopēts no citas vārtejas, maina daudz vairāk plūsmu, nekā tā autors bija iecerējis. Rakstiet noteikumu tikai klientu kopai un atstājiet komentāru, kāpēc tas pastāv.

Klientā apstipriniet maršrutus, ko instalēja backend, nevis tos, ko pieņēmāt. Pārvaldniekam ar izslēgtu maršrutu instalēšanu vajadzīgs manuāli uzturēts maršrutēšanas projekts, un tas jāatjaunina ikreiz, kad mainās tunelis. Pārbaudiet maršrutēšanas tabulu pēc atkārtotas savienošanās, ne tikai pēc svaigas palaišanas.

Pārbaudiet, ko tunelis joprojām neaptver

Selektoru pāris aptver IPv4 un neko citu. IPv6, DNS un jebkura lietojumprogrammu līmeņa politika ir atsevišķi lēmumi, ko plašs IPv4 selektors klusi ignorē. Tunelis, kas pārvadā katru IPv4 paketi, joprojām var noplūdināt katru nosaukuma meklēšanu.

Skaidri norādiet paredzēto DNS ceļu, jo pilns tunelis, kas joprojām atrisina nosaukumus ar vietējo risinātāju, noplūdina vaicājumus ārpus tuneļa un salauž privātos nosaukumus. Ja klientam piešķirta IPv6 adrese, šai adrešu saimei vajadzīga tāda pati apstrāde, citādi resursdators dos priekšroku ceļam, ko tunelis neaizsargā. Pārbaudiet ar nosaukumu, uz kuru var atbildēt tikai privātā puse, un publisku atbildi uzskatiet par noplūdi.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Apstipriniet ķēdi ar šīm divām komandām un saskaņotajiem selektoriem no saraksta augstāk. Ja traceroute rāda vietējo maršrutētāju kā pirmo lēcienu, trafiks neizmanto tuneli, lai ko apgalvotu selektori. Interneta piekļuve ir pilnīga tikai tad, kad izvēlētais trafiks tiek ielaists, pārsūtīts un atgriezts caur projektēto vārteju. 0.0.0.0/0 atrašana profilā ir šīs ķēdes sākums, nevis pierādījums.