Які інтэрфейс атрымлівае ўнутраную і знешнюю ролю NAT на выхадзе VPN у IOS
Прасочвайце расшыфраваны кліенцкі пакет ад віртуальнага інтэрфейса да знешняга канала. Пераўтварэнне належыць гэтаму ўнутранаму патоку, а не знешняму транспарту тунеля.
Маршрутызатары, якія даюць поўны тунельны выхад у інтэрнэт, выконваюць дзве задачы, што выглядаюць як адна. Ён завяршае тунель і перадае расшыфраваны кліенцкі пакет у інтэрнэт. Пераўтварэнне патрэбнае толькі другой задачы, і яно мусіць адпавядаць унутранаму патоку. Гэтае адрозненне вызначае, якія інтэрфейсы нясуць ролі NAT і які дыяпазон адрасоў з’яўляецца ў правіле.
Прасочваем адзін пакет праз маршрутызатар
Вазьміце кліента на 10.90.0.25, які адкрывае публічную службу HTTPS. Ці трапляе гэтая мэта ў тунель, вырашае палітыка самога кліента. Калі трапіла, маршрутызатар расшыфроўвае пакет і перадае яго на віртуальны інтэрфейс, адкуль той накіроўваецца ў публічны знешні канал.
Гэты віртуальны інтэрфейс — унутраны бок пераўтварэння. Публічны знешні канал — знешні бок. Калі ролі пераблытаныя або адсутнічаюць, пакет альбо выходзіць з прыватнай крыніцай, альбо адкідаецца да пераўтварэння.
| 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? |
Узгадніце палітыку пераўтварэння з пулам кліентаў
Правіла NAT павінна называць дыяпазон, які кліенты фактычна атрымліваюць, а не офісную LAN, якая выпадкова дзеліць той жа знешні канал. Правіла, што пакрывае толькі лакальную падсетку, прапускае аддаленых кліентаў, нават калі абодва выходзяць праз адзін інтэрфейс.
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Трымайце выключэнні для прыватных пляцовак асобна. Трафік да ўнутраных мэт мусіць захоўваць сваю першапачатковую крыніцу, інакш мэта адкажа на адрас, да якога не дастане, і зваротны шлях зваліцца так, што выглядае як пятля маршрутызацыі.
Прымяняйце ролі да фактычных інтэрфейсаў у разгорнутым дызайне. Фрагмент Virtual-Template, скапіраваны з старога адказу Easy VPN, не з’яўляецца поўнай бягучай канфігурацыяй, а тып тунеля вызначае, які інтэрфейс атрымае расшыфраваны пакет.
Раздзяляйце знешні транспарт і ўнутранае пераўтварэнне
Пераўтварэнне расшыфраванай крыніцы праграмы — не тая ж аперацыя, што прапусканне IKE або абароненых пакетаў праз прыладу NAT вышэй па плыні. Першае змяняе тое, што інтэрнэт бачыць як крыніцу запыту кліента; другое трымае тунель жывым праз прамежкавую прыладу.
Блытаніна паміж імі дае дзве класічныя адмовы. Маршрутызатар, які пераўтварае ўласны транспарт тунеля, ламае адносіны з партнёрам, а маршрутызатар, што ніколі не пераўтварае ўнутраны паток, перадае прыватныя адрасы ў інтэрнэт. Прачытайце, на які паток вы глядзіце, перш чым правіць правіла, і праверце, ці тунель застаўся ўзнятым пасля змены. Правіла, якое выпраўляе прагляд і пры гэтым скідвае тунель, перанесла праблему, а не вырашыла яе.
Ні адну з адмоваў не выправіць зменай другой. Прачытайце, на які паток вы глядзіце, перш чым правіць правіла.
Правярайце на абодвух межах
Чытайце крыніцу праграмы на мяжы інтэрнэту і адноўленую мэту на зваротным шляху. Першае кажа, ці адбылося пераўтварэнне; другое — ці вярнулася зваротнае супастаўленне да патрэбнага кліента.
Затым праверце кліента, які карыстаецца ўзгодненым шляхам раздзеленага тунеля. Гэты кліент ніколі не задзейнічае інтэрнэт-пераўтварэнне дадзенага маршрутызатара, таму паводзіны мусяць адрознівацца, і гэтае адрозненне пацвярджае, які шлях выбраў трафік.
Калі абодва кліенты паводзяць сябе аднолькава, палітыка раздзеленага тунеля не робіць таго, што сказана ў дызайне. Выпраўце гэта перад даданнем новых правілаў пераўтварэння, бо правіла, напісанае для нявыкарыстанага шляху, хавае сапраўдную праблему.