Dual-stack VPN pooly: adresovanie oboch rodín v strongSwan

Vnútorné pooly IPv4 a IPv6, chránené prefixy a rodina vonkajšieho tunela sú tri samostatné rozhodnutia. Naplánujte každé z nich, kým to nazvete dual-stack.

Brána môže dať cestujúcemu používateľovi virtuálnu adresu IPv4 aj IPv6, pričom vonkajší tunel stále putuje cez IPv4. Sú to nezávislé rozhodnutia a práve ich spájanie do jedného je miesto, kde sa dual-stack plány zvyčajne rozpadajú. Vnútorné rodiny klienta, chránené prefixy, na ktoré sa môže dostať, a transport, ktorý nesie zapuzdrenie, sú tri samostatné voľby.

Väčšina zmätku pochádza z toho, že slovo dual-stack sa použije na návrh, ktorý je dual-stack len na jednom mieste. Služba môže byť dual-stack vnútri, single-stack na svojej vonkajšej adrese, a napriek tomu klientom fungovať úplne dobre. Čo nedokáže, je fungovať náhodou.

Dve rodiny vnútri, jedna cesta von

Vonkajšie spojenie je IKE cez UDP a potrebuje jednu dostupnú rodinu adries odtiaľ, kde sa klient nachádza. Vnútorná adresa IPv6 nevyžaduje poskytovateľa s podporou IPv6, pretože vnútorný paket je užitočné zaťaženie vo vnútri vonkajšieho. Mnohé funkčné nasadenia prenášajú prefixy IPv6 cez uplink, ktorý podporuje iba IPv4.

Čo vonkajšia cesta obmedzuje, je dostupnosť a prechod cez NAT. Ak brána inzeruje iba adresu IPv4, klient v sieti iba s IPv6 sa nemôže pripojiť vôbec, bez ohľadu na to, aké pooly nakonfigurujete. Rodinu vonkajšej cesty vyberte podľa svojej klientskej populácie, nie podľa vnútorného plánu adries.

Dajte klientovi adresu v každej rodine

Žiadosť o obe rodiny je jeden riadok na strane klienta, ak má brána čo prideľovať. Pomenované pooly držia zdroje oddelene od servisných sietí, a to je vlastnosť, ktorá robí pravidlá firewallu čitateľnými aj po šiestich mesiacoch.

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

Hodnota vips si vyžaduje adresu z každej rodiny a zoznam poolov rozhoduje, odkiaľ tieto adresy pochádzajú. Dokumentácia strongSwan k virtuálnym IP adresám pokrýva viac žiadostí a prideľovanie z poolov, vrátane toho, že klient žiadajúci konkrétnu adresu vyjadruje len preferenciu, ktorú môže responder prepísať. Nestavajte pravidlo prístupu, ktoré predpokladá, že klient vždy dostane rovnakú hodnotu.

Vygenerujte si vlastný jedinečný lokálny prefix namiesto kopírovania príkladu. Dve organizácie, ktoré obe fd42::/16 ho nasadia, objavia kolíziu pri prvom vzájomnom prepojení, a diagnostikovať to nie je príjemné.

Selektory opisujú ciele, nie zdroje

Lokálne selektory prevádzky podriadenej SA hovoria, ktoré chránené siete stoja za bránou, a vzdialené selektory opisujú, čo klient smie použiť ako zdroj. Adresa virtuálneho poolu patrí na zdrojovú stranu tejto politiky; jej zaradenie do zoznamu cieľov je časté nesprávne čítanie konfigurácie.

Obe rodiny potrebujú spätné trasy a povolené preposielanie na bráne. Pridanie prefixu do selektora bez trasy späť do poolu vytvorí tunel, ktorý sa nadviaže, prepustí jeden smer prevádzky a potichu zahodí odpoveď. Selektor je politika, nie smerovanie.

Držte pooly a servisné prefixy v oddelených blokoch svojho adresného plánu. Keď sa prekryjú, trasa, ktorá má dosiahnuť chráneného hostiteľa, môže zodpovedať adrese poolu a zmiznúť v tuneli.

DNS a cesta odpovede rozhodujú, či to vyzerá hotové

Odpovede resolvera sú nezávislé od transportu použitého na jeho dosiahnutie. Názov môže vrátiť záznam A, záznam AAAA alebo oba, a klient vyberá podľa svojich vlastných pravidiel preferencie. Ak interná služba publikuje záznam AAAA, ale ten prefix nikto nesmeruje, klienti v dual-stack sieťach skúsia najprv cestu IPv6 a zostanú tam, kým to zlyhá. V konfigurácii tunela pritom nič nevyzerá zle.

Rozhodnite teda pre každý názov, ktoré rodiny majú byť použiteľné, a potom overte, že príslušný prefix je v selektore a má spätnú trasu. Je to rozhodnutie pre každú službu zvlášť. Plošné publikovanie oboch typov záznamov je spôsob, akým funkčná služba iba s IPv4 začne polovici používateľov vypršať časový limit.

Overte obe rodiny, kým to vyhlásite za hotové

Konfigurácia, ktorá sa načíta, nie je konfigurácia, ktorá funguje. Prečítajte si stav, ktorý hlási démon, potvrďte pridelenie z poolov a potom sa pozrite na trasy, ktoré klient skutočne nainštaloval.

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

Prvé dva príkazy ukazujú nadviazané podriadené SA a ktoré pooly ešte majú voľné adresy, takže plán, ktorý funguje pre prvého klienta a zlyhá pri desiatom, sa stane viditeľným. Posledné dva ukazujú, či klient dostal globálnu adresu IPv6 z poolu a kam by prevádzka k chránenému prefixu v skutočnosti išla. Porovnajte pridelenú adresu s poolom, ktorý ste nakonfigurovali, nie s adresou, na ktorú ste sa spoliehali. Ak responder podľa svojej politiky zvolil inú hodnotu, trasy a pravidlá firewallu musia stále zodpovedať jeho voľbe.

Potom otestujte jedného chráneného hostiteľa pre každú rodinu a názov, ktorý sa prekladá do oboch. Test jednej rodiny vám nepovie nič o polovici plánu, ktorú ste neprecvičili, a práve tam zvyčajne sídli chýbajúca trasa.

Súvisiace články