Як спланувати пул адрес VPN-клієнтів, який підійде

Почніть із поля пулу на сервері VPN, а не з таблиці. Усе, що ви введете там, стане внутрішнім адресним простором для кожного клієнта, який підключиться потім, і воно має співіснувати з локальною мережею, до якої доходять ці клієнти, з маршрутизованими майданчиками за нею та з будь-якою адресою, яку клієнт уже має вдома. Підключіть одного клієнта одразу після збереження пулу, бо саме це перше підключення покаже, чи працює значення на практиці. Далі огляд рухається назовні: адреса, яку отримав клієнт, шлях, яким іде відповідь, і запис, який ви залишаєте по собі.

Почніть із поля пулу, перш ніж підключиться бодай один клієнт

Кожен продукт показує це по-своєму, тому знайдіть об'єкт, який справді видає адреси. У OpenVPN є серверна директива пулу, що видає наступну вільну адресу, у шлюзу IKEv2 є розділ пулу, прив'язаний до конфігурації партнера, а в WireGuard немає ні того, ні іншого, бо кожен партнер несе свою адресу у своєму файлі конфігурації. Директива пулу й адреса окремого партнера не взаємозамінні, а редагування не того витрачає решту огляду.

Отримавши поле, перелічіть діапазони, які вже існують: офісну локальну мережу, кожен маршрутизований майданчик, хмарний VPC і будь-який інший пул, що ще в роботі. Перетин визначається арифметикою префікса, а не тим, чи номери вузлів виглядають знайомо, тому порівняйте агрегат із кожним із цих діапазонів. Два діапазони, які обидва виглядають як 10.x, нешкідливі, коли їхні агрегати не перетинаються, і інцидент підтримки, коли перетинаються.

Далі вирішіть, чи є адреса функцією того, хто підключається, чи того, коли вони підключаються. Динамічне призначення видає те, що вільно, а призначення за ідентичністю прив'язує фіксовану адресу до облікових даних. Запишіть вибір, бо він змінює те, як має виглядати повторне підключення згодом.

Прочитайте адресу, яку клієнт справді отримав

Підключіть одного клієнта й читайте те, що повідомляє тунель, а не те, що обіцяв пул. Клієнт показує свою внутрішню адресу в стані підключення, а в Linux інтерфейс несе її напряму.

Порівняйте цю адресу зі збереженим діапазоном. Якщо вона поза діапазоном, ви дивитеся на інший шлях призначення, ніж той, що редагували. Перевірте й довжину префікса, бо клієнт із /32 не має партнера на каналі й надсилає кожне призначення через свій маршрут за замовчуванням.

ip -4 addr show tun0
ip route get 192.168.50.20

Клієнт, який підключається з домашнього роутера з тим самим діапазоном, підключиться і потім майже нічого не досягне. Клієнт зберігає свій локальний маршрут для цього префікса, тому адреса тунелю конфліктує з мережею за ним, і трафік виходить через неправильний інтерфейс. Цей випадок не можна виправити на сервері; задокументований засіб — перенумерувати домашню мережу або вибрати достатньо далекий діапазон пулу, щоб конфлікти лишалися рідкими. Запишіть і збій, і засіб, бо служба підтримки зустріне його знову.

Підключіть того самого клієнта знову й спостерігайте за адресою. Динамічний пул може повернути те саме значення або інше, і обидва правильні, тоді як пул за ідентичністю, що змінює адресу, не дотримує прив'язки. Ця перевірка займає секунди й вирішує, чи режим, записаний у першому розділі, є чинним режимом.

Простежте відповідь назад від служби

Пул працює лише тоді, коли відповіді можуть повертатися до нього. Служба в локальній мережі відповідає на внутрішню адресу, тому її шлюзу потрібен маршрут для пулу або трансляція перед службою. Коли запит приходить через тунель, а відповідь виходить іншим шляхом, міжмережевий екран з відстеженням стану або перевірка зворотного шляху відкидає її, і клієнт бачить службу, що підключається й потім зависає. Внесіть пул у проєкт маршрутизації як один зведений блок замість додавання маршрутів для кожного вузла.

Трансляція змінює те, що бачить решта системи. Коли джерело перезаписується, адреса в міжмережевому екрані вузла й у журналі застосунку — трансльована, тому правило, написане проти адреси пулу, ні з чим не збігається, а рядок журналу не можна простежити до клієнта. Документація strongSwan щодо переспрямування охоплює серверну половину цього шляху для шлюзу IKEv2. DNS несе те саме обмеження, бо ім'я, що розв'язується в адресу, недоступну клієнтові, зазнає невдачі пізніше й в іншому місці.

Два клієнти, потім один відклик

Підключіть двох клієнтів одночасно й прочитайте обидві адреси. Вони мають бути різними, придатними до використання й усередині пулу, і кожен має досягати служби, для якої призначений. Пул, що видає повторювані адреси, зазвичай виявляється тут, а не в першому тесті з одним клієнтом.

Відкличте одні облікові дані, поки інший клієнт лишається підключеним, потім спробуйте службу з уцілілого клієнта. Відклик, що порушує іншу сесію, вказує на спільний стан, найчастіше одні облікові дані або одну адресу, повторно використану між пристроями. Підключіть відкликаного клієнта знову й підтвердьте, що йому відмовляють, а не видають звільнену адресу.

Завершіть призначенням, яке має бути відхилене. Клієнт, що досягає всього, був підключений, а не перевірений.

Запишіть ці чотири значення там, де їх знайде наступна зміна

Запис короткий: діапазон і префікс пулу, режим призначення, зворотний шлях або трансляція в використанні та область DNS, що відповідає за ці призначення. Покладіть його поруч із конфігурацією сервера, а не в заявку, і поставте дату. Той, хто пізніше змінить одне з чотирьох, потребує інших трьох перед очима, бо зміна розміру пулу ламає маршрут, а зміна маршруту ламає відповідь DNS.

Тримайте при ньому нотатку про власність: діапазон тунелю належить серверу VPN, а резервування, зроблене в області DHCP локальної мережі, нічого не резервує для клієнта всередині тунелю. Цей один рядок запобігає найчастішій переробці, коли хтось додає резервування й чекає, що адреса тунелю піде за ним.