Objavljivanje interne usluge preko ASA VPN-a od lokacije do lokacije

Objavljivanje usluge koja živi iza VPN-a od lokacije do lokacije jedan je zadatak s pet tačaka kvara, i one padaju u fiksnom redu. Tunel se podiže, prijevod se poklapa, podružnica odgovara, a odgovor se vraća istim putem. Kad je bilo što od toga pogrešno, preglednik pokazuje isto: vezu koja visi ili se resetira. Radite listu odozgo prema dolje i zaustavite se na prvoj provjeri koja padne.

Provjera 1: tunel štiti adresu izvora

Počnite od tunela koji već propušta promet, pa potvrdite da adresa koju planirate objaviti leži unutar zaštićenog opsega. Na ASA taj opseg dolazi iz kripto ACL-a ili iz ruta VTI-ja, i mora pokrivati stvarnu adresu izvora, a ne podmrežu koju podružnica koristi za upravljanje. Selektor koji promaši izvor daje vam tunel koji je podignut i tok koji u njega nikad ne ulazi.

Potvrdite to brojačima tunela i tablicom ruta prije nego dirnete prijevod. Ako izvor nije dostupan s čvorišta preko tunela, ništa kasnije na ovoj listi to ne može popraviti.

Zaustavite se ovdje ako se zaštićeni opseg i adresa izvora ne slažu.

Provjera 2: odlučite koji će izvor podružnica vidjeti

Podružnica vidi ili izvornu adresu klijenta ili prevedenu, i taj izbor odlučuje povratnu putanju. Čuvanje adrese klijenta čitljivije je u zapisima izvora, ali tada podružnica mora odgovore za javne klijente slati natrag kroz tunel; uobičajeni internetski default šalje ih na drugu stranu i veza umire u jednom smjeru. Prevođenje izvora u adresu koju podružnica već usmjerava kroz tunel uklanja taj zahtjev.

Prijevod također mijenja što izvor može bilježiti i s čime se pravila zasnovana na izvoru mogu poklapati. Ako aplikacija treba znati osobu iza zahtjeva, to pripada autentificiranom obrnutom proxyju, a ne odluci NAT-a.

Provjera 3: napišite prijevod prema stvarnim sučeljima

ASA procjenjuje pravila prijevoda po redu i izvještava koje se poklopilo, pa par sučelja unutar pravila nije kozmetički. Pravilo napisano za put izvana prema unutra neće se poklopiti s tokom čiji se ulaz i izlaz razlikuju od pretpostavljenih.

Put koji gradite ima četiri dionice i sve četiri moraju se slagati:

Tretirajte opsege u toj tablici kao rezervirana mjesta. Važno je da je torka nakon prijevoda adresa koju podružnica prihvaća kroz tunel i da obrnuto mapiranje postoji u NAT stanju kako bi se odgovor obnovio na izlazu.

Provjera 4: ograničite pravilo pristupa na objavljeni port

Objavite port, ne host. Pravilo koje dopušta izvor na svakoj usluzi pretvara jednu objavljenu aplikaciju u put do svega što izvor pokreće, uključujući upravljačko sučelje koje ste namjerno držali izvan interneta. Dopustite objavljeni port od prevedenog izvora do izvora i ostavite administrativne usluge na njihovoj putanji samo kroz VPN.

Istovremeno provjerite redoslijed pravila. Široka dozvola iznad vašeg konkretnog pravila čini konkretno pravilo nevidljivim.

Provjera 5: pratite jedan zahtjev i njegov odgovor

Ne počinjite preglednikom, jer preglednik skriva koja je dionica pala. Pratite tok na čvorištu i pročitajte rezultat prije nego što išta promijenite.

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

Pratnja navodi koji se prijevod poklopio, koje pravilo pristupa je dopustilo ili odbilo tok, i je li paket usmjeren u tunel. Ako pokazuje da tok izlazi sa sučelja koje niste očekivali, par sučelja u NAT pravilu je pogrešan. Ako pokazuje odbijanje, redoslijed pravila je pogrešan. Ako stigne do tunela ali izvor nikad ne odgovori, problem je povratna putanja podružnice.

Zatim pošaljite jedan stvarni zahtjev izvana i potvrdite da se odgovor vraća kroz isti tunel. Zabilježite objavljeni unos, prijevod, zaštićeni par adresa i povratnu rutu kao zapis o objavi.