Planificarea accesului privat IKEv2 cu stivă dublă și strongSwan

Un tunel cu stivă dublă nu este o decizie, ci trei, și la fiecare se poate răspunde diferit. Pe ce familie rulează tunelul exterior, ce familii primește clientul în interior și pe ce familii răspund efectiv serviciile protejate. Un proiect care le tratează ca o singură alegere fie transportă IPv6 de care nu a fost niciodată nevoie, fie distribuie adrese pe care nimic nu le poate ruta înapoi. Separați cele trei și restul configurației devine aproape mecanic.

Trei tipuri de adresă, decise separat

Adresa exterioară este modul în care cele două gateway-uri se ating, și poate fi IPv4 în timp ce traficul interior transportă ambele familii. Adresa virtuală interioară este identitatea clientului în tunel, și fiecare familie are nevoie de propriul grup. Prefixele protejate sunt ceea ce clientul poate atinge, și aparțin serviciilor, nu tunelului. Confundarea celei de-a treia cu a doua cauzează majoritatea erorilor de planificare, pentru că ambele arată ca intervale private.

Transportul exterior doar IPv4 cu trafic interior cu stivă dublă este o aranjare normală și bine susținută.

Decideți fiecare în mod explicit și notați deciziile. Dacă traseul exterior este doar IPv4, spuneți-o și opriți-vă din a vă îngrijora de accesibilitatea punctelor finale IPv6. Dacă o familie este alocată în interior dar nimic nu răspunde pe ea, fie o scoateți din plan, fie faceți acele servicii cu adevărat stivă dublă.

Alocați o adresă virtuală în fiecare familie

Într-o configurație swanctl clientul cere adrese virtuale, iar un metacaracter din fiecare familie cere respondenței să aloce câte una din fiecare. Respondența le ia din grupuri, iar grupurile sunt obiecte separate de rețelele din spatele gateway-ului. Țineți-le separate și în plan, pentru că un grup care se suprapune cu un prefix de serviciu produce rutare care pare corectă până în momentul în care traficul aterizează într-un loc nedorit.

Cereți ambele familii când aveți nevoie de amândouă, și una când nu, pentru că o adresă nefolosită este suprafață de politică fără beneficiu. O cerere specifică este o cerere, nu o rezervare, iar respondența poate returna o altă valoare conform propriei politici. Acel detaliu contează oriunde o adresă este codificată dur într-o regulă de firewall sau într-o verificare de monitorizare. Referiți grupurile după nume în conexiune și țineți rețelele de servicii în afara lor.

vips = 0.0.0.0, ::

Generați propriul prefix local unic pentru grupul IPv6 în loc să adoptați o valoare de exemplu scurtă. Exemplul arată forma setării, nu o valoare implicită de moștenit.

Descrieți destinațiile separat de grupuri

Selectoarele de trafic descriu ce așteaptă fiecare parte să schimbe, așa că selectoarele locale ale gateway-ului trebuie să numească prefixe de servicii protejate, nu grupuri de clienți. Selectoarele la distanță ale clientului reflectă acea intenție. Când cele două liste descriu obiecte diferite, tunelul poate urca și totuși nu transportă nimic util.

Aceleași prefixe au nevoie de rute de retur și de redirecționare permisă în rețeaua gateway-ului, pentru fiecare familie pe care o activați.

Aici un plan IPv6 privat încetează să mai fie suficient. Adresarea locală unică cumpără accesibilitate privată și nu creează ieșire IPv6 publică, așa că un proiect care presupune că familia fără numere va urma pur și simplu regulile de mascare IPv4 își va dezamăgi utilizatorii. Dacă accesul IPv6 public face parte din cerință, are nevoie de un plan rutat și de un furnizor amonte care este de acord cu el. Altfel spuneți clar că partea IPv6 este doar privată, ceea ce este o graniță onestă și nu o limitare de ascuns.

Faceți DNS-ul și căile de retur intenționate

Rezolvarea numelor nu urmează transportul. Un resolver poate returna înregistrări A și AAAA printr-un tunel doar IPv4, iar clientul va încerca atunci o familie pe care nu ați planificat-o niciodată. Decideți ce nume de serviciu trebuie să poarte răspunsuri cu stivă dublă utilizabile și faceți ambele căi intenționate. Un nume care se rezolvă într-o familie fără cale funcțională produce o blocare în loc de o eroare curată, iar blocările sunt mult mai greu de diagnosticat.

Documentați accesibilitatea punctului final exterior separat, inclusiv dacă este implicată vreo traversare NAT și ce familie folosește.

Apoi scrieți planul în șase linii: punct final exterior, grup IPv4, grup IPv6, prefix de serviciu IPv4, prefix de serviciu IPv6 și routerul care deține răspunsurile pentru fiecare. Un plan în acea formă răspunde la întrebările pe care un operator le pune cu adevărat la trei dimineața. Orice mai scurt lasă stiva dublă ca o a doua adresă înșurubată pe o politică doar IPv4, și așa ajunge de obicei să funcționeze pe jumătate.