Dual-stack VPN-poolar: adressere begge familiane i strongSwan

Indre IPv4- og IPv6-poolar, verna prefiks og den ytre tunnelfamilien er tre separate avgjerder. Planlegg kvar av dei før du kallar det dual stack.

Ein gateway kan gje ein reisande brukar både ein IPv4- og ein IPv6-virtuell adresse medan den ytre tunnelen framleis går over IPv4. Dette er uavhengige avgjerder, og å handsame dei som éin er nettopp der dual-stack-planar vanlegvis fell frå kvarandre. Dei indre familiane til klienten, dei verna prefiksa han kan nå, og transporten som ber innkapslinga, er tre separate val.

Det meste av forvirringa kjem av at ordet dual stack vert brukt om eit design som berre er dual stack på éin stad. Ei teneste kan vere dual stack innvendig, single stack på si ytre adresse, og likevel fungere heilt fint for klientar. Det ho ikkje kan, er å fungere ved eit uhell.

To familiar innanfor, éin veg utanfor

Den ytre sambandet er IKE over UDP, og det treng éin tilgjengeleg adressefamilie frå der klienten måtte vere. Ei indre IPv6-adresse krev ikkje ein leverandør med IPv6, fordi den indre pakken er nyttelast inne i den ytre. Mange fungerande utrullingar ber IPv6-prefiks gjennom ei oppkopling som berre har IPv4.

Det den ytre vegen faktisk avgrensar, er tilgjenge og NAT-gjennomgang. Viss gatewayen berre annonserer ei IPv4-adresse, kan ein klient på eit nettverk med berre IPv6 ikkje kopie til i det heile, uansett kva poolar du har konfigurert. Vel den ytre familien ut frå klientmassen din, ikkje ut frå den indre adresseplanen.

Gje klienten ei adresse i kvar familie

Å be om begge familiane er éi linje på klientsida, føresett at gatewayen har noko å dele ut. Namngjevne poolar held kjeldene skilde frå tenestenettverka, og det er denne eigenskapen som gjer brannmurreglar lesbare seks månader seinare.

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

Verdien vips ber om ei adresse frå kvar familie, og poollista avgjer kvar desse adressene kjem frå. Dokumentasjonen for strongSwan om virtuelle IP-adresser dekkjer fleire førespurnader og pooletildeling, inkludert poenget at ein klient som ber om ei bestemt adresse, berre uttrykkjer ei preferanse som svararen kan overstyre. Ikkje bygg ein tilgangsregel som føreset at klienten alltid får same verdi.

Generer ditt eige unike lokale prefiks i staden for å kopiere dømet. To organisasjonar som begge fd42::/16 tek det i bruk, vil oppdage kollisjonen første gong dei koplar seg saman, og det er ikkje behageleg å diagnostisere.

Selektorar skildrar destinasjonar, ikkje kjelder

Dei lokale trafikkselektorane til den underordna SA-en seier kva verna nettverk som ligg bak gatewayen, og fjernselektorane skildrar kva klienten kan bruke som kjelde. Ei virtuell pooladresse høyrer til kjeldesida av denne policyen; å setje ho i destinasjonslista er ei vanleg feillesing av konfigurasjonen.

Begge familiane treng returruter og tillaten vidaresending på gatewayen. Å leggje eit prefiks til ein selektor utan ei rute tilbake til poolen gjev ein tunnel som vert etablert, slepp éi trafikkretning gjennom og slepp svaret stille. Selektoren er policy, ikkje ruting.

Hald poolane og tenesteprefiksa i separate blokker av adresseplanen din. Når dei overlappar, kan ei rute som skal nå ein verna vert treffe ei pooladresse og forsvinne inn i tunnelen.

DNS og returvegen avgjer om det kjennest ferdig

Svar frå resolvarar er uavhengige av transporten som vert brukt for å nå resolvaren. Eit namn kan returnere ein A-post, ein AAAA-post eller begge, og klienten vel etter sine eigne preferansereglar. Viss ei intern teneste publiserer ein AAAA-post, men ingenting rutar det prefikset, vil klientar på dual-stack-nettverk prøve IPv6-vegen først og bli sitjande til han feilar. Ingenting i tunnelkonfigurasjonen ser feil ut medan det skjer.

Så avgjer per namn kva familiar som skal vere brukbare, og kontroller deretter at det tilsvarande prefikset er i selektoren og har ein returveg. Det er ei avgjerd per teneste. Å publisere begge posttypane utan skilnad er måten ei fungerande teneste med berre IPv4 byrjar å få tidsavbrot for halvparten av brukarane sine på.

Verifiser begge familiane før du kallar det ferdig

Konfigurasjon som lastar, er ikkje konfigurasjon som verkar. Les tilstanden daemonen rapporterer, stadfest pooletildelingane, og sjå deretter på rutene klienten faktisk installerte.

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

Dei to første kommandoane viser dei etablerte underordna SA-ane og kva poolar som framleis har ledige adresser, slik at ein plan som verkar for den første klienten og feilar for den tiande, vert synleg. Dei to siste viser om klienten fekk ei global IPv6-adresse frå poolen, og kvar trafikk mot eit verna prefiks faktisk ville gå. Samanlikn den tildelte adressa med poolen du konfigurerte, ikkje med adressa du håpa på. Viss svararen valde ein annan verdi under sin policy, må rutene og brannmurreglane framleis stemme med det han valde.

Test deretter éin verna vert per familie, og test eit namn som løysest til begge. Ein test med éin familie seier deg ingenting om halvparten av planen du ikkje har øvd på, og det er vanlegvis der den manglande ruta bur.

Relaterte artiklar