Hvilket grensesnitt får NAT på innsiden og utsiden på en IOS VPN-utgang
Følg den dekrypterte klientpakken fra det virtuelle grensesnittet til oppstrømslenken. Oversettelsen hører hjemme i denne indre strømmen, ikke i tunnelens ytre transport.
Rutere som gir en internettutgang med full tunnel, gjør to jobber som ser ut som én. Den avslutter tunnelen og videresender den dekrypterte klientpakken ut til internett. Bare den andre jobben trenger oversettelse, og oversettelsen må passe til den indre strømmen. Den forskjellen avgjør hvilke grensesnitt som bærer NAT-rollene, og hvilket adresseområde som vises i regelen.
Følg én pakke gjennom ruteren
Ta en klient på 10.90.0.25 som åpner en offentlig HTTPS-tjeneste. Om destinasjonen i det hele tatt går inn i tunnelen, er klientens egen policybeslutning. Når den gjør det, dekrypterer ruteren pakken og leverer den til et virtuelt grensesnitt, der den rutes videre til den offentlige oppstrømslenken.
Det virtuelle grensesnittet er innsiden av oversettelsen. Den offentlige oppstrømslenken er utsiden. Hvis rollene er snudd eller mangler, forlater pakken enten med en privat kilde eller blir droppet før den oversettes.
| 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 oversettelsespolicyen til klientpoolen
NAT-regelen må navngi området klientene faktisk får, ikke kontor-LAN-et som tilfeldigvis deler oppstrømslenken. En regel som bare dekker det lokale subnettet, overser eksterne klienter selv når begge går ut gjennom samme grensesnitt.
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 overloadHold unntak for private nettsteder atskilt. Trafikk til interne destinasjoner må beholde sin opprinnelige kilde, ellers svarer destinasjonen til en adresse den ikke kan nå, og returveien feiler på en måte som ligner en rutingsløyfe.
Bruk rollene på de faktiske grensesnittene i den utrullede utformingen. Et Virtual-Template-fragment kopiert fra et gammelt Easy VPN-svar er ikke en fullstendig gjeldende konfigurasjon, og tunneltypen som brukes, avgjør hvilket grensesnitt som mottar den dekrypterte pakken.
Hold ytre transport og indre oversettelse atskilt
Å oversette en dekryptert applikasjonskilde er ikke samme operasjon som å presse IKE- eller beskyttede pakker gjennom en NAT-enhet oppstrøms. Den første endrer hva internett ser som kilden til klientens forespørsel; den andre holder en tunnel i live gjennom en mellomkasse.
Å blande dem gir to klassiske feil. En ruter som oversetter sin egen tunneltransport, bryter peer-forholdet, mens en ruter som aldri oversetter den indre strømmen, videresender private adresser til internett. Les hvilken strøm du ser på før du redigerer en regel, og sjekk om tunnelen holdt seg oppe etter endringen. En regel som fikser nettlesingen mens den feller tunnelen, har flyttet problemet i stedet for å løse det.
Ingen av feilene rettes ved å endre den andre. Les hvilken strøm du ser på før du redigerer en regel.
Verifiser ved begge grenser
Les applikasjonskilden ved internettgrensen, og den gjenopprettede destinasjonen på returveien. Den første forteller om oversettelsen skjedde; den andre forteller om den omvendte tilordningen kom tilbake til riktig klient.
Test deretter en klient som bruker en godkjent split-tunnel-sti. Den klienten bruker aldri denne ruterens internettoversettelse, så den bør oppføre seg annerledes, og forskjellen bekrefter hvilken sti trafikken tok.
Hvis begge klientene oppfører seg identisk, gjør split-tunnel-policyen ikke det utformingen sier. Fiks det før du legger til flere oversettelsesregler, fordi en regel skrevet for en sti som ikke er i bruk, skjuler det virkelige problemet.