Разширяване на сайтов 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 към старото местоназначение доказва, че промяната не е счупила това, което вече е работело. Запишете адреса на източника, който приложението логва, защото правилата му за достъп и всеки обратен маршрут трябва да съвпадат с тази стойност. Където клонът транслира преди тунела, адресът в политиката и адресът, който приложението вижда, се различават по замисъл, затова запишете и двата. Повторете теста след смяна на ключ или промяна в маршрутизирането, тъй като тези пътища обикновено се валидират веднъж и после се забравят.

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