Dvostruki stack VPN bazeni: adresiranje obiju obitelji u strongSwanu

Pristupnik može putujućem korisniku dati i IPv4 i IPv6 virtualnu adresu, dok vanjski tunel i dalje ide preko IPv4. To su neovisne odluke, i upravo njihovo tretiranje kao jedne je mjesto gdje se planovi dvostrukog stacka obično raspadaju. Unutarnje obitelji 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 stack primjenjuje na dizajn koji je dvostruki stack samo na jednom mjestu. Usluga može biti dvostruki stack iznutra, jednostruki stack na svojoj vanjskoj adresi, i ipak savršeno dobro raditi za klijente. Ono što ne može jest raditi slučajno.

Dvije obitelji unutra, jedna staza vani

Vanjska veza je IKE preko UDP-a i potrebna joj je jedna dostupna obitelj adresa s mjesta na kojem se klijent nalazi. Unutarnja IPv6 adresa ne zahtijeva pružatelja s IPv6 podrškom, jer je unutarnji 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 s IPv6 ne može se uopće povezati, bez obzira koje bazene konfigurirali. Odaberite vanjsku obitelj prema svojoj klijentskoj populaciji, a ne prema unutarnjem planu adresa.

Dajte klijentu adresu u svakoj obitelji

Traženje obiju obitelji izjava je u jednom redu na strani klijenta, pod uvjetom da pristupnik ima što podijeliti. Imenovani bazeni drže izvore odvojeno od uslužnih mreža, i to je svojstvo koje pravila vatrozida čini čitljivima š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 obitelji, a popis bazena odlučuje odakle te adrese dolaze. Dokumentacija strongSwana o virtualnim IP adresama pokriva više zahtjeva i dodjelu bazena, uključujući i to da klijent koji traži određenu adresu izražava samo preferenciju koju odgovarajuća strana može nadjačati. Ne gradite pravilo pristupa koje pretpostavlja da klijent uvijek dobiva 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 diagnosticiranje toga nije ugodno.

Selektori opisuju odredišta, ne izvore

Lokalni selektori prometa podređene SA govore koje zaštićene mreže stoje iza pristupnika, a udaljeni selektori opisuju što klijent može koristiti kao izvor. Adresa virtualnog bazena pripada izvornoj strani te politike; stavljanje u popis odredišta često je pogrešno čitanje konfiguracije.

Obje obitelji trebaju povratne rute i dopušteno prosljeđivanje na pristupniku. Dodavanje prefiksa selektoru bez rute natrag do bazena stvara tunel koji se uspostavlja, propušta jedan smjer prometa i tiho odbacuje odgovor. Selektor je politika, a ne usmjeravanje.

Držite bazene i uslužne 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 izgleda li to dovršeno

Odgovori razrješivača neovisni su o transportu kojim se do njega dolazi. Ime može vratiti A zapis, AAAA zapis ili oboje, a klijent bira prema vlastitim pravilima preferencije. Ako interna usluga objavljuje AAAA zapis ali ništa ne usmjerava taj prefiks, klijenti na mrežama dvostrukog stacka 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 obitelji trebaju biti upotrebljive, pa provjerite da je odgovarajući prefiks u selektoru i da ima povratnu rutu. To je odluka za svaku uslugu pojedinačno. Objavljivanje oba tipa zapisa bez razlike način je na koji radna usluga samo s IPv4 počinje isticati vrijeme polovici svojih korisnika.

Provjerite obje obitelji 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 naredbe pokazuju uspostavljene podređene SA i koji bazeni još imaju dostupne adrese, pa plan koji radi za prvog klijenta a pada za desetog postaje vidljiv. Posljednje dvije pokazuju je li klijent dobio globalnu IPv6 adresu iz bazena i kamo bi promet do zaštićenog prefiksa zaista išao. Usporedite 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 pravila vatrozida i dalje moraju odgovarati njezinu izboru.

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