Watter koppelvlak kry NAT binne en buite op ’n IOS-VPN-uitgang

Roeteerders wat ’n voltonnel-internetuitgang bied, doen twee take wat soos een lyk. Dit beëindig die tonnel en stuur die ontsyferde kliëntpakket na die internet. Net die tweede taak het vertaling nodig, en die vertaling moet by die binneste vloei pas. Daardie onderskeid bepaal watter koppelvlakke die NAT-rolle dra en watter adresreeks in die reël verskyn.

Volg een pakket deur die roeteerder

Neem ’n kliënt by 10.90.0.25 wat ’n openbare HTTPS-diens oopmaak. Of daardie bestemming selfs in die tonnel beland, is die kliënt se eie beleidsbesluit. Sodra dit gebeur, ontsyfer die roeteerder die pakket en lewer dit aan ’n virtuele koppelvlak, van waar dit na die openbare opstroom gerouteer word.

Daardie virtuele koppelvlak is die binnekant van die vertaling. Die openbare opstroom is die buitekant. As die rolle omgekeer of ontbreek, verlaat die pakket óf met ’n private bron óf dit word laat vaar voordat dit vertaal word.

Pas die vertalingsbeleid by die kliëntpoel aan

Die NAT-reël moet die reeks noem wat die kliënte werklik ontvang, nie die kantoor-LAN wat toevallig dieselfde opstroom deel nie. ’n Reël wat net die plaaslike subnet dek, mis die afgeleë kliënte, selfs wanneer albei deur dieselfde koppelvlak uitgaan.

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

Hou uitsonderings vir private terreine apart. Verkeer na interne bestemmings moet sy oorspronklike bron behou, anders antwoord die bestemming na ’n adres wat dit nie kan bereik nie, en die terugpad misluk op ’n manier wat soos ’n routeringslus lyk.

Pas die rolle toe op die werklike koppelvlakke in die ontplooide ontwerp. ’n Virtual-Template-fragment wat uit ’n ou Easy VPN-antwoord gekopieer is, is nie ’n volledige huidige konfigurasie nie, en die tonneltipe wat gebruik word, bepaal watter koppelvlak die ontsyferde pakket ontvang.

Hou buitenste vervoer en binneste vertaling apart

Om ’n ontsyferde toepassingsbron te vertaal is nie dieselfde bewerking as om IKE- of beskermde pakkette deur ’n NAT-toestel stroomop te stuur nie. Die eerste verander wat die internet as die bron van die kliënt se versoek sien; die tweede hou ’n tonnel oor ’n middlebox heen aan die lewe.

Om hulle te verwar, lewer twee klassieke mislukkings. ’n Roeteerder wat sy eie tonnelvervoer vertaal, breek die eweknieverhouding, terwyl ’n roeteerder wat nooit die binneste vloei vertaal nie, private adresse na die internet stuur. Lees watter vloei jy voor jou het voordat jy ’n reël wysig, en kyk of die tonnel ná die verandering opgebly het. ’n Reël wat blaai regmaak terwyl dit die tonnel laat val, het die probleem verskuif eerder as opgelos.

Nie een van die mislukkings word reggemaak deur die ander een te verander nie. Lees watter vloei jy voor jou het voordat jy ’n reël wysig.

Verifieer by albei grense

Lees die toepassingsbron by die internetgrens, en die herstelde bestemming op die terugpad. Die eerste sê of vertaling plaasgevind het; die tweede sê of die omgekeerde kartering by die regte kliënt uitgekom het.

Toets dan ’n kliënt wat ’n goedgekeurde split-tonnel-pad gebruik. Daardie kliënt oefen nooit hierdie roeteerder se internetvertaling nie, so dit behoort anders op te tree, en die verskil bevestig watter pad die verkeer gevolg het.

As albei kliënte identies optree, doen die split-tonnel-beleid nie wat die ontwerp sê nie. Maak dit reg voordat jy meer vertalingsreëls byvoeg, want ’n reël wat vir ’n ongebruikte pad geskryf is, verberg die werklike probleem.