Корисникот со далечински пристап не стигнува до ништо зад ASA, додека истиот сервер одговара на ping од внатрешниот LAN. Тунелот се подигнува, клиентот добива адреса од pool-от, а пакетот сепак излегува преку интернет стандардната рута или исчезнува. Оваа шема обично значи дека дешифрираниот сообраќај не нашол своја рута и паднал на обичната стандардна рута. Поправката не е уште едно NAT правило; поправката е tunneled стандардната рута.

Започнете од симптомот, не од конфигурацијата

Гледајте каде оди пакетот, а не каде очекувавте да оди. Снимање на надворешниот интерфејс за време на неуспешна сесија покажува дека дешифрираниот пакет оди кон ISP gateway со уште недопрена адреса од pool-от, или не покажува ништо зашто пребарувањето не успеало. Во двата случаи тунелот не е проблемот.

Тунелот изгледа здраво во show vpn-sessiondb, и токму затоа луѓето продолжуваат да го дебагираат IKE.

Од отфрлање од ACL ова го разликува насоката. Отфрлањето од ACL се логира и брои, додека рутата што недостасува создава неуспех при пребарување без соодветен запис. Пуштете show route за одредиштето на клиентот и прочитајте што ASA навистина избрал, вклучително дали била избрана стандардна рута и која.

Како се разликува tunneled пребарувањето

Cisco водичот за статично рутирање на ASA 9.23 документира посебна стандардна рута за дешифриран VPN сообраќај што нема статична или научена рута. Клучниот збор tunneled ја означува таа рута, така што дешифрираниот пакет може да падне на друг следен скок од оној што ASA го користи за сопствениот транспорт. Поточните рути сепак победуваат, затоа клиентот може да стигне до 10.0.0.0/8 преку внатрешниот gateway и да го изгуби сето останато.

Минималниот распоред држи две стандардни рути со различни следни скокови. Едната го носи сообраќајот на самата 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

Ако двете стандардни рути покажуваат на истиот следен скок, клучниот збор ништо не менува и симптомот нема да се помести.

Ограничувањата што одлучуваат дали ќе работи

Истиот водич дозволува само една tunneled стандардна рута и наведува дека ECMP не е поддржан за неа, така што не можете да го распределувате товарот по тој пат. Тој исто така наведува ограничувања што се однесуваат на следење рути, проверка на обратен пат и некои инспекциски и управувачки текови. Прочитајте ги во однос на инсталираната верзија пред да дизајнирате околу функцијата. Дизајнот што ги игнорира обично не успева на едно конкретно место, а не насекаде, и затоа симптомот изгледа повремен.

Проверката на обратен пат е онаа што каса во асиметрични дизајни. Ако одговорот пристигнува преку друг интерфејс од оној што ASA го очекува, пакетот се отфрла пред рутирањето воопшто да биде важно. Поправете ја топологијата или повратниот пат, наместо да ја исклучите проверката за да наметнете следен скок.

Следењето рути е посебна стапица: следениот објект обично ја чува обичната стандардна рута, а не tunneled рутата.

Што не прави клучниот збор

Тој не ја избира изворната адреса што ASA ја користи за градење на IKE. Надворешната крајна точка на тунелот следи сопствен избор на интерфејс и извор на платформата, а tunneled стандардната рута нема дел во таа одлука. Нејзината промена нема да поправи phase 1 што започнува од погрешна адреса.

Тој исто така не го претвора следниот скок во прокси. Ако одредиштето очекува размена HTTP CONNECT, испраќањето сирови IP пакети до прокси хост ви дава само хост што не ги рутира. Наместо тоа конфигурирајте го прокси механизмот што клиентот го поддржува.

И не создава понатамошно проследување. Gateway кон кој покажувате сепак има потреба од рута назад кон VPN pool, плус превод на изворот каде што дизајнот го бара тоа.

Проверете го патот од почеток до крај

Откако рутата е на место, проверете четири работи по ред: show route за одредиште што му е потребно на pool-от, снимање на интерфејсот кон новиот следен скок, снимање на самиот gateway и повратен пат од тој gateway до адресата од pool-от. Првите две докажуваат дека ASA го избрала патот, а последните две дека некој одговара на него.

Ако gateway одговара, но клиентот никогаш не гледа одговор, погледнете го преводот на изворот и повратната рута пред повторно да ја допрете табелата со рути.

Запишете ја верзијата на која сте провериле, бидејќи списокот ограничувања зависи од верзијата и дизајн што работи на една линија може да бара друг пат на друга. Таа белешка го надживува конфигурацискиот исечок.

Поврзани статии