Split тунелот не го ослободува јавниот хост од NAT правилата на ASA

Split тунелирањето обично се опишува како начин да се задржи корпоративниот сообраќај внатре во тунелот, а остатокот од интернетот надвор од огнениот ѕид. Двете половини од тој опис се погрешни на ист начин. Split тунелирањето е одлука за рута што ја носи клиентот, а одлуката за рута не кажува ништо за тоа што се случува со пакетот откако ќе стигне до headend.

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

Мит: split тунелот го вади огнениот ѕид од патеката

Верувањето е дека секоја дестинација надвор од приватните опсези останува на локалната интернет врска, па огнениот ѕид никогаш не ја гледа и никогаш не му треба правило за неа. Тоа важи само додека дестинацијата не е во списокот на тунелот. Во моментот кога оператор додава јавен хост во ACL-от split-include, клиентот го испраќа тој сообраќај во тунелот, а ASA мора да го рутира, филтрира и преведе како секој друг дешифриран тек. На клиентот ништо не се променило освен списокот на дестинации.

Клиентот не стана рутер. Ја следеше политиката што му ја дадовте.

Што всушност прави split-include рутата

Во поставување за далечински пристап на Cisco ASA, групната политика носи split-tunnel-policy tunnelspecified и split-tunnel-network-list што именува стандарден ACL. Секоја permit линија во тој ACL е дестинација што клиентот треба да ја испрати во тунелот, а сето друго продолжува да ја користи локалната стандардна рута.

Додавањето на еден хост е една линија, и тоа е единствениот дел од промената што клиентот може да го види: access-list RA-SPLIT standard permit host 203.0.113.20.

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

Пакетот пристигнува и заминува на истиот интерфејс

Сега следете го текот по дешифрирањето. Пакетот влезе на надворешниот интерфејс преку VPN тунелот, неговата дестинација е јавна адреса, а табелата за рутирање го испраќа назад низ истиот надворешен интерфејс кон интернет. Сообраќајот што влегува и излегува на еден интерфејс се отфрла освен ако на ASA не му се дозволи, а токму тоа го прави same-security-traffic permit intra-interface. Без тоа врската паѓа на начин што изгледа како проблем со рутирањето, а не е.

Тоа поставување е глобално. Дозволува hairpinning за секој тек на кој му треба, не само за овој партнерски хост, затоа му припаѓа на прегледана промена, а не на брз тест.

Зошто PAT ограничен на дестинација не е изборен

Изворната адреса на дешифрираниот пакет уште е VPN адресата на клиентот, обично од базен како 10.77.0.0/24. Таа адреса нема рута на јавниот интернет, па партнерот или никогаш не одговара или одговара во ништо.

Преводот го поправа изворот и ја остава дестинацијата недопрена. Бидејќи објектите се веќе дефинирани на друго место, рачно правило ограничено на оваа дестинација го има овој облик:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Делот destination static е важен. Ако го изоставите, правилото станува широк превод што може да се совпадне со многу повеќе сообраќај отколку што е наменето, а широко identity правило порано во редоследот може целосно да го победи ова. Проверете show nat detail и редоследот на секциите пред да претпоставите дека вашето правило е она што се совпаѓа.

Интерфејсниот PAT исто така значи дека партнерот ја гледа интерфејсната адреса на ASA, која може повторно да се преведе возводно. Ако договорот именува адреса, потврдете ја од крај до крај, а не на еден хоп.

Докажете го со правилната тест дестинација

Користете го самиот партнерски хост, а не генеричка what-is-my-ip страница. Таа страница речиси сигурно е надвор од split списокот, па ја пријавува вашата локална интернет адреса и не кажува ништо за оваа патека. Отворете нова врска кон партнерската услуга и прашајте ги каков извор забележале, или извршете packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed и читајте ги фазите NAT и рутирање линија по линија. Traceroute од клиентот е послаба проверка, зашто го покажува патот што веќе се случил, а не политиката што го избрала.

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

Работечката верзија на овој дизајн е кратка: еден хост во split ACL, дозвола за hairpin, едно PAT правило ограничено на дестинација. Сето друго во приказната е митот.