Kuriai sąsajai tenka NAT vidinė, o kuriai – išorinė rolė IOS VPN išėjime
Stebėkite iššifruotą kliento paketą nuo virtualiosios sąsajos iki išėjimo linijos. Vertimas priklauso šiam vidiniam srautui, o ne išorinei tunelio transporto daliai.
Maršrutizatoriai, teikiantys viso tunelio interneto išėjimą, atlieka du darbus, kurie atrodo kaip vienas. Jis užbaigia tunelį ir persiunčia iššifruotą kliento paketą į internetą. Vertimo reikia tik antrajam darbui, ir vertimas turi atitikti vidinį srautą. Šis skirtumas lemia, kurios sąsajos turi NAT roles ir koks adresų diapazonas nurodomas taisyklėje.
Sekite vieną paketą per maršrutizatorių
Paimkite klientą, kurio adresas 10.90.0.25, atidarantį viešą HTTPS paslaugą. Ar šis tikslas apskritai patenka į tunelį, sprendžia paties kliento politika. Kai patenka, maršrutizatorius iššifruoja paketą ir perduoda jį virtualiajai sąsajai, iš kurios jis nukreipiamas į viešąją išėjimo liniją.
Ši virtualioji sąsaja yra vidinė vertimo pusė. Viešoji išėjimo linija yra išorinė pusė. Jei rolės sukeistos arba jų trūksta, paketas arba išvyksta su privačiu šaltiniu, arba atmetamas prieš jį išverčiant.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
Suderinkite vertimo politiką su klientų telkiniu
NAT taisyklėje turi būti nurodytas diapazonas, kurį klientai iš tikrųjų gauna, o ne biuro LAN, kuris atsitiktinai dalijasi išėjimo linija. Taisyklė, apimanti tik vietinį potinklį, nepastebi nuotolinių klientų, net kai abu išeina per tą pačią sąsają.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadPrivačių svetainių išimtis laikykite atskirai. Srautas į vidinius tikslus turi išlaikyti savo pirminį šaltinį, kitaip tikslas atsakys į adresą, kurio negali pasiekti, ir grįžtamoji dalis suges taip, kad atrodys kaip maršrutizavimo kilpa.
Taikykite roles tikrosioms diegto sprendimo sąsajoms. Virtual-Template fragmentas, nukopijuotas iš seno Easy VPN atsakymo, nėra išsami dabartinė konfigūracija, o naudojamas tunelio tipas lemia, kuri sąsaja priima iššifruotą paketą.
Laikykite išorinį transportą ir vidinį vertimą atskirai
Iššifruoto programos šaltinio vertimas nėra ta pati operacija kaip IKE ar apsaugotų paketų stūmimas per NAT įrenginį aukščiau. Pirmasis keičia tai, ką internetas mato kaip kliento užklausos šaltinį; antrasis palaiko tunelį per tarpinį įrenginį.
Sumaišius juos, gaunami du klasikiniai gedimai. Maršrutizatorius, verčiantis savo paties tunelio transportą, sugriauna lygiaverčių ryšį, o maršrutizatorius, niekada neverčiantis vidinio srauto, persiunčia privačius adresus į internetą. Prieš redaguodami taisyklę, perskaitykite, kurį srautą matote, ir patikrinkite, ar tunelis po pakeitimo liko veikti. Taisyklė, kuri sutaiso naršymą, bet numeta tunelį, problemą perkėlė, o ne išsprendė.
Nė vienas gedimas nepataisomas keičiant kitą. Prieš redaguodami taisyklę, perskaitykite, kurį srautą matote.
Patikrinkite ties abiem ribomis
Perskaitykite programos šaltinį interneto riboje ir atkurtą tikslą grįžtamojoje dalyje. Pirmasis parodo, ar vertimas įvyko; antrasis parodo, ar atvirkštinis susiejimas grįžo tinkamam klientui.
Tada išbandykite klientą, kuris naudoja patvirtintą padalinto tunelio kelią. Šis klientas niekada nepatiria šio maršrutizatoriaus interneto vertimo, todėl turėtų elgtis kitaip, ir skirtumas patvirtina, kokiu keliu ėjo srautas.
Jei abu klientai elgiasi vienodai, padalinto tunelio politika nedaro to, ką numato sprendimas. Sutvarkykite tai prieš pridėdami daugiau vertimo taisyklių, nes taisyklė, parašyta nenaudojamam keliui, slepia tikrąją problemą.