Кой всъщност отговаря на отделения адрес на VPN?

Адрес, който стои неизползван в разпределението на организацията, не е слушател и добавянето му към защитна стена не създава такъв. Нещо трябва да прекратява IKE на този адрес, а механизмът се различава според това дали шлюзът притежава адреса, или устройство по-нагоре го преобразува. Пътят на пакета е това, което различава двата случая, и той определя коя функция на платформата ви е нужна, преди някой да отвори заявка за промяна. Моделирайте пътя първо, после избирайте.

Пътят на пакета зад адреса

Партньорът изпраща IKE към адреса, който му е даден, по UDP 500 или по UDP 4500, когато е в действие преминаване през NAT. Всяко устройство, което държи този адрес по пътя, или получава дейтаграмата локално и отговаря на нея, или я препраща другаде. Това са единствените две възможности и всичко останало в тази статия следва от това коя е вярна.

Локалното получаване означава, че на това устройство съществува сокет, свързан с този адрес. Препращането означава, че дейтаграмата се пренаписва и изпраща към друга крайна точка, която тогава има сокета. Правило в защитната стена, което разрешава UDP 500, не ви казва нищо за това кое от двете се случва.

Запишете протокола, преди да пипате нещо: адресът, с който партньорите се свързват, как мрежата по-нагоре го доставя, локалният интерфейс или логическата крайна точка, която го получава, и процесът, който отговаря на IKE. Четири реда и всеки един може да бъде проверен. Когато един от тях е неизвестен, това неизвестно е проектната работа, а не подробност по внедряването, която да се реши по-късно. Попълването им след одобрението на заявката за промяна е начинът, по който правило за преобразуване попада на грешното устройство.

Модел A: шлюзът притежава адреса

В първия модел шлюзът държи адреса сам, или като вторичен адрес на съществуващ интерфейс, или като адрес на отделен интерфейс, или като loopback, който платформата поддържа като крайна точка на тунел. Това са три различни функции с три различни пътя на конфигуриране и платформа, която поддържа едната, може да не поддържа другите.

Потвърдете, че платформата и изданието поддържат точно тази схема, преди да проектирате около нея. Маршрутизиран блок, допълнителен адрес на интерфейс и крайна точка loopback не са взаимозаменяеми и документацията за едно издание не обещава, че следващото се държи по същия начин.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Слушащият сокет е доказателството. Ако към адреса не е свързано нищо, шлюзът не е прекратяващата страна, независимо какво казва таблицата за маршрутизация, и прихващането на пакети ще покаже, че дейтаграмите пристигат, без никой да им отговаря.

Не поставяйте втори интерфейс в подмрежа, която вече съществува другаде в топологията, и не приемайте, че платформата ще се справи. Припокриващите се подмрежи на интерфейси дават двусмислен избор на източник и в много платформи — отказ да се конфигурират изобщо.

Модел B: устройство по-нагоре го преобразува

Във втория модел защитна стена по-нагоре държи отделния адрес и препраща трафика към друг VPN шлюз. Това е преобразуване на местоназначението с обратен път и е напълно валиден проект, стига да е документиран като такъв.

Това, което не е, е доказателство, че устройството по-нагоре е придобило локален VPN сокет. Преобразуването препраща пакети; то не прави горната кутия IKE отговарящ. Ако правилото по-нагоре се премахне или обратният му път се счупи, VPN спира, дори шлюзът да е здрав и собствените му слушатели непокътнати.

Запишете двата адреса: този, с който се свързват партньорите, и този, който шлюзът всъщност вижда. После запишете транспорта и обратния път, защото преобразуване, което работи за UDP 500, но не за инкапсулиран ESP, ще се свърже и след това ще не успее да носи трафик, което е объркващо за отстраняване по-късно.

Идентичността не е външният адрес

IPsec разделя крайната точка на тунела от трафика, който защитава, и архитектурата държи тези решения на различни места. Промяната на адреса, с който се свързват партньорите, не променя автоматично кои вътрешни префикси са разрешени, кои маршрути са инсталирани или до кои ресурси сесията може да достигне.

Удостоверената идентичност е отново отделна. IKEv2 носи полезен товар за идентичност и обмен за удостоверяване, които не е нужно да съвпадат с външния адрес на пакета и точно затова преобразуван проект все още може да се удостоверява правилно.

Тази независимост е полезна и също капан. Две DNS имена, които се разрешават към един обикновен слушател, не избират различни VPN бекендове и сертификат, който назовава една идентичност, няма да удовлетвори партньор, който очаква друга. Потвърдете какво валидира партньорът, преди да приемете, че само адресът го решава.

Приемете проекта, като наблюдавате една връзка

Проверете къде всъщност се доставя нова разрешена връзка, коя идентичност отговаря и кой частен поток след това е разрешен. Три наблюдения, три различни слоя, а успешното публично търсене на адреса не проверява нито едно от тях.

Запазете и отрицателния случай: партньор, който не бива да бъде приет, или вътрешен префикс, който не бива да бъде достижим, проверени след промяната. Протоколът, който написахте в началото, е това, което прави този тест възможен, без да възстановявате проекта по памет.

Смисълът на всичко това е да позволи на собственика на мрежата да избере поддържан метод за разпределение, вместо да разчита на общо твърдение за това какво може всяка защитна стена с допълнителен адрес. Точно това твърдение е мястото, където тези проекти се объркват, защото звучи правдоподобно на всяка платформа и в общия случай не е вярно на нито една. Протоколът от четири реда го решава за вашата платформа за десет минути.