Volle tonnel in strongSwan vereis 0.0.0.0/0 aan albei kante

’n strongSwan-verbinding wat vir een private subnet werk, sal nie internetverkeer dra net omdat iemand een reël verander het nie. ’n Volle tonnel is ’n ooreenkoms tussen twee eweknieë oor watter adresse die child SA beskerm, en elke eweknie noem die ander kant relatief tot homself. Kry een kant reg en die ander verkeerd, en die child SA kom óf nie op nie óf kom smaller op as wat bedoel is. Die vyf kontroles hieronder volg daardie ooreenkoms van die kliënt, deur die gateway, en uit na die internet.

Kontroleer eers die kliënt se selektor

Die kliënt beskryf wat hy aan die verre kant beskerm wil hê as remote_ts, en alles wat hy stuur, kom van sy eie toegewysde adres. Vir internetverkeer moet daardie waarde die bestemmings dek wat die gebruiker werklik sal bereik, wat in die praktyk die hele IPv4-ruimte beteken. ’n Kliënt wat nog een subnet lys, vra vir ’n gesplete tonnel, ongeag wat die profiel in die koppelvlak genoem word. Die bronkant is gewoonlik dynamic omdat die adres by verbindingstyd toegewys word. ’n Vaste bron wat daar geskryf word, breek sodra die poel verander.

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

’n Fragment is nie ’n volledige verbindingslêer nie, en hierdie een aanvaar dat verifikasie, identiteite en die virtuele adrespoel reeds opgestel is. Die kliënt se bronselektor en die adres wat die bediener toewys, moet steeds ooreenstem, anders kom die child SA op met ’n omvang wat nie een van die twee kante verwag het nie. Laai dit met swanctl --load-all en lees die uitset voordat jy sukses aanvaar. ’n Lêer wat ontleed, kan steeds verwerp word vir ’n selektor wat nie met die eweknie se voorstel oorvleuel nie.

Kontroleer die gateway se selektor aan sy eie kant

Die gateway lees dieselfde begrip uit die teenoorgestelde rigting. Internetbestemmings is plaaslik aan die gateway, so sy local_ts is die wye een en sy remote_ts beskryf die kliëntpoel. Daardie omkering is die algemeenste fout in ’n volle-tonnel-opstelling, en dit oorleef hersiening omdat albei reëls op hul eie geloofwaardig lyk.

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

Om die kliëntfragment in die gateway-lêer te kopieer, lewer ’n selektorpas wat niks nuttigs beskryf nie, want albei kante sou dieselfde rol opeis. Die strongSwan-aansturingsgids dokumenteer die kliënt- en gateway-paring eksplisiet, en dit is die moeite werd om dit langs die verbindingslêer te lees eerder as ná die fout. Die gateway-lêer het ook die poeldefinisie nodig waarna remote_ts verwys. ’n Selektor wat ’n poel noem wat nie bestaan nie, laai sonder klag en faal by verbindingstyd.

Die ouerwetlike ipsec.conf gebruik linker- en regterrolle met verskillende sleutels, en ’n rightsubnet-reël is nie ’n direkte vervanging vir die swanctl-waarde nie. Hou die twee sintakses in aparte lêers in plaas daarvan om die een in die ander te plak. Om hulle in een gids te meng, is hoe ’n werkende verbinding ná ’n herbegin stilweg terugval.

Kontroleer die onderhandelde child SA, nie die lêer nie

’n Gestoorde konfigurasie bewys bedoeling en niks meer nie. ’n Eweknie kan vernou wat versoek is, en ’n bestaande child SA word nie vervang bloot omdat die lêer daaronder verander het nie. Bevestig wat werklik geïnstalleer is voordat jy iets anders verander.

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

Die eerste opdrag wys wat die daemon gelaai het, die tweede wys die child SA's wat gevestig is, en die derde wys die beleide wat die kern sal toepas. As die lêer 0.0.0.0/0 sê en die lys wys een subnet, het onderhandeling die omvang vernou, en om die lêer weer te lees sal dit nie verduidelik nie. Beëindig die child, herinisieer dit, en vergelyk al drie uitsette weer. ’n Child wat met dieselfde noue omvang terugkeer, word deur die verre kant vernou eerder as deur die plaaslike lêer, en dit is ’n gesprek met die ander administrateur in plaas van ’n plaaslike wysiging.

Lees albei rigtings in die beleidslys, want ’n tonnel wat een rigting installeer en nie die ander nie, is ’n roeteringsprobleem in konfigurasiekostuum. Die voorwaartse en omgekeerde beleide moet dieselfde paar selektore in spieëlbeeld noem, en ’n ontbrekende spieël is ’n gebrek in die daemon of in die voorstel eerder as in die selektorteks.

Kontroleer aansturing en die terugroete

’n Selektor laat verkeer na die gateway toe; dit maak nie dat die gateway daardie verkeer verder aanstuur nie. Aansturing moet geaktiveer wees, die firewall moet die vloei toelaat, en die antwoord moet sy weg terug na die kliëntpoel vind. Dit is drie afsonderlike vereistes, en elkeen faal met ’n ander simptoom. ’n Ontbrekende aanstuur-reël gedra hom soos ’n swart gat, terwyl ’n ontbrekende terugroete soos ’n eenrigtingtonnel gedra.

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

Private kliëntadresse benodig gewoonlik doelbewuste brontranslasie voordat hulle ’n openbare koppelvlak kan verlaat, terwyl ’n eksplisiet geroteerde toekenning anders hanteer moet word. As NAT in die spel is, hou die implementering se ondersteunde uitsonderings sodat verkeer wat ’n sekuriteitsbeleid moet inspekteer, nie daarlangs getransleer word nie. ’n Breë masquerade-reël wat van ’n ander gateway gekopieer is, verander baie meer strome as wat die outeur bedoel het. Skryf die reël net vir die kliëntpoel, en los ’n opmerking wat sê waarom dit bestaan.

Bevestig op die kliënt die roetes wat die backend geïnstalleer het eerder as die roetes wat jy aangeneem het. ’n Bestuurder met roete-installasie gedeaktiveer het ’n roeteringsontwerp nodig wat met die hand onderhou word, en daardie ontwerp moet opgedateer word wanneer die tonnel verander. Kontroleer die roeteringtabel ná ’n herverbinding, nie net ná ’n vars herbegin nie.

Kontroleer wat die tonnel steeds nie dek nie

Die selektorpas dek IPv4 en niks anders nie. IPv6, DNS en enige toepassingsvlakbeleid is afsonderlike besluite wat ’n breë IPv4-selektor stilweg ignoreer. ’n Tonnel wat elke IPv4-pakket dra, kan steeds elke naamsoektog lek.

Stel die beoogde DNS-pad eksplisiet, want ’n volle tonnel wat name steeds deur die plaaslike resolver oplos, lek navrae buite die tonnel en breek private name. As die kliënt ’n IPv6-adres toegewys kry, het daardie adresfamilie dieselfde behandeling nodig, anders verkies die gasheer ’n pad wat die tonnel nie beskerm nie. Toets met ’n naam wat net die private kant kan antwoord, en behandel ’n openbare antwoord as ’n lek.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Bevestig die ketting met daardie twee opdragte plus die onderhandelde selektore uit die lys hierbo. As die traceroute die plaaslike router as die eerste hop wys, gebruik die verkeer nie die tonnel nie, maak nie saak wat die selektore beweer nie. Internettoegang is eers volledig wanneer die gekose verkeer deur die ontwerpte gateway toegelaat, aangestuur en teruggekeer word. Om 0.0.0.0/0 in ’n profiel te vind, is die begin van daardie ketting eerder as die bewys daarvan.