Publicarea unui serviciu care trăiește în spatele unui VPN site-to-site este o singură sarcină cu cinci puncte de eșec, iar ele eșuează într-o ordine fixă. Tunelul urcă, traducerea se potrivește, filiala răspunde și răspunsul se întoarce pe aceeași cale. Când oricare dintre ele este greșit, browserul arată același lucru: o conexiune care se blochează sau se resetează. Parcurgeți lista de sus în jos și opriți-vă la prima verificare care eșuează.

Verificarea 1: tunelul protejează adresa sursei

Începeți cu un tunel care deja transportă trafic, apoi confirmați că adresa pe care intenționați să o publicați se află în intervalul protejat. Pe un ASA acel interval provine din ACL-ul de criptare sau din rutele unui VTI și trebuie să acopere adresa reală a sursei, nu subrețeaua pe care filiala o folosește pentru administrare. Un selector care ratează sursa vă dă un tunel care stă în picioare și un flux care nu intră niciodată în el.

Confirmați cu contoarele tunelului și tabela de rute înainte de a atinge traducerea. Dacă sursa nu este accesibilă din hub prin tunel, nimic mai departe în această listă nu o poate repara.

Opriți-vă aici dacă intervalul protejat și adresa sursei nu coincid.

Verificarea 2: decideți ce sursă va vedea filiala

Filiala vede fie adresa originală a clientului, fie una tradusă, iar această alegere decide calea de întoarcere. Păstrarea adresei clientului se citește mai curat în jurnalele sursei, dar atunci filiala trebuie să trimită răspunsurile pentru clienții publici înapoi prin tunel; o rută implicită obișnuită de internet le trimite în cealaltă direcție și conexiunea moare într-o direcție. Traducerea sursei într-o adresă pe care filiala o rutează deja prin tunel elimină această cerință.

Traducerea schimbă și ce poate înregistra sursa și cu ce se pot potrivi regulile bazate pe sursă. Dacă aplicația trebuie să știe persoana din spatele unei cereri, locul ei este într-un proxy invers autentificat, nu într-o decizie NAT.

Verificarea 3: scrieți traducerea față de interfețele reale

Un ASA evaluează regulile de traducere în ordine și raportează care s-a potrivit, așa că perechea de interfețe din regulă nu este cosmetică. O regulă scrisă pentru o cale din exterior spre interior nu se va potrivi cu un flux a cărui intrare și ieșire diferă de cele presupuse.

Calea pe care o construiți are patru segmente, și toate patru trebuie să coincidă:

LegSourceDestination
Request from the internet198.51.100.25203.0.113.20:443
After destination translation198.51.100.2510.60.20.10:443
After source translation toward the tunnel10.10.250.1010.60.20.10:443
Branch reply10.60.20.1010.10.250.10
Restored reply to the client203.0.113.20198.51.100.25

Tratați intervalele din acel tabel ca substituenți. Important este ca tuplul de după traducere să fie o adresă pe care filiala o acceptă prin tunel și ca maparea inversă să existe în starea NAT, astfel încât răspunsul să fie restaurat la ieșire.

Verificarea 4: limitați regula de acces la portul publicat

Publicați portul, nu gazda. O regulă care permite sursa pe fiecare serviciu transformă o aplicație publicată într-o cale către tot ce rulează sursa, inclusiv interfața de administrare pe care ați ținut-o intenționat în afara internetului. Permiteți portul publicat de la sursa tradusă la sursă și lăsați serviciile administrative pe calea lor doar prin VPN.

Verificați ordinea regulilor în același timp. O permisiune largă deasupra regulii dumneavoastră specifice face regula specifică invizibilă.

Verificarea 5: urmăriți o cerere și răspunsul ei

Nu începeți cu un browser, pentru că un browser ascunde care segment a eșuat. Urmăriți fluxul pe hub și citiți rezultatul înainte de a schimba ceva.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Urmărirea numește traducerea care s-a potrivit, regula de acces care a permis sau a refuzat fluxul și dacă pachetul a fost rutat în tunel. Dacă arată fluxul ieșind pe o interfață pe care nu o așteptați, perechea de interfețe din regula NAT este greșită. Dacă arată un refuz, ordinea regulilor este greșită. Dacă ajunge la tunel dar sursa nu răspunde niciodată, problema este calea de întoarcere a filialei.

Apoi trimiteți o cerere reală din exterior și confirmați că răspunsul se întoarce prin același tunel. Înregistrați intrarea publicată, traducerea, perechea de adrese protejată și ruta de întoarcere ca registru de publicare.

Articole similare