Dvostruki stek VPN bazeni: adresiranje oba familija u strongSwan-u

Pristupnik može putujućem korisniku dati i IPv4 i IPv6 virtuelnu adresu, dok vanjski tunel i dalje ide preko IPv4. To su nezavisne odluke, i upravo tretiranje njih kao jedne je mjesto gdje se planovi dvostrukog steka obično raspadaju. Unutrašnje familije klijenta, zaštićeni prefiksi do kojih može doći i transport koji nosi enkapsulaciju tri su odvojena izbora.

Većina zabune dolazi od toga što se riječ dvostruki stek primjenjuje na dizajn koji je dvostruki stek samo na jednom mjestu. Servis može biti dvostruki stek iznutra, jednostruki stek na svojoj vanjskoj adresi, i ipak savršeno dobro raditi za klijente. Ono što ne može jest raditi slučajno.

Dvije familije unutra, jedna staza vani

Vanjska veza je IKE preko UDP-a i potrebna joj je jedna dostupna familija adresa s mjesta na kojem se klijent nalazi. Unutrašnja IPv6 adresa ne zahtijeva provajdera sa IPv6 podrškom, jer je unutrašnji paket korisni teret unutar vanjskog. Mnoga radna postavljanja prenose IPv6 prefikse kroz uzlazni kanal koji podržava samo IPv4.

Ono što vanjska staza zaista ograničava jest dostupnost i prolaz kroz NAT. Ako pristupnik oglašava samo IPv4 adresu, klijent na mreži samo sa IPv6 ne može se uopće povezati, bez obzira koje bazene konfigurirali. Odaberite vanjsku familiju prema svojoj klijentskoj populaciji, a ne prema unutrašnjem planu adresa.

Dajte klijentu adresu u svakoj familiji

Traženje obje familije je izjava u jednom redu na strani klijenta, pod uslovom da pristupnik ima šta podijeliti. Imenovani bazeni drže izvore odvojeno od servisnih mreža, i to je svojstvo koje pravila firewall-a čini čitljivim šest mjeseci kasnije.

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

Vrijednost vips traži adresu iz svake familije, a lista bazena odlučuje odakle te adrese dolaze. Dokumentacija strongSwan-a o virtuelnim IP adresama pokriva više zahtjeva i dodjelu bazena, uključujući i to da je klijent koji traži određenu adresu samo preferencija koju odgovarajuća strana može nadjačati. Ne gradite pravilo pristupa koje pretpostavlja da klijent uvijek dobija istu vrijednost.

Generirajte vlastiti jedinstveni lokalni prefiks umjesto da kopirate primjer. Dvije organizacije koje obje fd42::/16 uvedu, otkrit će koliziju pri prvom međusobnom povezivanju, a dijagnosticiranje toga nije ugodno.

Selektori opisuju odredišta, ne izvore

Lokalni selektori saobraćaja dječije SA govore koje zaštićene mreže stoje iza pristupnika, a udaljeni selektori opisuju šta klijent može koristiti kao izvor. Adresa virtuelnog bazena pripada izvornoj strani te politike; stavljanje u listu odredišta često je pogrešno čitanje konfiguracije.

Obje familije trebaju povratne rute i dozvoljeno prosljeđivanje na pristupniku. Dodavanje prefiksa selektoru bez rute natrag do bazena stvara tunel koji se uspostavlja, propušta jedan smjer saobraćaja i tiho odbacuje odgovor. Selektor je politika, a ne rutiranje.

Držite bazene i servisne prefikse u odvojenim blokovima svog plana adresa. Kada se preklope, ruta koja treba doći do zaštićenog hosta može se poklopiti s adresom bazena i nestati u tunelu.

DNS i povratna staza odlučuju da li to izgleda dovršeno

Odgovori rezolvera nezavisni su od transporta kojim se do rezolvera dolazi. Ime može vratiti A zapis, AAAA zapis ili oboje, a klijent bira prema vlastitim pravilima preferencije . Ako interni servis objavljuje AAAA zapis ali ništa ne rutira taj prefiks, klijenti na mrežama dvostrukog steka prvo će pokušati IPv6 stazu i sjediti tamo dok ne propadne. Ništa u konfiguraciji tunela ne izgleda pogrešno dok se to događa.

Zato odredite po imenu koje familije trebaju biti upotrebljive, pa provjerite da je odgovarajući prefiks u selektoru i da ima povratnu rutu. To je odluka za svaki servis pojedinačno. Objavljivanje oba tipa zapisa bez razlike je način na koji radni servis samo sa IPv4 počinje da istekom vremena odgovara polovini svojih korisnika.

Provjerite obje familije prije nego što to proglasite gotovim

Konfiguracija koja se učita nije konfiguracija koja radi. Pročitajte stanje koje demon prijavljuje, potvrdite dodjele bazena, a zatim pogledajte rute koje je klijent zaista instalirao.

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

Prve dvije komande pokazuju uspostavljene dječije SA i koji bazeni još imaju dostupne adrese, pa plan koji radi za prvog klijenta a pada za desetog postaje vidljiv. Posljednje dvije pokazuju da li je klijent dobio globalnu IPv6 adresu iz bazena i kuda bi saobraćaj do zaštićenog prefiksa zaista išao. Uporedite dodijeljenu adresu s bazenom koji ste konfigurirali, a ne s adresom kojoj ste se nadali. Ako je odgovarajuća strana pod svojom politikom odabrala drugu vrijednost, rute i firewall pravila i dalje moraju odgovarati njenom izboru.

Zatim testirajte po jedan zaštićeni host za svaku familiju i ime koje se razrješava u obje. Test jedne familije ne govori vam ništa o polovini plana koju niste isprobali, a ta polovina je obično mjesto gdje nedostaje ruta.