Sisemise teenuse avaldamine ASA saitidevahelise VPN-i kaudu

Saitidevahelise VPN-i taga elava teenuse avaldamine on üks ülesanne viie tõrkepunktiga ja need tõrkestuvad kindlas järjekorras. Tunnel tõuseb, tõlge klapib, haru vastab ja vastus tuleb tagasi sama teed. Kui mõni neist on vale, näitab brauser sama asja: ühendus, mis jääb rippuma või lähtestatakse. Töötage nimekiri ülalt alla läbi ja peatuge esimesel kontrollil, mis ebaõnnestub.

Kontroll 1: tunnel kaitseb päritolu aadressi

Alustage tunnelist, mis juba liiklust läbi laseb, seejärel kinnitage, et aadress, mille kavatsete avaldada, asub kaitstud vahemikus. ASA-l tuleb see vahemik krüpto-ACL-ist või VTI marsruutidest ja see peab katma päritolu tegelikku aadressi, mitte alavõrku, mida haru haldamiseks kasutab. Selektor, mis päritolust mööda läheb, annab teile tunneli, mis on püsti, ja voolu, mis sinna kunagi ei sisene.

Kinnitage seda tunneli loendurite ja marsruutitabeliga enne, kui tõlget puudutate. Kui päritolu pole jaotuspunktist tunneli kaudu kättesaadav, ei paranda seda miski hilisem selles nimekirjas.

Peatuge siin, kui kaitstud vahemik ja päritolu aadress ei ühti.

Kontroll 2: otsustage, millist allikat haru näeb

Haru näeb kas kliendi algset aadressi või tõlgitud aadressi, ja see valik määrab tagasitee. Kliendi aadressi säilitamine loeb päritolu logides puhtamalt, aga siis peab haru avalike klientide vastused tunneli kaudu tagasi saatma; tavaline interneti vaikemarsruut saadab need teisele poole ja ühendus sureb ühes suunas. Allika tõlkimine aadressiks, mille haru juba tunneli kaudu marsruudib, kaotab selle nõude.

Tõlge muudab ka seda, mida päritolu saab logida ja millega allikapõhised reeglid klapivad. Kui rakendus peab teadma inimest päringu taga, kuulub see autenditud pöördpuhverserverisse, mitte NAT-i otsusesse.

Kontroll 3: kirjutage tõlge tegelike liideste järgi

ASA hindab tõlkereegleid järjest ja teatab, milline klappis, seega pole reegli sees olev liideste paar kosmeetiline. Väljast-isse teekonnale kirjutatud reegel ei klapi vooluga, mille sisse- ja väljund erinevad eeldatutest.

Teel, mida ehitate, on neli lüli ja kõik neli peavad klappima:

Käsitlege selle tabeli vahemikke kohatäitjatena. Tähtis on, et tõlkejärgne korteež on aadress, mille haru tunneli kaudu vastu võtab, ja et pöördvastendus on NAT-i olekus olemas, et vastus väljumisel taastataks.

Kontroll 4: piirake juurdepääsureegel avaldatud pordiga

Avaldage port, mitte host. Reegel, mis lubab päritolu igal teenusel, muudab ühe avaldatud rakenduse teeks kõige juurde, mida päritolu jooksutab, sealhulgas haldusliides, mille te meelega internetist väljas hoidsite. Lubage avaldatud port tõlgitud allikast päritoluni ja jätke haldusteenused nende ainult-VPN teele.

Kontrollige samal ajal reeglite järjekorda. Lai luba teie konkreetse reegli kohal teeb konkreetse reegli nähtamatuks.

Kontroll 5: jälgige üht päringut ja selle vastust

Ärge alustage brauserist, sest brauser varjab, milline lüli ebaõnnestus. Jälgige voolu jaotuspunktis ja lugege tulemust enne, kui midagi muudate.

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

Jälg nimetab tõlke, mis klappis, juurdepääsureegli, mis voolu lubas või keelas, ja kas pakett suunati tunnelisse. Kui see näitab, et vool lahkub liidesest, mida te ei oodanud, on NAT-reegli liideste paar vale. Kui see näitab keeldu, on reeglite järjekord vale. Kui see jõuab tunnelini, aga päritolu ei vasta kunagi, on probleem haru tagasiteel.

Seejärel saatke üks päris päring väljast ja kinnitage, et vastus tuleb tagasi sama tunneli kaudu. Kirjutage avaldatud kirje, tõlge, kaitstud aadressipaar ja tagasitee avaldamisprotokolli.