Vilket gränssnitt får NAT på insidan och utsidan på en IOS VPN-utgång
Följ det dekrypterade klientpaketet från det virtuella gränssnittet till upplänken. Översättningen hör till detta inre flöde, inte till tunnelns yttre transport.
Routrar som tillhandahåller en internetutgång med full tunnel utför två jobb som ser ut som ett. Den avslutar tunneln och vidarebefordrar det dekrypterade klientpaketet ut till internet. Bara det andra jobbet behöver översättning, och översättningen måste matcha det inre flödet. Den skillnaden avgör vilka gränssnitt som bär NAT-rollerna och vilket adressområde som visas i regeln.
Följ ett paket genom routern
Ta en klient på 10.90.0.25 som öppnar en offentlig HTTPS-tjänst. Om destinationen ens går in i tunneln är klientens eget policybeslut. När den gör det dekrypterar routern paketet och levererar det till ett virtuellt gränssnitt, varifrån det routas till den offentliga upplänken.
Det virtuella gränssnittet är insidan av översättningen. Den offentliga upplänken är utsidan. Om rollerna är omvända eller saknas lämnar paketet antingen med en privat källa eller släpps innan det översätts.
| 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? |
Anpassa översättningspolicyn till klientpoolen
NAT-regeln måste ange det område klienterna faktiskt får, inte kontorets LAN som råkar dela upplänken. En regel som bara täcker det lokala subnätet missar fjärrklienter även när båda går ut genom samma gränssnitt.
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 overloadHåll undantag för privata webbplatser åtskilda. Trafik till interna destinationer måste behålla sin ursprungliga källa, annars svarar destinationen till en adress den inte kan nå och returvägen misslyckas på ett sätt som liknar en routingloop.
Tillämpa rollerna på de faktiska gränssnitten i den utrullade designen. Ett Virtual-Template-fragment kopierat från ett gammalt Easy VPN-svar är inte en fullständig aktuell konfiguration, och tunneltypen som används avgör vilket gränssnitt som tar emot det dekrypterade paketet.
Håll yttre transport och inre översättning åtskilda
Att översätta en dekrypterad applikationskälla är inte samma operation som att trycka IKE- eller skyddade paket genom en NAT-enhet uppströms. Den första ändrar vad internet ser som källan till klientens begäran; den andra håller en tunnel vid liv genom en mellanbox.
Att blanda ihop dem ger två klassiska fel. En router som översätter sin egen tunneltransport bryter peer-relationen, medan en router som aldrig översätter det inre flödet vidarebefordrar privata adresser till internet. Läs vilket flöde du tittar på innan du redigerar en regel och kontrollera om tunneln hölls uppe efter ändringen. En regel som fixar surfningen men fäller tunneln har flyttat problemet i stället för att lösa det.
Inget av felen åtgärdas genom att ändra det andra. Läs vilket flöde du tittar på innan du redigerar en regel.
Verifiera vid båda gränserna
Läs applikationskällan vid internetgränsen och den återställda destinationen på returvägen. Den första säger om översättningen skedde; den andra säger om den omvända mappningen kom tillbaka till rätt klient.
Testa sedan en klient som använder en godkänd split-tunnel-väg. Den klienten använder aldrig den här routerns internetöversättning, så den bör bete sig annorlunda, och skillnaden bekräftar vilken väg trafiken tog.
Om båda klienterna beter sig identiskt gör split-tunnel-policyn inte det designen säger. Åtgärda det innan du lägger till fler översättningsregler, eftersom en regel skriven för en väg som inte används döljer det verkliga problemet.