Тунэльны маршрут па змаўчанні на Cisco ASA: калі ён сапраўды дзейнічае

Карыстальнік аддаленага доступу не можа дасягнуць нічога за ASA, хаця той жа сервер адказвае на ping з унутранай LAN. Тунэль ўзнімаецца, кліент атрымлівае адрас з пула, а пакет усё роўна выходзіць праз інтэрнэт-маршрут па змаўчанні або знікае. Такі ўзор звычайна азначае, што расшыфраваны трафік не знайшоў уласнага маршруту і праваліўся на звычайны маршрут па змаўчанні. Выпраўленне — не чарговае правіла NAT; гэта тунэльны маршрут па змаўчанні.

Пачніце з сімптому, а не з канфігурацыі

Глядзіце, куды ідзе пакет, а не куды вы чакалі, што ён пойдзе. Захоп на знешнім інтэрфейсе падчас няўдалай сесіі паказвае, што расшыфраваны пакет накіроўваецца да шлюза прайдара з нязменным адрасам пула, або не паказвае нічога, бо пошук не ўдаўся. У любым выпадку праблема не ў тунэлі.

Тунэль выглядае здаровым у show vpn-sessiondb, і менавіта таму людзі працягваюць адладжваць IKE.

Адрознівае гэта ад скіду ACL напрамак. Скід ACL лагуецца і лічыцца, а адсутны маршрут дае збой пошуку без адпаведнага запісу. Выканайце show route для прызначэння кліента і прачытайце, што ASA фактычна выбрала, у тым ліку ці быў выбраны маршрут па змаўчанні і які менавіта.

Чым адрозніваецца тунэльны пошук

Кіраўніцтва Cisco па статычнай маршрутызацыі ASA 9.23 апісвае асобны маршрут па змаўчанні для расшыфраванага трафіку VPN, які не мае статычнага або вывучанага маршруту. Ключавое слова tunneled пазначае гэты маршрут, таму расшыфраваны пакет можа апынуцца на іншым наступным хопе, чым той, які ASA выкарыстоўвае для ўласнага транспарту. Больш канкрэтныя маршруты ўсё яшчэ перамагаюць, і таму кліент можа дасягнуць 10.0.0.0/8 праз унутраны шлюз, страціўшы ўсё астатняе.

Мінімальная схема трымае два маршруты па змаўчанні з рознымі наступнымі хопамі. Адзін нясе ўласны трафік ASA, другі — расшыфраваны трафік, які не мае лепшага маршруту. Абодва наступныя хопы па-ранейшаму павінны быць дасягальныя з інтэрфейсу, да якога вы іх падключылі.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Калі абодва маршруты па змаўчанні паказваюць на адзін і той жа наступны хоп, ключавое слова нічога не змяняе і сімптом не зрушыцца.

Абмежаванні, якія вырашаюць, ці будзе гэта працаваць

Тое ж кіраўніцтва дазваляе толькі адзін тунэльны маршрут па змаўчанні і сцвярджае, што ECMP для яго не падтрымліваецца, таму размеркаваць навантажанне на гэты шлях нельга. Яно таксама пералічвае абмежаванні, звязаныя з адсочваннем маршрутаў, праверкай зваротнага шляху і некаторымі патокамі інспекцыі ды кіравання. Прачытайце іх адносна ўсталяванага ў вас выпуску, перш чым праектаваць вакол гэтай функцыі. Схема, якая іх ігнаруе, звычайна адмаўляе ў адным канкрэтным месцы, а не ўсюды, і таму сімптом выглядае перарывістым.

Праверка зваротнага шляху — гэта тое, што кусае ў асіметрычных схемах. Калі адказ прыйдзе праз іншы інтэрфейс, чым чакае ASA, пакет адкідваецца яшчэ да таго, як маршрутызацыя стане важнай. Папраўце тапалогію або зваротны шлях замест таго, каб адключаць праверку дзеля прымусу да наступнага хопа.

Адсочванне маршрутаў — асобная пастка: аб'ект адсочвання звычайна ахоўвае звычайны маршрут па змаўчанні, а не тунэльны.

Чаго ключавое слова не робіць

Яно не выбірае адрас крыніцы, які ASA выкарыстоўвае для пабудовы IKE. Знешні канец тунэля ідзе за ўласным выбарам інтэрфейсу і крыніцы платформы, і тунэльны маршрут па змаўчанні не ўдзельнічае у гэтым рашэнні. Яго змена не выправіць phase 1, які бярэ крыніцу з няправільнага адраса.

Яно таксама не робіць наступны хоп проксі. Калі прызначэнне чакае абмену HTTP CONNECT, адпраўка сырых IP-пакетаў на хост проксі дасць вам толькі хост, які іх не маршрутызуе. Наладзьце замест гэтага падтрыманы кліентам механізм проксі.

І яно не стварае перасылку ўніз па потоцы. Шлюз, на які вы паказваеце, па-ранейшаму мае патрэбу ў маршруце назад да пула VPN, а таксама ў трансляцыі крыніцы там, дзе гэта патрабуе схема.

Праверце шлях ад пачатку да канца

Пасля таго як маршрут на месцы, праверце чатыры рэчы па парадку: show route для прызначэння, патрэбнага пулу, захоп на інтэрфейсе ў кірунку новага наступнага хопа, захоп на самім шлюзе і зваротны шлях ад гэтага шлюза да адраса пула. Першыя два даказваюць, што ASA выбрала шлях, а апошнія два — што нехта на ім адказвае.

Калі шлюз адказвае, але кліент не бачыць адказу, паглядзьце на трансляцыю крыніцы і зваротны маршрут, перш чым зноў кранаць табліцу маршрутаў.

Запішыце выпуск, на якім вы правяралі, бо спіс абмежаванняў залежыць ад версіі, і схема, якая працуе на адной галіне, можа патрабаваць іншага шляху на другой. Гэтая нататка жыве даўжэй за фрагмент канфігурацыі.