Kva grensesnitt får NAT på innsida og utsida på ein IOS VPN-utgang
Følg den dekrypterte klientpakka frå det virtuelle grensesnittet til oppstraumslenka. Omsetjinga høyrer til denne indre straumen, ikkje til den ytre transporten til tunnelen.
Rutarar som gjev ein internettutgang med full tunnel, gjer to jobbar som ser ut som éin. Han avsluttar tunnelen og sender den dekrypterte klientpakka ut til internett. Berre den andre jobben treng omsetjing, og omsetjinga må passe til den indre straumen. Den skilnaden avgjer kva grensesnitt som ber NAT-rollene, og kva adresseområde som viser seg i regelen.
Følg éi pakke gjennom rutaren
Ta ein klient på 10.90.0.25 som opnar ein offentleg HTTPS-teneste. Om destinasjonen i det heile går inn i tunnelen, er klienten sin eigen policyavgjerd. Når han gjer det, dekrypterer rutaren pakka og leverer henne til eit virtuelt grensesnitt, der ho blir ruta vidare til den offentlege oppstraumslenka.
Det virtuelle grensesnittet er innsida av omsetjinga. Den offentlege oppstraumslenka er utsida. Viss rollene er snudde eller manglar, forlèt pakka anten med ein privat kjelde eller blir sleppt før ho blir omsett.
| 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? |
Tilpass omsetjingspolicyen til klientpoolen
NAT-regelen må namngje området klientane faktisk får, ikkje kontor-LAN-et som tilfeldigvis deler oppstraumslenka. Ein regel som berre dekkjer det lokale subnettet, overser eksterne klientar sjølv når begge går ut gjennom same grensesnittet.
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 overloadHald unntak for private nettstader åtskilde. Trafikk til interne destinasjonar må behalde den opphavlege kjelda si, elles svarar destinasjonen til ei adresse han ikkje kan nå, og returvegen feilar på ein måte som liknar ei rutingsløyfe.
Bruk rollene på dei faktiske grensesnitta i den utrulla utforminga. Eit Virtual-Template-fragment kopiert frå eit gammalt Easy VPN-svar er ikkje ein fullstendig gjeldande konfigurasjon, og tunneltypen som blir brukt, avgjer kva grensesnitt som tek imot den dekrypterte pakka.
Hald ytre transport og indre omsetjing åtskilde
Å omsetje ei dekryptert applikasjonskjelde er ikkje same operasjonen som å presse IKE- eller verna pakker gjennom ei NAT-eining oppstraums. Den første endrar kva internett ser som kjelda til klienten sitt førespurnad; den andre held ein tunnel i live gjennom ei mellomkasse.
Å blande dei gir to klassiske feil. Ein ruter som omset sin eigen tunneltransport, bryt peer-tilhøvet, medan ein ruter som aldri omset den indre straumen, sender private adresser til internett. Les kva straum du ser på før du redigerer ein regel, og sjekk om tunnelen heldt seg oppe etter endringa. Ein regel som fiksar nettlesinga medan han fellar tunnelen, har flytta problemet i staden for å løyse det.
Ingen av feila blir retta ved å endre den andre. Les kva straum du ser på før du redigerer ein regel.
Stadfest ved begge grensene
Les applikasjonskjelda ved internettgrensa, og den gjenoppretta destinasjonen på returvegen. Den første fortel om omsetjinga skjedde; den andre fortel om den omvende tilordninga kom tilbake til rett klient.
Test deretter ein klient som brukar ein godkjend splitt-tunnel-sti. Den klienten brukar aldri internettomsetjinga til denne rutaren, så han bør oppføre seg annleis, og skilnaden stadfestar kva sti trafikken tok.
Viss begge klientane oppfører seg likt, gjer splitt-tunnel-policyen ikkje det utforminga seier. Fiks det før du legg til fleire omsetjingsreglar, fordi ein regel skriven for ein sti som ikkje er i bruk, skjuler det verkelege problemet.