Planlegging av privat IKEv2-tilgang med dobbel stakk og strongSwan

En tunnel med dobbel stakk er ikke én beslutning, men tre, og de kan besvares ulikt. Hvilken familie den ytre tunnelen går over, hvilke familier klienten mottar inni, og hvilke familier de beskyttede tjenestene faktisk svarer på. Et design som behandler dem som ett valg, bærer enten IPv6 som aldri var nødvendig, eller deler ut adresser som ingenting kan rute tilbake. Skill de tre, og resten av konfigurasjonen blir nesten mekanisk.

Tre typer adresser, avgjort hver for seg

Den ytre adressen er hvordan de to gatewayene når hverandre, og den kan være IPv4 mens den indre trafikken bærer begge familier. Den indre virtuelle adressen er klientens identitet inne i tunnelen, og hver familie trenger sitt eget basseng. De beskyttede prefiksene er det klienten kan nå, og de tilhører tjenestene og ikke tunnelen. Å forveksle det tredje med det andre forårsaker de fleste planleggingsfeil, fordi begge ser ut som private områder.

Ytre transport med bare IPv4 og indre trafikk med dobbel stakk er en normal og godt støttet ordning.

Avgjør hver enkelt eksplisitt og skriv ned beslutningene. Hvis den ytre veien bare er IPv4, si det og slutt å bekymre deg for nåbarheten til IPv6-endepunkter. Hvis en familie tildeles inni, men ingenting svarer på den, fjerner du den fra planen eller gjør disse tjenestene reelt dobbel-stakket.

Tildel en virtuell adresse i hver familie

I en swanctl-konfigurasjon ber klienten om virtuelle adresser, og et jokertegn i hver familie ber svareren tildele én av hver. Svareren henter dem fra bassenger, og bassenger er separate objekter fra nettverkene bak gatewayen. Hold dem atskilt i planen også, fordi et basseng som overlapper et tjenesteprefiks gir ruting som ser riktig ut helt til det øyeblikket trafikken lander et uønsket sted.

Be om begge familiene når du trenger begge, og om én når du ikke trenger det, fordi en ubrukt adresse er politikkflate uten nytte. En spesifikk forespørsel er en forespørsel og ikke en reservasjon, og svareren kan returnere en annen verdi under sin egen politikk. Den detaljen betyr noe der en adresse er hardkodet i en brannmurregel eller en overvåkingssjekk. Referer til bassenger ved navn i tilkoblingen og hold tjenestenettverk utenfor dem.

vips = 0.0.0.0, ::

Generer ditt eget unike lokale prefiks for IPv6-bassenget i stedet for å overta en kort eksempelverdi. Eksempelet viser formen på innstillingen, ikke en standardverdi som skal arves.

Beskriv mål atskilt fra bassenger

Trafikkvelgere beskriver hva hver side forventer å utveksle, så gatewayens lokale velgere skal navngi beskyttede tjenesteprefikser og ikke klientbassenger. Klientens eksterne velgere gjenspeiler den intensjonen. Når de to listene beskriver forskjellige objekter, kan tunnelen komme opp og likevel ikke bære noe nyttig.

De samme prefiksene trenger returruter og tillatt videreformidling inne i gatewayens nettverk, for hver familie du aktiverer.

Det er her en privat IPv6-plan slutter å være tilstrekkelig. Unik lokal adressering kjøper privat nåbarhet og skaper ikke offentlig IPv6-utgang, så et design som antar at den unummererte familien bare følger IPv4-maskeringsreglene, vil skuffe brukerne sine. Hvis offentlig IPv6-tilgang er en del av kravet, trenger den en rutet plan og en oppstrøm som er enig i den. Ellers si klart at IPv6-siden bare er privat, noe som er en ærlig grense og ikke en begrensning som skal skjules.

Gjør DNS og returveier bevisste

Navneoppslag følger ikke transporten. En resolver kan returnere A- og AAAA-poster over en tunnel med bare IPv4, og klienten vil da prøve en familie du aldri planla. Avgjør hvilke tjenestenavn som skal bære brukbare dobbel-stakk-svar, og gjør begge disse veiene bevisste. Et navn som løses til en familie uten fungerende vei gir en stans i stedet for en ren feil, og stans er langt vanskeligere å diagnostisere.

Dokumenter nåbarheten til det ytre endepunktet separat, inkludert om noen NAT-gjennomgang er i spill og hvilken familie den bruker.

Skriv deretter planen på seks linjer: ytre endepunkt, IPv4-basseng, IPv6-basseng, IPv4-tjenesteprefiks, IPv6-tjenesteprefiks og ruteren som eier svarene for hver. En plan i den formen svarer på spørsmålene en operatør faktisk stiller klokken tre om natten. Alt kortere lar dobbel stakk stå som en annen adresse boltet på en politikk med bare IPv4, og det er slik det vanligvis ender med å virke halvveis.