Hvilken grænseflade får NAT-indersiden og NAT-ydersiden på en IOS VPN-udgang
Følg den dekrypterede klientpakke fra den virtuelle grænseflade til uplinket. Oversættelsen hører til den indre strøm, ikke til tunnelens ydre transport.
Routere, der leverer en internetudgang med fuld tunnel, udfører to opgaver, der ligner én. De afslutter tunnelen og videresender den dekrypterede klientpakke til internettet. Kun den anden opgave kræver oversættelse, og oversættelsen skal passe til den indre strøm. Den forskel afgør, hvilke grænseflader der bærer NAT-rollerne, og hvilket adresseområde der optræder i reglen.
Følg én pakke gennem routeren
Tag en klient på 10.90.0.25, der åbner en offentlig HTTPS-tjeneste. Om den destination overhovedet kommer ind i tunnelen, er klientens egen politikbeslutning. Når den gør, dekrypterer routeren pakken og leverer den til en virtuel grænseflade, hvorfra den rutes til det offentlige uplink.
Den virtuelle grænseflade er indersiden af oversættelsen. Det offentlige uplink er ydersiden. Hvis rollerne vendes om eller mangler, forlader pakken enten med en privat kilde eller droppes, før den oversættes.
| 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? |
Tilpas oversættelsespolitikken til klientpuljen
NAT-reglen skal navngive det område, klienterne faktisk får, ikke kontorets LAN, som tilfældigvis deler samme uplink. En regel, der kun dækker det lokale subnet, rammer ikke fjernklienterne, selv når begge forlader gennem samme grænseflade.
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 undtagelser for private steder adskilt. Trafik til interne destinationer skal bevare sin oprindelige kilde, ellers svarer destinationen til en adresse, den ikke kan nå, og returvejen fejler på en måde, der ligner en routingløkke.
Anvend rollerne på de faktiske grænseflader i det udrullede design. Et Virtual-Template-fragment kopieret fra et gammelt Easy VPN-svar er ikke en komplet aktuel konfiguration, og den anvendte tunneltype afgør, hvilken grænseflade der modtager den dekrypterede pakke.
Hold ydre transport og indre oversættelse adskilt
At oversætte en dekrypteret applikationskilde er ikke samme operation som at presse IKE eller beskyttede pakker gennem en NAT-enhed længere oppe. Det første ændrer, hvad internettet ser som kilden til klientens anmodning; det andet holder en tunnel i live gennem en mellemboks.
At forveksle dem giver to klassiske fejl. En router, der oversætter sin egen tunneltransport, bryder peer-forholdet, mens en router, der aldrig oversætter den indre strøm, videresender private adresser til internettet. Læs, hvilken strøm du ser på, før du redigerer en regel, og kontroller, om tunnelen blev oppe efter ændringen. En regel, der retter browsing, men dropper tunnelen, har flyttet problemet i stedet for at løse det.
Ingen af fejlene rettes ved at ændre den anden. Læs, hvilken strøm du ser på, før du redigerer en regel.
Verificer ved begge grænser
Læs applikationskilden ved internetgrænsen, og den gendannede destination på returvejen. Det første fortæller, om oversættelsen skete; det andet fortæller, om den omvendte mapping kom tilbage til den rigtige klient.
Test derefter en klient, der bruger en godkendt split-tunnel-sti. Den klient udnytter aldrig denne routers internetoversættelse, så den bør opføre sig anderledes, og forskellen bekræfter, hvilken sti trafikken tog.
Hvis begge klienter opfører sig ens, gør split-tunnel-politikken ikke, hvad designet siger. Ret det, før du tilføjer flere oversættelsesregler, for en regel skrevet til en sti, der ikke bruges, skjuler det egentlige problem.