Poate o singură interfață WAN să deservească VPN-ul între locații și accesul la distanță?

O singură adresă publică poate deservi simultan un tunel de sucursală și un pool de utilizatori mobil. Dar nu poate deservi o singură regulă de admitere comună. Partenerul sucursalei și utilizatorul mobil diferă prin cine pretind că sunt, prin modul în care este verificată această dovadă, prin adresele pe care le primesc și prin prefixele care le pot răspunde. Odată ce tratați adresa externă ca pe un detaliu de transport și nu ca pe o identitate, proiectarea devine mult mai simplă.

Un test rapid de bun simț: încercați să scrieți ambele înregistrări de admitere înainte de a atinge routerul. Dacă o singură condiție de potrivire trebuie să le acopere pe amândouă, politica este deja ambiguă, iar primul simptom va arăta ca o defecțiune de rutare sau de firewall, deși în realitate este o defecțiune de identitate.

Două înregistrări înainte de orice configurare

Înregistrarea sucursalei este scurtă și stabilă. Ea enumeră adresa partenerului sau numele certificatului, cheia partajată în prealabil sau punctul de încredere al certificatului, subrețelele protejate de ambele părți, interfața tunelului și ruta statică ce trimite traficul către sucursală în acel tunel. Fiecare câmp privește un partener cunoscut și un set fix de prefixe.

Înregistrarea pentru mobilitate este mai largă și mai personală. Ea enumeră protocolul și portul clientului, modul în care un utilizator sau un dispozitiv se autentifică, pool-ul de adrese acordat la conectare, resursele pe care acel pool le poate atinge, prefixele tunelului divizat, serverele DNS împinse către client și orice al doilea factor. Fiecare câmp răspunde unei întrebări despre un număr necunoscut de utilizatori, nu despre o singură poartă.

Tocmai această diferență de granularitate este tot motivul pentru care cele două roluri se despart. Un profil de sucursală poate avea încredere într-o singură cheie, pentru că cheia aparține unui singur dispozitiv într-un singur loc. Un profil de mobilitate care se încrede într-o singură cheie de grup pentru toți distruge responsabilitatea pe utilizator, iar acest lucru se descoperă de obicei mai târziu, la analiza unui incident și nu la implementare.

Unde se despart potrivirea partenerilor și autentificarea

Pe IOS XE profilul IKEv2 poartă parametrii care nu pot fi negociați și condițiile folosite pentru selectarea partenerului. Asta înseamnă că partea sucursalei și partea de mobilitate au nevoie fiecare de propriul profil, chiar și atunci când se termină pe aceeași interfață și chiar și atunci când partajează o singură PKI criptografică. Cisco documentează rolurile profilului, autentificării și potrivirii în ghidul de configurare IKEv2 pentru IOS XE 17.

Profilul sucursalei se potrivește de obicei cu o identitate îngustă: o adresă la distanță, un FQDN sau un subiect de certificat. Ceva ca match identity remote address 198.51.100.10 255.255.255.255 fixează un singur partener, iar authentication remote pre-share cu o cheie păstrată pentru fiecare loc este suficient. Păstrați potrivirea cât mai specifică permite inventarul partenerilor, pentru că un wildcard suprapus mai sus în ordinea de selecție poate trage traficul sucursalei în profilul greșit.

Profilul de mobilitate nu poate fixa o adresă, așa că se potrivește cu un grup, un key-id sau un câmp al certificatului, apoi predă verificarea reală a utilizatorului către AAA sau către politica de autorizare atașată profilului. Această separare contează: autentificarea partenerului răspunde dacă clientului îi este permis să construiască un tunel, iar autorizarea pe utilizator răspunde ce pool și ce resurse primește. Folosirea cheii sucursalei ca autentificare universală aruncă al doilea răspuns.

Comutarea și traducerea au nevoie de aceeași separare

Admiterea și accesibilitatea sunt probleme separate. Un schimb IKE și IPsec reușit dovedește că părțile sunt de acord asupra cheilor; nu creează o rută către pool-ul pe care clientul l-a primit. De aceea pool-urile de acces la distanță au nevoie de o cale de retur: fie o rută statică ce indică interfața tunelului, fie un protocol de rutare care injectează rezumatul pool-ului. Prefixele sucursalei sosesc de obicei prin același proces de rutare care deservește restul locației.

Traducerea este locul unde cele două roluri se ciocnesc cel mai des. Traficul între locații care trebuie să își păstreze adresele private are nevoie de o excepție NAT limitată la acele două prefixe, în ambele sensuri. Clienții mobili au nevoie de obicei și de excepție pentru traficul lor din tunel, dar traficul lor către internet fie ocolește tunelul prin tunelul divizat, fie iese la concentrator după NAT. A excepta tot ce vine dintr-un tunel este greșeala clasică, pentru că ia traducerea și de la traficul care chiar are nevoie de ea.

Păstrați regulile de excepție la fel de înguste ca regulile de admitere. Dacă un rezumat de pool și un prefix de sucursală se suprapun, calea de retur devine ambiguă mult înainte de a fi aruncat vreun pachet, iar simptomul apare ca o locație care pierde din când în când o subrețea și nu ca o defecțiune curată a tunelului.

Cazuri de acceptare care expun o politică încrucișată

Construiți patru cazuri și rulați-le în ordine. Un host din sucursală atinge o resursă doar a sucursalei. Un client mobil atinge aceeași resursă prin adresa pool-ului său. Un client mobil încearcă un prefix al sucursalei pe care nu ar trebui să îl atingă. Un partener al sucursalei încearcă să obțină o adresă din pool-ul de acces la distanță. Ultimele două sunt cele care prind un profil partajat, pentru că eșuează în tăcere în monitorizarea normală.

Apoi confirmați planul de date și nu configurația. show crypto ikev2 sa și show crypto ipsec sa spun ce profil și ce selectori au purtat fiecare flux, în timp ce show ip nat translations și contoarele tunelului arată dacă calea de retur și excepția s-au potrivit într-adevăr. Un tracer sau o captură de pachete pe interfața tunelului închide bucla.

Notați identitatea observată, adresa din pool și politica aleasă lângă fiecare rezultat. Runda este terminată când fiecare caz corespunde exact unei înregistrări și niciun caz nu are nevoie de o excepție temporară pentru a trece.