Ruta implicită tunneled pe Cisco ASA: când se aplică de fapt

Un utilizator cu acces la distanță nu ajunge la nimic dincolo de ASA, în timp ce același server răspunde la ping-uri din LAN-ul intern. Tunelul se ridică, clientul primește o adresă din pool, iar pachetul tot pleacă pe ruta implicită de internet sau dispare. Acest tipar înseamnă de obicei că traficul decriptat nu a găsit o rută proprie și a căzut pe ruta implicită obișnuită. Remedierea nu este o altă regulă NAT; este ruta implicită tunneled.

Începe cu simptomul, nu cu configurația

Urmărește unde merge pachetul, nu unde te așteptai să meargă. O captură pe interfața externă în timpul unei sesiuni eșuate arată pachetul decriptat îndreptându-se spre gateway-ul ISP cu adresa din pool încă intactă, sau nu arată nimic pentru că căutarea a eșuat. În ambele cazuri, tunelul nu este problema.

Tunelul arată sănătos în show vpn-sessiondb, și exact de aceea oamenii continuă să depaneze IKE.

Ceea ce desparte acest caz de o aruncare ACL este direcția. O aruncare ACL este înregistrată și numărată, în timp ce o rută lipsă produce o eroare de căutare fără nicio intrare potrivită. Rulează show route pentru destinația clientului și citește ce a selectat de fapt ASA, inclusiv dacă a fost aleasă o rută implicită și care.

Prin ce diferă căutarea tunneled

Ghidul Cisco pentru rutare statică pe ASA 9.23 documentează o rută implicită separată pentru traficul VPN decriptat care nu are rută statică sau învățată. Cuvântul-cheie tunneled marchează acea rută, așa că un pachet decriptat poate cădea pe un alt următor hop decât cel pe care ASA îl folosește pentru propriul transport. Rutele mai specifice câștigă în continuare, și de aceea un client poate ajunge la 10.0.0.0/8 prin gateway-ul intern și pierde tot restul.

Un aranjament minimal păstrează două rute implicite cu următor hop-uri diferite. Una transportă traficul propriu al ASA, cealaltă transportă traficul decriptat care nu are o rută mai bună. Ambele următoare hop-uri trebuie să fie în continuare accesibile din interfața căreia îi atașezi.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Dacă ambele rute implicite indică același următor hop, cuvântul-cheie nu schimbă nimic și simptomul nu se va mișca.

Restricțiile care decid dacă funcționează

Același ghid permite o singură rută implicită tunneled și afirmă că ECMP nu este suportat pentru ea, deci nu poți distribui sarcina pe acea cale. De asemenea, enumeră restricții privind urmărirea rutelor, verificarea căii inverse și unele fluxuri de inspecție și administrare. Citește-le în raport cu versiunea instalată înainte de a proiecta în jurul funcției. Un proiect care le ignoră eșuează de obicei într-un singur loc anume, nu peste tot, și de aceea simptomul pare intermitent.

Verificarea căii inverse este cea care mușcă în proiectele asimetrice. Dacă răspunsul ar sosi printr-o interfață diferită de cea pe care o așteaptă ASA, pachetul este aruncat înainte ca rutarea să conteze. Repară topologia sau calea de retur în loc să dezactivezi verificarea pentru a forța un următor hop.

Urmărirea rutelor este o capcană separată: obiectul urmărit păzește de obicei ruta implicită obișnuită, nu pe cea tunneled.

Ce nu face cuvântul-cheie

Nu alege adresa sursă pe care ASA o folosește pentru a construi IKE. Endpoint-ul extern al tunelului urmează selecția de interfață și de sursă a platformei, iar ruta implicită tunneled nu are niciun rol în acea decizie. Schimbarea ei nu va repara o phase 1 care pleacă de la adresa greșită.

Nici nu transformă următorul hop într-un proxy. Dacă destinația așteaptă un schimb HTTP CONNECT, trimiterea de pachete IP brute către un host proxy îți dă doar un host care nu le rutează. Configurează în schimb mecanismul de proxy suportat de client.

Și nu creează forwarding în aval. Gateway-ul spre care indici are în continuare nevoie de o rută înapoi spre pool-ul VPN, plus traducerea sursei acolo unde proiectul o cere.

Verifică calea de la un capăt la altul

După ce ruta este pusă, verifică patru lucruri în ordine: show route pentru o destinație de care are nevoie pool-ul, o captură pe interfața spre noul următor hop, o captură pe gateway-ul însuși și o cale de retur de la acel gateway la adresa din pool. Primele două dovedesc că ASA a ales calea, iar ultimele două că cineva răspunde pe ea.

Dacă gateway-ul răspunde dar clientul nu vede niciodată un răspuns, uită-te la traducerea sursei și la ruta de retur înainte de a atinge din nou tabela de rutare.

Notează versiunea pe care ai validat, pentru că lista restricțiilor este specifică versiunii, iar un proiect care funcționează pe un tren poate avea nevoie de altă cale pe altul. Acea notă supraviețuiește fragmentului de configurare.