Проширење 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 до старог одредишта доказује да промена није покварила оно што је већ радило. Запишите изворну адресу коју апликација евидентира, јер њена правила приступа и свака повратна рута морају да одговарају тој вредности. Тамо где огранак преводи пре тунела, адреса из политике и адреса коју апликација види разликују се по дизајну, зато запишите обе. Поновите тест после обнављања кључа или промене рутирања, јер се ови путеви обично валидирају једном и затим забораве.

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