Dual-stack VPN-puljer: adressér begge familier i strongSwan

En gateway kan give en rejsende bruger både en IPv4- og en IPv6-virtualadresse, mens den ydre tunnel stadig kører over IPv4. Det er uafhængige beslutninger, og netop det at behandle dem som én er, hvor dual-stack-planer som regel falder fra hinanden. Klientens indre familier, de beskyttede præfikser, den kan nå, og den transport, der bærer indkapslingen, er tre separate valg.

Det meste forvirring kommer af, at ordet dual stack bruges om et design, der kun er dual stack ét sted. En tjeneste kan være dual stack indvendigt, single stack på sin ydre adresse og stadig fungere helt fint for klienter. Det, den ikke kan, er at fungere ved et tilfælde.

To familier indenfor, én vej udenfor

Den ydre forbindelse er IKE over UDP, og den skal bruge én tilgængelig adressefamilie fra det sted, hvor klienten nu befinder sig. En indre IPv6-adresse kræver ikke en udbyder med IPv6, fordi den indre pakke er nyttelast inde i den ydre. Mange fungerende udrulninger bærer IPv6-præfikser gennem en uplink, der kun har IPv4.

Det, den ydre vej begrænser, er tilgængelighed og NAT-gennemgang. Hvis gatewayen kun annoncerer en IPv4-adresse, kan en klient på et netværk med kun IPv6 slet ikke forbinde, uanset hvilke puljer du har konfigureret. Vælg den ydre familie ud fra din klientpopulation, ikke ud fra den indre adresseplan.

Giv klienten en adresse i hver familie

At anmode om begge familier er én linje på klientsiden, forudsat at gatewayen har noget at dele ud. Navngivne puljer holder kilderne adskilt fra servicenetværkene, og det er den egenskab, der gør firewallregler læsbare 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 }
    }
  }
}

Værdien vips beder om en adresse fra hver familie, og puljelisten afgør, hvor de adresser kommer fra. Dokumentationen for strongSwan om virtuel IP dækker flere anmodninger og puljetildeling, herunder det forhold, at en klient, der beder om en bestemt adresse, kun udtrykker en præference, som respondereren kan tilsidesætte. Byg ikke en adgangsregel, der antager, at klienten altid får den samme værdi.

Generér dit eget unikke lokale præfiks i stedet for at kopiere eksemplet. To organisationer, der begge fd42::/16 implementerer det, vil opdage kollisionen første gang, de forbinder til hinanden, og det er ikke behageligt at diagnosticere.

Selektorer beskriver destinationer, ikke kilder

Den underordnede SA’s lokale trafikselektorer angiver, hvilke beskyttede netværk der ligger bag gatewayen, og de fjernselektorer beskriver, hvad klienten må bruge som kilde. En virtuel puljeadresse hører til kildesiden af den politik; at sætte den i destinationslisten er en almindelig fejllæsning af konfigurationen.

Begge familier kræver returruter og tilladt videresendelse på gatewayen. At føje et præfiks til en selektor uden en rute tilbage til puljen giver en tunnel, der etableres, passerer én trafikretning og stiltiende dropper svaret. Selektoren er politik, ikke routing.

Hold puljerne og servicepræfikserne i separate blokke af din adresseplan. Når de overlapper, kan en rute, der skulle nå en beskyttet vært, matche en puljeadresse og forsvinde ind i tunnelen.

DNS og returvejen afgør, om det føles færdigt

Resolver-svar er uafhængige af den transport, der bruges til at nå resolveren. Et navn kan returnere en A-post, en AAAA-post eller begge, og klienten vælger efter sine egne præferenceregler . Hvis en intern tjeneste udgiver en AAAA-post, men intet router det præfiks, vil klienter på dual-stack-netværk prøve IPv6-vejen først og blive siddende, indtil den fejler. Intet i tunnelkonfigurationen ser forkert ud, mens det sker.

Så beslut pr. navn, hvilke familier der skal kunne bruges, og kontrollér derefter, at det tilsvarende præfiks er i selektoren og har en returrute. Det er en beslutning for hver tjeneste. At udgive begge posttyper i flæng er måden, hvorpå en fungerende tjeneste med kun IPv4 begynder at time ud for halvdelen af sine brugere.

Kontrollér begge familier, før du kalder det færdigt

Konfiguration, der indlæses, er ikke konfiguration, der virker. Læs den tilstand, daemonen rapporterer, bekræft puljetildelingerne, og se derefter på de ruter, klienten faktisk har installeret.

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

De to første kommandoer viser de etablerede underordnede SA’er og hvilke puljer der stadig har ledige adresser, så en plan, der virker for den første klient og fejler for den tiende, bliver synlig. De to sidste viser, om klienten har fået en global IPv6-adresse fra puljen, og hvor trafik til et beskyttet præfiks faktisk ville gå hen. Sammenlign den tildelte adresse med den pulje, du konfigurerede, ikke med den adresse, du håbede på. Hvis respondereren har valgt en anden værdi under sin politik, skal ruterne og firewallreglerne stadig passe med det, den valgte.

Test derefter én beskyttet vært pr. familie, og test et navn, der opløses til begge. En enkeltfamilie-test fortæller dig intet om den halvdel af planen, du ikke har afprøvet, og det er som regel der, den manglende rute bor.