Dual-stack VPN-pooler: adressera båda familjerna i strongSwan

Interna IPv4- och IPv6-pooler, skyddade prefix och den yttre tunnelfamiljen är tre separata beslut. Planera var och en innan du kallar det dual stack.

En gateway kan ge en resande användare både en virtuell IPv4- och en IPv6-adress medan den yttre tunneln fortfarande går över IPv4. Det är oberoende beslut, och att behandla dem som ett är precis där dual-stack-planer vanligtvis faller samman. Klientens inre familjer, de skyddade prefix den kan nå och transporten som bär inkapslingen är tre separata val.

Det mesta av förvirringen kommer av att ordet dual stack används om en design som bara är dual stack på ett ställe. En tjänst kan vara dual stack invändigt, single stack på sin yttre adress, och ändå fungera alldeles utmärkt för klienter. Det den inte kan är att fungera av misstag.

Två familjer inuti, en väg utanför

Den yttre anslutningen är IKE över UDP, och den behöver en nåbar adressfamilj från var klienten än befinner sig. En inre IPv6-adress kräver ingen leverantör med IPv6, eftersom det inre paketet är nyttolast inuti det yttre. Många fungerande installationer bär IPv6-prefix genom en upplänk som bara har IPv4.

Det den yttre vägen faktiskt begränsar är nåbarhet och NAT-passage. Om gatewayen annonserar bara en IPv4-adress kan en klient på ett nätverk med bara IPv6 inte ansluta alls, oavsett vilka pooler du har konfigurerat. Välj den yttre familjen utifrån din klientpopulation, inte utifrån den inre adressplanen.

Ge klienten en adress i varje familj

Att begära båda familjerna är en rad på klientsidan, förutsatt att gatewayen har något att dela ut. Namngivna pooler håller källorna åtskilda från tjänstenäten, och det är den egenskapen som gör brandväggsregler läsbara sex månader senare.

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ärdet vips begär en adress från varje familj, och poollistan avgör var dessa adresser kommer ifrån. Dokumentationen för strongSwan om virtuella IP-adresser täcker flera begäranden och poolfördelning, inklusive poängen att en klient som begär en specifik adress bara uttrycker en preferens som svararen får åsidosätta. Bygg inte en åtkomstregel som förutsätter att klienten alltid får samma värde.

Generera ett eget unikt lokalt prefix i stället för att kopiera exemplet. Två organisationer som båda fd42::/16 inför det upptäcker kollisionen första gången de sammankopplas, och det är inte trevligt att diagnosticera.

Selektorer beskriver destinationer, inte källor

Den underordnade SA:ns lokala trafikselektorer anger vilka skyddade nätverk som ligger bakom gatewayen, och fjärrselektorerna beskriver vad klienten får använda som källa. En virtuell pooladress hör till källsidan av den policyn; att sätta den i destinationslistan är en vanlig felläsning av konfigurationen.

Båda familjerna behöver returvägar och tillåten vidarebefordran på gatewayen. Att lägga till ett prefix i en selektor utan en väg tillbaka till poolen ger en tunnel som etableras, släpper igenom en trafikriktning och tyst tappar svaret. Selektorn är policy, inte routing.

Håll poolerna och tjänsteprefixen i separata block av din adressplan. När de överlappar kan en väg som borde nå en skyddad värd matcha en pooladress och försvinna in i tunneln.

DNS och svarsvägen avgör om det känns färdigt

Resolver-svar är oberoende av transporten som används för att nå resolvern. Ett namn kan returnera en A-post, en AAAA-post eller båda, och klienten väljer enligt sina egna preferensregler. Om en intern tjänst publicerar en AAAA-post men inget routar det prefixet kommer klienter på dual-stack-nät att försöka IPv6-vägen först och sitta där tills den misslyckas. Inget i tunnelkonfigurationen ser fel ut medan det pågår.

Bestäm därför per namn vilka familjer som ska vara användbara, och kontrollera sedan att motsvarande prefix finns i selektorn och har en returväg. Det är ett beslut per tjänst. Att publicera båda posttyperna urskillningslöst är hur en fungerande tjänst med bara IPv4 börjar få tidsgräns för hälften av sina användare.

Verifiera båda familjerna innan du kallar det klart

Konfiguration som laddas är inte konfiguration som fungerar. Läs tillståndet som daemonen rapporterar, bekräfta poolfördelningarna och titta sedan på de vägar klienten faktiskt installerade.

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

De två första kommandona visar de etablerade underordnade SA:erna och vilka pooler som fortfarande har lediga adresser, så en plan som fungerar för den första klienten och misslyckas för den tionde blir synlig. De två sista visar om klienten fick en global IPv6-adress från poolen och vart trafik till ett skyddat prefix faktiskt skulle gå. Jämför den tilldelade adressen med poolen du konfigurerade, inte med adressen du hoppades på. Om svararen valde ett annat värde enligt sin policy måste vägarna och brandväggsreglerna fortfarande stämma med det den valde.

Testa sedan en skyddad värd per familj, och testa ett namn som löses till båda. Ett test med en enda familj säger dig inget om den halva av planen som du inte har övat på, och det är vanligtvis där den saknade vägen bor.

Relaterade artiklar