Розширення сайту 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 до старого призначення доводить, що зміна не зламала те, що вже працювало. Зафіксуйте адресу джерела, яку записує застосунок, бо його правила доступу та будь-який зворотний маршрут мають відповідати цьому значенню. Там, де філія виконує перетворення до тунелю, адреса з політики й адреса, яку бачить застосунок, різняться за задумом, тож запишіть обидві. Повторіть тест після оновлення ключа або зміни маршрутизації, бо такі шляхи зазвичай перевіряють один раз і потім забувають.

Призначте власника кожному з трьох сегментів і зворотному маршруту всередині мережі призначення. Шлях із чотирма власниками відмовляє в проміжках між ними.