Проширување на VPN локација: следете ја повратната рута зад портата

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

Далечната порта е крајна точка на шифрирање

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

Нацртајте го патот во три дела: филијала до блиската порта, блиска до далечната, далечната порта до апликацијата. Секој дел има свој сопственик и свој начин на откажување.

Прочитајте ги двете насоки на политиката на тунелот

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

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

Додајте ја рутата напред и потврдете го пропуштањето

На далечната порта ѝ треба рута кон подмрежата на апликацијата, и секој рутер меѓу нив мора да го пропушти изворот на филијалата. Проверете што далечната порта навистина има, наместо што тврди дијаграмот.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

Тестирајте од филијалата, потоа повторно тестирајте го стариот пат

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

Доделете сопственик на секој од трите сегменти и на повратната рута внатре во мрежата на одредиштето. Пат со четири сопственици откажува во празнините меѓу нив.