Planera privat IKEv2-åtkomst med dubbla stackar och strongSwan

En tunnel med dubbla stackar är inte ett beslut utan tre, och de kan besvaras olika. Vilken familj den yttre tunneln går över, vilka familjer klienten tar emot inuti och vilka familjer de skyddade tjänsterna faktiskt svarar på. En design som behandlar dem som ett enda val bär antingen IPv6 som aldrig behövdes eller delar ut adresser som ingenting kan routa tillbaka. Separera de tre och resten av konfigurationen blir nästan mekanisk.

Tre typer av adresser, beslutade var för sig

Den yttre adressen är hur de två gatewaysen når varandra, och den kan vara IPv4 medan den inre trafiken bär båda familjerna. Den inre virtuella adressen är klientens identitet inne i tunneln, och varje familj behöver sin egen pool. De skyddade prefixen är det klienten får nå, och de tillhör tjänsterna och inte tunneln. Att blanda ihop det tredje med det andra orsakar de flesta planeringsfel, eftersom båda ser ut som privata intervall.

Yttre transport med bara IPv4 och inre trafik med dubbla stackar är en normal och väl stödd ordning.

Besluta var och en uttryckligen och skriv ned besluten. Om den yttre vägen bara är IPv4, säg det och sluta oroa dig för nåbarheten hos IPv6-slutpunkter. Om en familj tilldelas inuti men ingenting svarar på den, ta antingen bort den från planen eller gör dessa tjänster verkligt dubbelstackade.

Tilldela en virtuell adress i varje familj

I en swanctl-konfiguration begär klienten virtuella adresser, och ett jokertecken i varje familj ber svararen tilldela en av varje. Svararen hämtar dem från pooler, och pooler är separata objekt från nätverken bakom gatewayen. Håll dem åtskilda i planen också, eftersom en pool som överlappar ett tjänsteprefix ger routing som ser korrekt ut ända till det ögonblick trafiken landar på en oönskad plats.

Be om båda familjerna när du behöver båda, och om en när du inte behöver, eftersom en oanvänd adress är politikyta utan nytta. En specifik begäran är en begäran och inte en reservation, och svararen kan returnera ett annat värde enligt sin egen policy. Den detaljen spelar roll överallt där en adress är hårdkodad i en brandväggsregel eller en övervakningskontroll. Hänvisa till pooler vid namn i anslutningen och håll tjänstenätverk utanför dem.

vips = 0.0.0.0, ::

Generera ditt eget unika lokala prefix för IPv6-poolen i stället för att ta över ett kort exempelvärde. Exemplet visar inställningens form, inte ett standardvärde att ärva.

Beskriv mål åtskilt från pooler

Trafikväljare beskriver vad varje sida förväntar sig att utbyta, så gatewayens lokala väljare ska namnge skyddade tjänsteprefix och inte klientpooler. Klientens fjärrväljare speglar den avsikten. När de två listorna beskriver olika objekt kan tunneln komma upp och ändå inte bära något användbart.

Samma prefix behöver returvägar och tillåten vidarebefordran inne i gatewayens nätverk, för varje familj du aktiverar.

Det är här en privat IPv6-plan slutar att räcka. Unik lokal adressering köper privat nåbarhet och skapar inte offentlig IPv6-utgång, så en design som antar att den onumrerade familjen bara följer IPv4-maskeringsreglerna kommer att göra sina användare besvikna. Om offentlig IPv6-åtkomst är en del av kravet behöver den en routad plan och en uppström som håller med. Annars säg klart att IPv6-sidan bara är privat, vilket är en ärlig gräns och inte en begränsning att dölja.

Gör DNS och returvägar avsiktliga

Namnuppslagning följer inte transporten. En resolver kan returnera A- och AAAA-poster över en tunnel med bara IPv4, och klienten kommer då att prova en familj du aldrig planerade. Bestäm vilka tjänstenamn som ska bära användbara svar med dubbla stackar och gör båda dessa vägar avsiktliga. Ett namn som löses till en familj utan fungerande väg ger ett stopp i stället för ett rent fel, och stopp är mycket svårare att diagnostisera.

Dokumentera den yttre slutpunktens nåbarhet separat, inklusive om någon NAT-traversering är inblandad och vilken familj den använder.

Skriv sedan planen på sex rader: yttre slutpunkt, IPv4-pool, IPv6-pool, IPv4-tjänsteprefix, IPv6-tjänsteprefix och routern som äger svaren för varje. En plan i den formen besvarar frågorna en operatör faktiskt ställer klockan tre på natten. Allt kortare lämnar dubbla stackar som en andra adress fastskruvad på en policy med bara IPv4, och det är så det vanligtvis slutar att fungera halvt.