Planlegging av privat IKEv2-tilgang med dobbel stakk og strongSwan

Ein tunnel med dobbel stakk er ikkje éi avgjerd, men tre, og dei kan svarast ulikt. Kva familie den ytre tunnelen går over, kva familiar klienten mottek inni, og kva familiar dei verna tenestene faktisk svarar på. Eit design som handsamar dei som eitt val, ber anten IPv6 som aldri var naudsynt, eller deler ut adresser som ingenting kan rute tilbake. Skil dei tre, og resten av konfigurasjonen vert nesten mekanisk.

Tre typar adresser, avgjort kvar for seg

Den ytre adressa er korleis dei to gatewayane når kvarandre, og ho kan vere IPv4 medan den indre trafikken ber begge familiane. Den indre virtuelle adressa er identiteten til klienten inne i tunnelen, og kvar familie treng sitt eige basseng. Dei verna prefiksa er det klienten kan nå, og dei høyrer til tenestene og ikkje tunnelen. Å forveksle det tredje med det andre valdar dei fleste planleggingsfeila, fordi begge ser ut som private område.

Ytre transport med berre IPv4 og indre trafikk med dobbel stakk er ei normal og godt støtta ordning.

Avgjer kvar einskild eksplisitt og skriv ned avgjerdene. Viss den ytre vegen berre er IPv4, seier du det og sluttar å uro deg for nåbarheita til IPv6-endepunkt. Viss ein familie vert tildelt inni, men ingenting svarar på han, fjernar du han frå planen eller gjer desse tenestene reelt dobbel-stakka.

Tildel ei virtuell adresse i kvar familie

I ein swanctl-konfigurasjon ber klienten om virtuelle adresser, og eit jokerteikn i kvar familie ber svararen tildele éi av kvar. Svararen hentar dei frå basseng, og basseng er separate objekt frå netverka bak gatewayen. Hald dei skilde i planen òg, fordi eit basseng som overlappar eit tenesteprefiks gjev ruting som ser riktig ut heilt til det augneblunken trafikken landar ein uønskt stad.

Be om begge familiane når du treng begge, og om éin når du ikkje treng det, fordi ei ubrukt adresse er politikkflate utan nytte. Ein spesifikk førespurnad er ein førespurnad og ikkje ein reservasjon, og svararen kan returnere ein annan verdi under sin eigen politikk. Den detaljen tel der ei adresse er hardkoda i ein brannmurregel eller ein overvakingssjekk. Vis til basseng ved namn i tilkopinga og hald tenestenettverk utanfor dei.

vips = 0.0.0.0, ::

Generer ditt eige unike lokale prefiks for IPv6-bassenget i staden for å overta ein kort eksempelverdi. Eksempelet viser forma på innstillinga, ikkje ein standardverdi som skal arvast.

Skildre mål skilt frå basseng

Trafikkveljarar skildrar kva kvar side ventar å utveksle, så dei lokale veljarane til gatewayen skal namngje verna tenesteprefiks og ikkje klientbasseng. Dei eksterne veljarane til klienten speglar den intensjonen. Når dei to listene skildrar ulike objekt, kan tunnelen kome opp og likevel ikkje bere noko nyttig.

Dei same prefiksa treng returruter og tillaten vidaresending inne i netverket til gatewayen, for kvar familie du aktiverer.

Det er her ein privat IPv6-plan sluttar å vere tilstrekkeleg. Unik lokal adressering kjøper privat nåbarheit og skapar ikkje offentleg IPv6-utgang, så eit design som går ut frå at den unummererte familien berre følgjer IPv4-maskeringsreglane, vil skuffe brukarane sine. Viss offentleg IPv6-tilgang er ein del av kravet, treng han ein ruta plan og ein oppstraum som er samd i han. Elles seier du klart at IPv6-sida berre er privat, noko som er ei ærleg grense og ikkje ei avgrensing som skal skjulast.

Gjer DNS og returvegar medvitne

Namneoppslag følgjer ikkje transporten. Ein resolver kan returnere A- og AAAA-postar over ein tunnel med berre IPv4, og klienten vil då prøve ein familie du aldri planla. Avgjer kva tenestenamn som skal bere brukbare dobbel-stakk-svar, og gjer begge desse vegane medvitne. Eit namn som løysest til ein familie utan fungerande veg gjev ein stans i staden for ein rein feil, og stansar er langt vanskelegare å diagnostisere.

Dokumenter nåbarheita til det ytre endepunktet separat, inkludert om nokon NAT-gjennomgang er i spel og kva familie han brukar.

Skriv deretter planen på seks linjer: ytre endepunkt, IPv4-basseng, IPv6-basseng, IPv4-tenesteprefiks, IPv6-tenesteprefiks og rutaren som eig svara for kvar. Ein plan i den forma svarar på spørsmåla ein operatør faktisk stiller klokka tre om natta. Alt kortare lèt dobbel stakk stå som ei anna adresse bolta på ein politikk med berre IPv4, og det er slik det vanlegvis endar med å verke halvvegs.