ASA VPN hairpin: rutarea a două tuneluri printr-o singură interfață

Traficul unui utilizator la distanță poate ieși prin aceeași interfață ASA pe care a intrat, dar permisiunea hairpin, amploarea tunelului, NAT și ACL-urile sunt patru decizii separate.

Un utilizator la distanță se conectează la ASA, cere un host din spatele unei filiale, iar ASA trimite acea cerere prin exact aceeași interfață prin care a intrat utilizatorul. Nimic din asta nu necesită un al doilea port fizic. Ceea ce necesită sunt patru decizii independente pe care oamenii au tendința să le contopească într-una: permisiunea de a face hairpin, un tunel care protejează adresele corecte, o politică NAT care păstrează sursa promisă și o politică de acces care autorizează serviciul.

Un pachet, două tuneluri

Urmează fluxul și ordinea operațiilor încetează să mai fie misterioasă. Pachetul ajunge în tunelul de acces la distanță, este decriptat și devine un pachet IP obișnuit cu sursa din pool-ul de clienți. Apoi ASA îl rutează, îl compară cu ACL-ul de criptare de la site la site, îl criptează din nou și îl trimite prin interfața exterioară spre filială.

Adresele de mai jos sunt ilustrative, dar forma contează: sursa este pool-ul, nu LAN-ul intern al ASA-ului.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Din asta decurg două lucruri. Clientul are nevoie de o rută către prefixul filialei prin conexiunea sa de acces la distanță, ceea ce înseamnă că split-tunnel sau lista de rute împinsă trebuie să o includă. Iar filiala trebuie să știe cum să returneze traficul către 10.77.0.20 sau către adresa pe care designul NAT a înlocuit-o.

Permisiunea hairpin este globală

Comanda la care apelează oamenii este same-security-traffic permit intra-interface. Ea permite traficului să intre și să iasă prin aceeași interfață, exact ceea ce are nevoie această cale. Este și o setare globală: activarea ei schimbă comportamentul altor fluxuri care traversează din întâmplare aceeași interfață de două ori.

De aceea îi aparține unui registru de modificări și nu unei sesiuni de depanare. Întrebați ce altceva de pe echipament ar putea lua acum o cale prin aceeași interfață și dacă ceva ar trebui. Pe o margine aglomerată cu rețele de oaspeți sau tuneluri de parteneri suprapuse, răspunsul nu este automat nu. Scrieți motivul lângă setare, pentru că următorul inginer va găsi comanda, nu conversația.

Amploarea protecției și NAT sunt separate

Tunelul de la site la site protejează ceea ce selectează ACL-ul său de criptare. Dacă acel ACL numește subrețeaua internă a ASA ca sursă, pool-ul de acces la distanță nu este protejat și pachetul fie va fi eliminat, fie trimis în clar, în funcție de comportamentul platformei pentru traficul nepotrivit. Adăugați pool-ul la fluxul protejat atunci când designul păstrează adresele pool-ului.

Apoi NAT decide dacă adresa pool-ului supraviețuiește. Identity NAT o păstrează, iar filiala vede 10.77.0.20 ca sursă. Traducerea schimbă contractul: filiala returnează acum traficul către adresa tradusă, iar propria politică trebuie să o accepte. Ordinea regulilor decide dacă ACL-ul de criptare se potrivește înainte sau după traducere, așa că citiți fluxul efectiv în loc să presupuneți care câștigă.

Nu ștergeți regulile PAT generale de internet pentru ca un singur caz de tranzit să funcționeze. O excepție țintită sau o regulă identity deliberată sunt mai ușor de explicat și de anulat decât o gaură în politica de ieșire.

Criptarea nu este autorizare

Un tunel funcțional dovedește doar că două părți sunt de acord asupra cheilor și selectorilor. Nu spune nimic despre dacă acest utilizator poate ajunge la acel serviciu. Filtrul VPN sau politica de grup atașate conexiunii de acces la distanță trebuie încă să permită destinația și portul filialei, iar ACL-ul interfeței pe calea exterioară se aplică în continuare.

Testați răspunsul în ambele direcții. O conexiune care reușește în timp ce un serviciu vecin ar trebui să eșueze este mai informativă decât un singur ping reușit, pentru că arată că politica este selectivă, nu larg deschisă. Dacă testul care ar trebui refuzat reușește, vinovat nu este tunelul, ci politica. Păstrați ambele rezultate în registrul de modificări, astfel încât următoarea persoană să știe ce comportament a fost intenționat.

Hairpin sau o a doua interfață

Tranzitul hairpin menține designul mic și costă o singură setare globală. O interfață separată, sau un tunel bazat pe rutare cu propria interfață virtuală, izolează calea de tranzit și vă oferă politică pe interfață, cu prețul adresării și încă un crypto map sau profil. Niciuna nu este mai corectă; eșuează diferit.

Designurile bazate pe rutare sunt o altă aranjare, nu o casetă de bifare în aceeași configurație. Dacă treceți la unul, discuția de mai sus despre ACL-ul de criptare bazat pe politici încetează să se aplice, iar tabela de rutare începe să facă munca de selecție.

Verificați de la clientul real

O sondă pornită din ASA are o altă adresă de sursă și nu va parcurge calea de la pool la filială. Folosiți packet-tracer pentru a verifica cvintuplul, apoi deschideți o conexiune reală de la clientul la distanță efectiv, pentru că trasorul simulează și nu înlocuiește rutarea și politica clientului însuși.

După o modificare planificată, conectați-vă la un serviciu care ar trebui să funcționeze, apoi la unul care ar trebui refuzat, iar apoi confirmați ruta de retur a filialei. exemplele Cisco de NAT hairpin pentru VPN păstrează permisiunea intra-interface, NAT și ACL-urile vizibil separate, iar acesta este modelul mental care merită copiat.

Articole similare