Dual-stack VPN-pooler: adresser begge familier i strongSwan

Indre IPv4- og IPv6-pooler, beskyttede prefikser og den ytre tunnelfamilien er tre separate beslutninger. Planlegg hver av dem før du kaller det dual stack.

En gateway kan gi en reisende bruker både en IPv4- og en IPv6-virtuell adresse mens den ytre tunnelen fortsatt går over IPv4. Dette er uavhengige beslutninger, og å behandle dem som én er nettopp der dual-stack-planer vanligvis faller fra hverandre. Klientens indre familier, de beskyttede prefiksene den kan nå, og transporten som bærer innkapslingen, er tre separate valg.

Det meste av forvirringen kommer av at ordet dual stack brukes om et design som bare er dual stack på ett sted. En tjeneste kan være dual stack innvendig, single stack på sin ytre adresse, og likevel fungere helt fint for klienter. Det den ikke kan, er å fungere ved et uhell.

To familier innenfor, én vei utenfor

Den ytre forbindelsen er IKE over UDP, og den trenger én tilgjengelig adressefamilie fra der klienten måtte være. En indre IPv6-adresse krever ikke en leverandør med IPv6, fordi den indre pakken er nyttelast inne i den ytre. Mange fungerende utrullinger bærer IPv6-prefikser gjennom en oppkobling som bare har IPv4.

Det den ytre veien faktisk begrenser, er tilgjengelighet og NAT-gjennomgang. Hvis gatewayen bare annonserer en IPv4-adresse, kan en klient på et nettverk med bare IPv6 ikke koble til i det hele tatt, uansett hvilke pooler du har konfigurert. Velg den ytre familien ut fra klientmassen din, ikke ut fra den indre adresseplanen.

Gi klienten en adresse i hver familie

Å be om begge familiene er én linje på klientsiden, forutsatt at gatewayen har noe å dele ut. Navngitte pooler holder kildene adskilt fra tjenestenettverkene, og det er denne egenskapen som gjør brannmurregler lesbare seks måneder senere.

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 en adresse fra hver familie, og poollisten avgjør hvor disse adressene kommer fra. Dokumentasjonen for strongSwan om virtuelle IP-adresser dekker flere forespørsler og pooletildeling, inkludert poenget at en klient som ber om en bestemt adresse, bare uttrykker en preferanse som svareren kan overstyre. Ikke bygg en tilgangsregel som forutsetter at klienten alltid får samme verdi.

Generer ditt eget unike lokale prefiks i stedet for å kopiere eksempelet. To organisasjoner som begge fd42::/16 tar det i bruk, vil oppdage kollisjonen første gang de kobler seg sammen, og det er ikke behagelig å diagnostisere.

Selektorer beskriver destinasjoner, ikke kilder

Den underordnede SA-ens lokale trafikkselektorer sier hvilke beskyttede nettverk som ligger bak gatewayen, og fjernselektorene beskriver hva klienten kan bruke som kilde. En virtuell pooladresse hører til kildesiden av denne policyen; å sette den i destinasjonslisten er en vanlig feillesing av konfigurasjonen.

Begge familiene trenger returruter og tillatt videresending på gatewayen. Å legge et prefiks til en selektor uten en rute tilbake til poolen gir en tunnel som etableres, slipper én trafikkretning gjennom og slipper svaret stille. Selektoren er policy, ikke ruting.

Hold poolene og tjenesteprefiksene i separate blokker av adresseplanen din. Når de overlapper, kan en rute som skal nå en beskyttet vert treffe en pooladresse og forsvinne inn i tunnelen.

DNS og returveien avgjør om det føles ferdig

Svar fra resolvere er uavhengige av transporten som brukes for å nå resolvere. Et navn kan returnere en A-post, en AAAA-post eller begge, og klienten velger etter sine egne preferanseregler. Hvis en intern tjeneste publiserer en AAAA-post, men ingenting ruter det prefikset, vil klienter på dual-stack-nettverk prøve IPv6-veien først og bli sittende til den feiler. Ingenting i tunnelkonfigurasjonen ser feil ut mens det skjer.

Så avgjør per navn hvilke familier som skal være brukbare, og kontroller deretter at det tilsvarende prefikset er i selektoren og har en returrute. Det er en beslutning per tjeneste. Å publisere begge posttypene uten forskjell er måten en fungerende tjeneste med bare IPv4 begynner å få tidsavbrudd for halvparten av brukerne sine på.

Verifiser begge familiene før du kaller det ferdig

Konfigurasjon som lastes, er ikke konfigurasjon som virker. Les tilstanden daemonen rapporterer, bekreft pooletildelingene, og se 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

De to første kommandoene viser de etablerte underordnede SA-ene og hvilke pooler som fortsatt har ledige adresser, slik at en plan som virker for den første klienten og feiler for den tiende, blir synlig. De to siste viser om klienten fikk en global IPv6-adresse fra poolen, og hvor trafikk mot et beskyttet prefiks faktisk ville gå. Sammenlign den tildelte adressen med poolen du konfigurerte, ikke med adressen du håpet på. Hvis svareren valgte en annen verdi under sin policy, må rutene og brannmurreglene fortsatt stemme med det den valgte.

Test deretter én beskyttet vert per familie, og test et navn som løses til begge. En test med én familie sier deg ingenting om halvparten av planen du ikke har øvd på, og det er vanligvis der den manglende ruten bor.

Relaterte artikler