Folsleine tunnel yn strongSwan freget 0.0.0.0/0 oan beide kanten

In folsleine tunnel freget 0.0.0.0/0 as remote_ts fan 'e klant en as local_ts fan 'e poarte, plus trochstjoering, NAT en in weromrûte. Kontrolearje alle fjouwer.

In strongSwan-ferbining dy't wurket foar ien privee subnet sil net ynternetferkear drage allinnich om't immen ien rigel bewurke hat. In folsleine tunnel is in oerienkomst tusken twa kanten oer hokker adressen de child SA beskermet, en elke kant neamt de oare kant yn ferhâlding ta himsels. Krij ien kant goed en de oare ferkeard, en de child SA komt óf net omheech óf komt smeller omheech as bedoeld. De fiif kontrôles hjirûnder folgje dy oerienkomst fan 'e klant, troch de poarte, en út nei it ynternet.

Kontrolearje earst de selektor fan 'e klant

De klant beskriuwt wat er oan 'e fiere kant beskermje wol as remote_ts, en alles wat er stjoert komt fan syn eigen tawiisde adres. Foar ynternetferkear moat dy wearde de bestimmings dekke dy't de brûker echt berikke sil, wat yn 'e praktyk de hiele IPv4-romte betsjut. In klant dy't noch ien subnet neamt, freget om in splitst tunnel, hoe't it profyl yn 'e ynterface ek hjit. De boarne kant is meast dynamic om't it adres by ferbinen tawiisd wurdt. In feste boarne dy't dêr skreaun is, brekt sa gau as de adresgroep feroaret.

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

It fragmint is gjin folsleine ferbiningsbestân, en dit iene nimt oan dat autentikaasje, identiteiten en de groep firtuele adressen al konfigurearre binne. De boarneselektor fan 'e klant en it adres dat de tsjinner tawiist, moatte noch oerienkomme, oars komt de child SA omheech mei in berik dat gjin fan beide kanten ferwachte. Laad it mei swanctl --load-all en lês de útfier foardat jo sukses oannimme. In bestân dat parset, kin noch altyd wegere wurde fanwegen in selektor dy't net oerlapet mei it foarstel fan 'e oare kant.

Kontrolearje de selektor fan 'e poarte oan har eigen kant

De poarte lêst itselde begryp fan 'e tsjinoerstelde rjochting. Ynternetbestimmings binne lokaal foar de poarte, dus har local_ts is de brede en har remote_ts beskriuwt de klantgroep. Dy omkearing is de meast foarkommende flater yn in folsleine-tunnelkonfiguraasje, en it oerlibbet de beoardieling om't beide rigels apart leauwich lykje.

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

It fragmint fan 'e klant yn it poartebestân kopiearje jout in selektorpair dat neat nuttich beskriuwt, om't beide kanten deselde rol opeaskje soene. De strongSwan-hantlieding foar trochstjoering dokumintearret de pearing fan klant en poarte eksplisyt, en it is de muoite wurdich dy njonken it ferbiningsbestân te lêzen ynstee fan nei it falen. It poartebestân hat ek de definysje fan 'e groep nedich dêr't remote_ts nei ferwiist. In selektor dy't in net-besteande groep neamt, laadt sûnder klacht en falt by ferbinen.

De âlde ipsec.conf brûkt lofter- en rjochterrollen mei ferskillende kaaien, en in rightsubnet-rigel is gjin direkte ferfanging foar de swanctl-wearde. Hâld de twa syntaksen yn aparte bestannen ynstee fan de iene yn 'e oare te plakken. Se yn ien map mingje is hoe't in wurkjende ferbining nei in werstart stil werom falt.

Kontrolearje de ûnderhannele child SA, net it bestân

In bewarre konfiguraasje bewiist bedoeling en neat mear. In kant kin ferfiene wat frege is, en in besteande child SA wurdt net ferfongen allinnich om't it bestân derûnder feroare is. Befestigje wat eins ynstallearre is foardat jo eat oars feroarje.

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

It earste kommando lit sjen wat de daemon laden hat, it twadde lit de oprjochte child SA's sjen, en it tredde lit de beliedsregels sjen dy't de kernel tapasse sil. As it bestân 0.0.0.0/0 seit en de list lit ien subnet sjen, hat de ûnderhanneling it berik ferfine en it bestân opnij lêzen sil dat net ferklearje. Beëinigje de child, start it opnij en fergelykje alle trije útfieren wer. In child dy't mei itselde smelle berik weromkomt, wurdt troch de fiere kant ferfine en net troch it lokale bestân, en dat is in petear mei de oare behearder ynstee fan in lokale bewurking.

Lês beide rjochtingen yn 'e beliedslist, want in tunnel dy't ien rjochting ynstallearret en net de oare is in routingprobleem yn konfiguraasjekleane. De foarút- en werom-beliedsregels moatte itselde selektorpair yn spegelbyld neame, en in missende spegel is in defekt yn 'e daemon of yn it foarstel en net yn 'e selektortekst.

Kontrolearje trochstjoering en de weromrûte

In selektor lit ferkear ta nei de poarte; it makket net dat de poarte dat ferkear fierder rûtet. Trochstjoering moat oan stean, de fjoerwâl moat de stream tastean, en it antwurd moat syn wei werom fine nei de klantgroep. Dat binne trije aparte easken, en elk falt mei in oar symptoom. In missende trochstjoerregel hâldt him as in swart gat, wylst in missende weromrûte him as in ienrjochtingstunnel hâldt.

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

Privee klantadressen hawwe meast bewuste boarnetranslaasje nedich foardat se in iepenbiere ynterface ferlitte kinne, wylst in eksplisyt rûtearre tawizing oare behanneling freget. As NAT yn it spul is, hâld de troch de ymplemintaasje stipe útsûnderingen sadat ferkear dat in feilichheidsbelied ynspesearje moat net bylâns translatet wurdt. In brede masquerade-regel kopiearre fan in oare poarte feroaret folle mear streamen as de auteur bedoelde. Skriuw de regel allinnich foar de klantgroep, en lit in kommentaar stean dy't seit wêrom't er bestiet.

Befestigje op 'e klant de rûtes dy't de backend ynstallearre hat ynstee fan 'e rûtes dy't jo oannommen hawwe. In behearder mei rûteynstallaasje útskeakele hat in mei de hân ûnderhâlden routingûntwerp nedich, en dat ûntwerp moat bywurke wurde as de tunnel feroaret. Kontrolearje de routingtabel nei opnij ferbinen, net allinnich nei in frisse start.

Kontrolearje wat de tunnel noch net beslacht

It selektorpair beslacht IPv4 en neat oars. IPv6, DNS en elk belied op applikaasjenivo binne aparte besluten dy't in breed IPv4-selektor stil negearret. In tunnel dy't elk IPv4-pakket draacht, kin noch altyd elke namesykje lekke.

Neam it bedoelde DNS-paad eksplisyt, want in folsleine tunnel dy't noch altyd nammen fia de lokale resolver oplost, lekt fragen bûten de tunnel en brekt privee nammen. As de klant in IPv6-adres tawiisd krijget, hat dy adresfamylje deselde behanneling nedich, oars foarkomt de host in paad dat de tunnel net beskermet. Test mei in namme dy't allinnich de privee kant beantwurdzje kin, en behannelje in iepenbier antwurd as in lek.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Befestigje de keatling mei dy twa kommando's plus de ûnderhannele selektors fan 'e list hjirboppe. As de traceroute de lokale router as earste hop sjen lit, brûkt it ferkear de tunnel net, wat de selektors ek beweare. Ynternettagong is pas folslein as it keazen ferkear troch de ûntwurpen poarte tastien, trochstjoerd en werom brocht wurdt. It finen fan 0.0.0.0/0 yn in profyl is it begjin fan dy keatling en net it bewiis.

Relatearre artikelen