Публикуване на вътрешна услуга през VPN сайт към сайт на ASA

Публикуването на услуга, която живее зад VPN сайт към сайт, е една задача с пет точки на отказ и те се провалят във фиксиран ред. Тунелът се вдига, транслацията съвпада, клонът отговаря и отговорът се връща по същия път. Когато някое от тях е грешно, браузърът показва едно и също: връзка, която виси или се нулира. Работете списъка отгоре надолу и спрете на първата проверка, която се провали.

Проверка 1: тунелът защитава адреса на източника

Започнете от тунел, който вече пропуска трафик, после потвърдете, че адресът, който планирате да публикувате, е в защитения диапазон. На ASA този диапазон идва от крипто ACL или от маршрутите на VTI и трябва да покрива реалния адрес на източника, а не подмрежата, която клонът използва за управление. Селектор, който пропуска източника, ви дава тунел, който е вдигнат, и поток, който никога не влиза в него.

Потвърдете с броячите на тунела и таблицата с маршрути, преди да пипате транслацията. Ако източникът не е достъпен от хъба през тунела, нищо по-нататък в този списък не може да го поправи.

Спрете тук, ако защитеният диапазон и адресът на източника не съвпадат.

Проверка 2: решете какъв източник ще види клонът

Клонът вижда или оригиналния адрес на клиента, или транслатиран такъв, и този избор решава обратния път. Запазването на адреса на клиента изглежда по-чисто в логовете на източника, но тогава клонът трябва да изпраща отговорите за публични клиенти обратно през тунела; обичайният интернет маршрут по подразбиране ги праща в другата посока и връзката умира в една посока. Транслирането на източника към адрес, който клонът вече маршрутизира през тунела, премахва това изискване.

Транслацията също променя какво източникът може да логва и с какво могат да съвпадат правилата, базирани на източник. Ако приложението трябва да знае човека зад заявката, това място е в удостоверено обратно прокси, а не в решение за NAT.

Проверка 3: напишете транслацията спрямо реалните интерфейси

ASA оценява правилата за транслация по ред и съобщава кое е съвпаднало, така че двойката интерфейси в правилото не е козметична. Правило, написано за път отвън навътре, няма да съвпадне с поток, чиито вход и изход се различават от приетите.

Пътят, който изграждате, има четири звена и всичките четири трябва да съвпадат:

Приемете диапазоните в тази таблица като заместители. Важното е кортежът след транслация да е адрес, който клонът приема през тунела, и обратното съпоставяне да съществува в състоянието на NAT, за да се възстанови отговорът на изхода.

Проверка 4: ограничете правилото за достъп до публикувания порт

Публикувайте порта, не хоста. Правило, което разрешава източника на всяка услуга, превръща едно публикувано приложение в път към всичко, което източникът изпълнява, включително интерфейса за управление, който нарочно сте държали извън интернет. Разрешете публикувания порт от транслирания източник към източника и оставете административните услуги на техния път само през VPN.

Проверете реда на правилата едновременно. Широко разрешение, стоящо над конкретното ви правило, прави конкретното правило невидимо.

Проверка 5: проследете една заявка и отговора ѝ

Не започвайте с браузър, защото браузърът скрива кое звено се е провалило. Проследете потока на хъба и прочетете резултата, преди да промените нещо.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Проследяването показва коя транслация е съвпаднала, кое правило за достъп е разрешило или отказало потока и дали пакетът е бил маршрутизиран в тунела. Ако показва, че потокът излиза от интерфейс, който не очаквате, двойката интерфейси в правилото за NAT е грешна. Ако показва отказ, редът на правилата е грешен. Ако стига до тунела, но източникът никога не отговаря, проблемът е в обратния път на клона.

След това изпратете една реална заявка отвън и потвърдете, че отговорът се връща през същия тунел. Запишете публикувания запис, транслацията, защитената двойка адреси и обратния маршрут като запис за публикация.