Welke interface krijgt de NAT-rol binnen en buiten op een IOS VPN-uitgang

Routers die een volledige-tunnel-internetuitgang bieden, doen twee taken die er als één uitzien. Hij beëindigt de tunnel en stuurt het ontsleutelde clientpakket naar het internet. Alleen de tweede taak heeft vertaling nodig, en de vertaling moet bij de binnenste stroom passen. Dat onderscheid bepaalt welke interfaces de NAT-rollen dragen en welk adresbereik in de regel voorkomt.

Volg één pakket door de router

Neem een client op 10.90.0.25 die een openbare HTTPS-dienst opent. Of die bestemming überhaupt de tunnel in gaat, is een beleidsbeslissing van de client zelf. Zodra dat gebeurt, ontsleutelt de router het pakket en levert het af bij een virtuele interface, van waaruit het naar de openbare uplink wordt gerouteerd.

Die virtuele interface is de binnenkant van de vertaling. De openbare uplink is de buitenkant. Als de rollen omgekeerd of afwezig zijn, verlaat het pakket ofwel met een privébron het netwerk, ofwel wordt het weggegooid voordat het wordt vertaald.

Stem het vertaalbeleid af op de clientpool

De NAT-regel moet het bereik noemen dat de clients daadwerkelijk krijgen, niet het kantoor-LAN dat toevallig de uplink deelt. Een regel die alleen het lokale subnet dekt, mist externe clients, zelfs wanneer beide via dezelfde interface naar buiten gaan.

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 overload

Houd uitzonderingen voor privésites apart. Verkeer naar interne bestemmingen moet zijn oorspronkelijke bron behouden, anders antwoordt de bestemming naar een adres dat zij niet kan bereiken en faalt de retourweg op een manier die op een routeringslus lijkt.

Pas de rollen toe op de werkelijke interfaces in het uitgerolde ontwerp. Een Virtual-Template-fragment dat uit een oud Easy VPN-antwoord is gekopieerd, is geen volledige actuele configuratie, en het gebruikte tunneltype bepaalt welke interface het ontsleutelde pakket ontvangt.

Houd buitenste transport en binnenste vertaling gescheiden

Het vertalen van een ontsleutelde applicatiebron is niet dezelfde handeling als het duwen van IKE- of beschermde pakketten door een NAT-apparaat stroomopwaarts. Het eerste verandert wat het internet als bron van het clientverzoek ziet; het tweede houdt een tunnel in leven door een middlebox.

Ze door elkaar halen levert twee klassieke storingen op. Een router die zijn eigen tunneltransport vertaalt, breekt de peerverhouding, terwijl een router die de binnenste stroom nooit vertaalt, privéadressen naar het internet doorstuurt. Lees welke stroom je bekijkt voordat je een regel aanpast, en controleer of de tunnel na de wijziging in stand bleef. Een regel die browsen repareert maar de tunnel laat vallen, heeft het probleem verplaatst in plaats van opgelost.

Geen van beide storingen wordt opgelost door de andere te wijzigen. Lees welke stroom je bekijkt voordat je een regel aanpast.

Verifieer aan beide grenzen

Lees de applicatiebron aan de internetgrens, en de herstelde bestemming op de retourweg. Het eerste vertelt je of de vertaling gebeurde; het tweede vertelt je of de omgekeerde mapping bij de juiste client terugkwam.

Test vervolgens een client die een goedgekeurd split-tunnelpad gebruikt. Die client gebruikt nooit de internetvertaling van deze router, dus zou hij zich anders moeten gedragen, en het verschil bevestigt welk pad het verkeer nam.

Als beide clients zich identiek gedragen, doet het split-tunnelbeleid niet wat het ontwerp zegt. Los dat op voordat je meer vertaalregels toevoegt, want een regel die voor een ongebruikt pad is geschreven, verbergt het echte probleem.