Dvigubo kamino VPN telkiniai: abiejų adresų šeimų aptarnavimas strongSwan

Vidiniai IPv4 ir IPv6 telkiniai, apsaugoti prefiksai ir išorinio tunelio šeima yra trys atskiri sprendimai. Suplanuokite kiekvieną, prieš vadindami tai dvigubu kaminu.

Mazgas gali suteikti keliaujančiam naudotojui ir IPv4, ir IPv6 virtualųjį adresą, o išorinis tunelis vis dar eina per IPv4. Tai nepriklausomi sprendimai, ir būtent jų traktavimas kaip vieno yra vieta, kurioje dvigubo kamino planai paprastai subyra. Kliento vidinės šeimos, apsaugoti prefiksai, kuriuos jis gali pasiekti, ir transportas, kuris neša inkapsuliaciją, yra trys atskiri pasirinkimai.

Daugiausia painiavos kyla dėl to, kad žodis dvigubas kaminas taikomas projektui, kuris dvigubas kaminas yra tik vienoje vietoje. Paslauga gali būti dvigubo kamino viduje, viengubo kamino savo išoriniame adrese ir vis tiek puikiai veikti klientams. Ko ji negali, tai veikti atsitiktinai.

Dvi šeimos viduje, vienas kelias lauke

Išorinis ryšys yra IKE per UDP, ir jam reikia vienos pasiekiamos adresų šeimos iš ten, kur klientas yra. Vidinis IPv6 adresas nereikalauja IPv6 palaikančio tiekėjo, nes vidinis paketas yra naudinga apkrova išorinio paketo viduje. Daug veikiančių diegimų perduoda IPv6 prefiksus per tik IPv4 turinčią jungtį.

Tai, ką išorinis kelias iš tikrųjų riboja, yra pasiekiamumas ir NAT perėjimas. Jei mazgas skelbia tik IPv4 adresą, klientas tik IPv6 tinkle negali prisijungti apskritai, kad ir kokius telkinius sukonfigūravote. Išorinę šeimą rinkitės pagal savo klientų populiaciją, o ne pagal vidinį adresų planą.

Duokite klientui adresą kiekvienoje šeimoje

Abiejų šeimų prašymas kliento pusėje yra viena eilutė, su sąlyga, kad mazgas turi ką paskirstyti. Pavadinti telkiniai laiko šaltinius atskirai nuo paslaugų tinklų, ir būtent ši savybė daro ugniasienės taisykles įskaitomas po šešių mėnesių.

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 }
    }
  }
}

Reikšmė vips prašo po vieną adresą iš kiekvienos šeimos, o telkinių sąrašas nusprendžia, iš kur tie adresai ateina. Dokumentacija „strongSwan“ apie virtualiuosius IP apima kelis prašymus ir telkinių priskyrimą, įskaitant tai, kad konkretaus adreso prašantis klientas išreiškia tik pirmenybę, kurią atsakydysis gali panaikinti. Nekurkite prieigos taisyklės, kuri numato, kad klientas visada gauna tą pačią reikšmę.

Sugeneruokite savo unikalų vietinį prefiksą, o ne kopijuokite pavyzdį. Dvi organizacijos, kurios abi fd42::/16 jį įdiegs, aptiks susidūrimą pirmą kartą susijungdamos, o tai diagnozuoti nėra malonu.

Selektoriai aprašo paskirties vietas, o ne šaltinius

Vaikinės SA vietiniai srauto selektoriai nurodo, kurie apsaugoti tinklai yra už mazgo, o nuotoliniai selektoriai aprašo, ką klientas gali naudoti kaip šaltinį. Virtualaus telkinio adresas priklauso šios politikos šaltinio pusei; dėti jį į paskirties sąrašą yra dažnas neteisingas konfigūracijos skaitymas.

Abiem šeimoms reikia grįžtamųjų maršrutų ir leidžiamo persiuntimo mazge. Prefikso pridėjimas prie selektoriaus be maršruto atgal į telkinį sukuria tunelį, kuris susikuria, praleidžia vieną srauto kryptį ir tyliai numeta atsakymą. Selektorius yra politika, o ne maršrutizavimas.

Laikykite telkinius ir paslaugų prefiksus atskiruose savo adresų plano blokuose. Kai jie persidengia, maršrutas, kuris turėtų pasiekti apsaugotą mazgą, gali sutapti su telkinio adresu ir dingti tunelyje.

DNS ir atsakymo kelias nusprendžia, ar tai atrodo baigta

Sprendėjo atsakymai nepriklauso nuo transporto, naudojamo jam pasiekti. Vardas gali grąžinti A įrašą, AAAA įrašą arba abu, o klientas renkasi pagal savo pirmenybės taisykles. Jei vidinė paslauga skelbia AAAA įrašą, bet niekas nemaršrutizuoja to prefikso, klientai dvigubo kamino tinkluose pirmiausia bandys IPv6 kelią ir ten liks, kol jis nepavyks. Tuo metu tunelio konfigūracijoje niekas neatrodo neteisingai.

Taigi nuspręskite pagal kiekvieną vardą, kurios šeimos turėtų būti naudojamos, tada patikrinkite, ar atitinkamas prefiksas yra selektoriuje ir turi grįžtamąjį maršrutą. Tai sprendimas kiekvienai paslaugai atskirai. Abiejų tipų įrašų skelbimas be skirtumo yra būdas, kuriuo veikianti tik IPv4 paslauga pradeda baigti laiką pusei savo naudotojų.

Patikrinkite abi šeimas, prieš tai pavadindami baigta

Konfigūracija, kuri įkeliama, nėra konfigūracija, kuri veikia. Perskaitykite būseną, kurią praneša demonas, patvirtinkite telkinių priskyrimus, tada pažiūrėkite maršrutus, kuriuos klientas iš tikrųjų įdiegė.

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

Pirmosios dvi komandos rodo nustatytas vaikines SA ir tai, kuriuose telkiniuose dar yra laisvų adresų, tad planas, kuris veikia pirmam klientui ir nepavyksta dešimtam, tampa matomas. Paskutinės dvi rodo, ar klientas gavo globalų IPv6 adresą iš telkinio ir kur iš tikrųjų eitų srautas į apsaugotą prefiksą. Palyginkite priskirtą adresą su telkiniu, kurį sukonfigūravote, o ne su adresu, kurio tikėjotės. Jei atsakydysis pagal savo politiką pasirinko kitą reikšmę, maršrutai ir ugniasienės taisyklės vis tiek turi atitikti jo pasirinkimą.

Tada išbandykite po vieną apsaugotą mazgą kiekvienai šeimai ir vardą, kuris sprendžiamas į abi. Vienos šeimos testas nieko nepasako apie tą plano pusę, kurios nepratote, ir būtent ten paprastai glūdi trūkstamas maršrutas.

Susiję straipsniai