ASA identiteits-NAT tsjin IOS NAT-útsûndering foar VPN-ferkear

In filiaal hâldt internet-PAT en in site-to-site VPN op deselde Cisco-gateway, en de VPN stopet mei wurkjen sadree't NAT tafoege wurdt. De adressen yn 'e tunnel komme net mear oerien mei wat de crypto-ACL beskermet, of de partner sjocht oersette adressen dêr't er gjin rûte foar hat. Cisco lost dit op twa plakken op: de ASA kiest in NAT-regel dy't in adres op himsels mappet, wylst IOS de stream bûten in oersettingsregel hâldt fia in deny yn 'e ACL. Beide behâlde de oarspronklike adressen, en gjinien is in omgong fan NAT-ferwurking.

Skriuw de stream op foardat jo in regel kieze

Begjin mei it opskriuwen fan 'e stream dy't jo beskermje wolle: de LAN-boarne, de fiere bestimming en it krekte adrespairs dat it IPsec-belied beskermet. Doch dat foardat jo in regel bewurkje, want de tuple lit sjen hokker klassifisearder of NAT-regel oerienkomme moatten hie.

Sykje dan de regel dy't eins oerienkaam, net dy't jo bedoelden. Op beide platfoarms wurdt NAT yn in folchoarder beoardiele, en in eardere regel kin winne foardat jo útsûndering besjoen wurdt. In útsûndering dy't der goed útsjocht mar ferliest fan in oare regel, jout it ferwachte pakket nea oan it beskermingsbelied. It symptoom is gelyk oan in ûntbrekkende útsûndering, dêrom moat de regelfolchoarder lêzen wurde foardat de konfiguraasje feroaret.

ASA identiteits-NAT is in regel, gjin omgong

Op 'e ASA is identiteits-NAT in NAT-regel wêrfan't it oersette adres gelyk is oan it oarspronklike. Hy wurdt keazen as elke oare regel en ynstallearret noch altiten in oersettingsynfier, dus it pakket slacht NAT-ferwurking net oer. Wat feroaret is dat de adressen op 'e tried itselde bliuwe, en dat is wat it IPsec-belied nedich hat.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

De ynterfaces fan 'e regel en syn route-lookup-ynstelling moatte by it trochstjoerûntwerp passe. In regel dy't it adres korrekt mappet mar op it ferkearde ynterfacepear tapast wurdt, wurdt net foar jo stream keazen. Route-lookup beslút oft it oersette pakket rûte wurdt of oft de oarspronklike bestimming brûkt wurdt, en dat beslút oft weromferkear troch de tunnel weromkomt.

Behearstagonk ta de ASA sels is in apart gefal. As jo identiteits-NAT brûke foar behearsferkear, jildt de release-ôfhinklike route-lookup-eask, en in brede útsûndering kopyearre út in VPN-foarbyld reparearret SSH net.

In deny yn 'e IOS NAT-ACL betsjut hjir net keazen

Op IOS wurdt internet-NAT bestjoerd troch in boarnelist, en dy ACL is in klassifisearder, gjin filter. In permit-rigel kiest ferkear foar oersetting; in deny-rigel betsjut dat it pakket hjir net keazen wurdt. Dy deny is gjin opdracht om it pakket fuort te smiten lykas in deny yn in ynterface-ACL.

Net keazen hjir is ek smeller as nea earne oersette. In oare NAT-regel, in oar ynterface of in route-map kinne de stream noch oersette, dus de hiele NAT-tabel moat lêzen wurde. It pakket hat ek noch in rûte, in oerienkommende crypto-ACL en tastimming by de echte tagongsbeheargrinzen nedich.

In minimale IOS-opset set de deny boppe de permit yn deselde list en wiist de overload-regel nei dy list. Dan beskermet de crypto-ACL itselde pear dat de deny fan oersetting útslút.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Ien testbere fraach foar beide modellen

Beide modellen beantwurdzje deselde fraach: hokker regel kaam oerien mei dizze stream, en hokker adressen ferlieten it ynterface? Fang op it bûtenynterface en fergelykje it boarne-adres foar en nei de gateway. Kontrolearje dan de werjefte fan 'e partner oer de tunnel, want de SA kin oprjochte wêze wylst de beskerme stream earne oars oerset wurdt.

Op 'e ASA toanje nat detail en de oersettingstabel; op IOS toanje ip nat translations en de oerienkommende ACL-tellers. In regel dy't nea groeit waard nea keazen, en dat wiist op folchoarder, ynterface of rjochting yn stee fan op 'e crypto-konfiguraasje.

Wêr't de konfiguraasje meastal misgiet

De gewoane flaters binne meganysk. De deny stiet ûnder de permit en komt nea oerien. De klassifisearder wurdt yn 'e ferkearde rjochting tapast, sadat de weromstream oerset wurdt. De identiteitsregel beslacht de krekte adressen mar it ferkearde ynterfacepear. De crypto-ACL beskermet in subnet dat net mear oerienkomt mei wat de NAT-regel oanbiedt.

Skriuw it oarspronklike en oanbeane adrespairs njonken de regeleigner, sadat de folgjende yngenieur sjen kin wêrom't in klassifisearder oersetting wegeret wylst de firewall de applikaasje tastiet. Hâld dat yn 'e feroaringskaart, net yn in persoanlike notysje. Rin dan de stream opnij nei elke NAT-feroaring, want de regelfolchoarder is diel fan 'e konfiguraasje sels as de tekst fan 'e regel net feroare is. In tunnel dy't omheech komt is gjin bewiis dat de adressen oerlibbe hawwe; allinnich it fongen pakket en de dekapsulearre werjefte fan 'e partner binne dat.