Om ’n diens wat agter ’n werf-tot-werf-VPN woon te publiseer, is een taak met vyf foutpunte, en hulle faal in ’n vaste volgorde. Die tonnel kom op, die vertaling pas, die tak antwoord, en die antwoord kom terug deur dieselfde pad. Wanneer enige een daarvan verkeerd is, wys die blaaier dieselfde ding: ’n verbinding wat hang of herstel. Werk die lys van bo na onder en stop by die eerste kontrole wat faal.

Kontrole 1: die tonnel beskerm die oorsprongadres

Begin by ’n tonnel wat reeds verkeer deurlaat, en bevestig dan dat die adres wat jy beplan om te publiseer binne die beskermde reeks val. Op ’n ASA kom daardie reeks van die kripto-ACL of van die roetes van ’n VTI, en dit moet die oorsprong se werklike adres dek eerder as die subnet wat die tak vir bestuur gebruik. ’n Keurder wat die oorsprong mis, gee jou ’n tonnel wat op is en ’n vloei wat nooit daarby ingaan nie.

Bevestig met die tonneltellers en die roetetabel voordat jy aan die vertaling raak. As die oorsprong nie van die hub af deur die tonnel bereikbaar is nie, kan niks later in hierdie lys dit herstel nie.

Stop hier as die beskermde reeks en die oorsprongadres nie ooreenstem nie.

Kontrole 2: besluit watter bron die tak sal sien

Die tak sien óf die oorspronklike kliëntadres óf ’n vertaalde een, en daardie keuse bepaal die terugpad. Om die kliëntadres te bewaar lees skoner in die oorsprong se logboeke, maar die tak moet dan antwoorde vir openbare kliënte terug deur die tonnel stuur; ’n gewone internet-standaard stuur hulle die ander kant toe en die verbinding sterf in een rigting. Om die bron te vertaal na ’n adres wat die tak reeds oor die tonnel routeer, verwyder daardie vereiste.

Vertaling verander ook wat die oorsprong kan log en watter brongebaseerde reëls kan pas. As die toepassing die mens agter ’n versoek moet ken, hoort dit in ’n geauthentiseerde omgekeerde proxy, nie in ’n NAT-besluit nie.

Kontrole 3: skryf die vertaling teen die werklike koppelvlakke

’n ASA evalueer vertalingsreëls in volgorde en rapporteer watter een gepas het, so die koppelvlakpaar binne die reël is nie cosmeties nie. ’n Reël wat vir ’n buite-na-binne-pad geskryf is, sal nie pas by ’n vloei wie se in- en uitgang van dié verskil wat jy aangeneem het nie.

Die pad wat jy bou het vier bene, en al vier moet ooreenstem:

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

Behandel die reekse in daardie tabel as plekhouers. Wat saak maak, is dat die tuple ná vertaling ’n adres is wat die tak oor die tonnel aanvaar, en dat die omgekeerde kartering in die NAT-toestand bestaan sodat die antwoord op die uitpad herstel word.

Kontrole 4: beperk die toegangsreël tot die gepubliseerde poort

Publiseer die poort, nie die gasheer nie. ’n Reël wat die oorsprong op elke diens toelaat, verander een gepubliseerde toepassing in ’n pad na alles wat die oorsprong bedryf, insluitend die bestuurskoppelvlak wat jy doelbewus van die internet af gehou het. Laat die gepubliseerde poort van die vertaalde bron na die oorsprong toe, en laat administratiewe dienste op hul slegs-VPN-pad.

Kontroleer terselfdertyd die reëlvolgorde. ’n Breë toelating wat bo jou spesifieke reël sit, maak die spesifieke reël onsigbaar.

Kontrole 5: spoor een versoek en sy antwoord na

Moenie met ’n blaaier begin nie, want ’n blaaier verberg watter been gefaal het. Spoor die vloei op die hub na en lees die resultaat voordat jy enigiets verander.

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

Die nasporing noem die vertaling wat gepas het, die toegangsreël wat die vloei toegelaat of geweier het, en of die pakkie in die tonnel ingeroeteer is. As dit wys die vloei verlaat ’n koppelvlak wat jy nie verwag het nie, is die koppelvlakpaar in die NAT-reël verkeerd. As dit ’n weiering wys, is die reëlvolgorde verkeerd. As dit die tonnel bereik maar die oorsprong antwoord nooit, is die tak se terugpad die probleem.

Stuur dan een werklike versoek van buite en bevestig die antwoord kom terug deur dieselfde tonnel. Teken die gepubliseerde inskrywing, die vertaling, die beskermde adrespaar en die terugroete aan as die publikasierekord.

Verwante artikels