Kahekihilise virna VPN-varamud: mõlema aadressiperekonna adresseerimine strongSwanis

Sisemised IPv4 ja IPv6 varamud, kaitstud prefiksid ja välimise tunneli perekond on kolm eraldi otsust. Planeerige igaüks enne, kui nimetate selle kahekihiliseks virnaks.

Lüüs saab anda rändurile nii IPv4 kui ka IPv6 virtuaalaadressi, samal ajal kui välimine tunnel liigub endiselt üle IPv4. Need on sõltumatud otsused ja nende käsitlemine ühena on koht, kus kahekihilise virna plaanid tavaliselt lagunevad. Kliendi sisemised perekonnad, kaitstud prefiksid, milleni ta võib jõuda, ja transport, mis kapselduse kannab, on kolm eraldi valikut.

Suurem osa segadusest tuleb sellest, et sõna kahekihiline virn rakendatakse kujundusele, mis on kahekihiline ainult ühes kohas. Teenus võib olla seestpoolt kahekihiline, oma välisaadressil ühekihiline ja ikkagi klientide jaoks täiesti hästi toimida. Mida ta ei saa, on toimida juhuslikult.

Kaks perekonda sees, üks tee väljas

Välimine ühendus on IKE üle UDP ja see vajab üht kättesaadavat aadressiperekonda sealt, kus klient parasjagu on. Sisemine IPv6-aadress ei nõua IPv6-toega teenusepakkujat, sest sisemine pakett on kasulik koorem välimise sees. Paljud toimivad juurutused kannavad IPv6-prefikseid ainult-IPv4 üleslingi kaudu.

Mida välimine tee tõesti piirab, on kättesaadavus ja NAT-i läbimine. Kui lüüs kuulutab ainult IPv4-aadressi, ei saa ainult-IPv6 võrgus olev klient üldse ühendust, ükskõik milliseid varamuid te seadistasite. Otsustage välimine perekond oma kliendibaasi järgi, mitte sisemise aadressiplaani järgi.

Andke kliendile aadress igas perekonnas

Mõlema perekonna küsimine on kliendi poolel üherealine lause, eeldusel et lüüsil on midagi jagada. Nimega varamud hoiavad allikad teenusevõrkudest eraldi ja just see omadus teeb tulemüürireeglid kuus kuud hiljem loetavaks.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Väärtus vips küsib aadressi igast perekonnast ja varamute loend otsustab, kust need aadressid tulevad. Dokumentatsioon strongSwan virtuaalsete IP-aadresside kohta katab mitut päringut ja varamute määramist, sealhulgas seda, et konkreetset aadressi küsiv klient väljendab vaid eelistust, mille vastaja võib tühistada. Ärge ehitage juurdepääsureeglit, mis eeldab, et klient saab alati sama väärtuse.

Looge oma unikaalne lokaalne prefiks selle asemel, et näidist kopeerida. Kaks organisatsiooni, mis mõlemad fd42::/16 selle juurutavad, avastavad kokkupõrke esimesel omavahelisel ühendamisel ja selle diagnoosimine ei ole meeldiv.

Selektorid kirjeldavad sihtkohti, mitte allikaid

Alam-SA kohalikud liiklusselektorid ütlevad, millised kaitstud võrgud asuvad lüüsi taga, ja kaugselektorid kirjeldavad, mida klient tohib allikana kasutada. Virtuaalse varamu aadress kuulub selle poliitika allikapoolsele küljele; selle panemine sihtkohtade loendisse on konfiguratsiooni levinud vale lugemine.

Mõlemad perekonnad vajavad tagasiteid ja lubatud edasisaatmist lüüsil. Prefiksi lisamine selektorile ilma teeta tagasi varamusse tekitab tunneli, mis luuakse, laseb läbi ühe liiklussuuna ja pillab vastuse vaikselt ära. Selektor on poliitika, mitte marsruutimine.

Hoidke varamud ja teenuse prefiksid aadressiplaani eraldi plokkides. Kui need kattuvad, võib tee, mis peaks jõudma kaitstud hostini, sobida varamu aadressiga ja tunnelis kaduda.

DNS ja vastusetee otsustavad, kas see tundub valmis

Resolveri vastused on sõltumatud transportijast, mida resolverini jõudmiseks kasutatakse. Nimi võib tagastada A-kirje, AAAA-kirje või mõlemad, ja klient valib oma enda eelistusreeglite järgi . Kui sisemine teenus avaldab AAAA-kirje, aga miski seda prefiksit ei marsruudi, proovivad kahekihilise virna võrkudes olevad kliendid kõigepealt IPv6-teed ja jäävad sinna, kuni see ebaõnnestub. Midagi tunneliseadistuses ei paista sel ajal valesti.

Otsustage seega iga nime kohta, millised perekonnad peaksid kasutatavad olema, ja kontrollige seejärel, et vastav prefiks on selektoris ja sellel on tagasitee. See on otsus iga teenuse kohta eraldi. Mõlema kirjetüübi valimatu avaldamine on viis, kuidas toimiv ainult-IPv4 teenus hakkab poolele oma kasutajatest aeguma.

Kontrollige mõlemat perekonda, enne kui nimetate selle valmis

Seadistus, mis laeb, ei ole seadistus, mis töötab. Lugege olekut, mida deemon teatab, kinnitage varamute määramised ja vaadake seejärel marsruute, mille klient tegelikult paigaldas.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Kaks esimest käsku näitavad loodud alam-SA-sid ja seda, millistes varamutes on veel aadresse saadaval, nii et plaan, mis töötab esimese kliendi puhul ja ebaõnnestub kümnenda puhul, muutub nähtavaks. Kaks viimast näitavad, kas klient sai varamust globaalse IPv6-aadressi ja kuhu liiklus kaitstud prefiksi suunas tegelikult läheks. Võrrelge määratud aadressi varamuga, mille seadistasite, mitte aadressiga, mida lootsite. Kui vastaja valis oma poliitika kohaselt teise väärtuse, peavad marsruudid ja tulemüürireeglid ikkagi tema valikuga sobima.

Seejärel testige igas perekonnas ühte kaitstud hosti ja nime, mis lahendub mõlemasse. Ühe perekonna test ei ütle teile midagi selle plaani poole kohta, mida te ei harjutanud, ja just seal asub tavaliselt puuduv marsruut.

Seotud artiklid