SoftEther SecureNAT: DHCP і NAT — два окремі рішення

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

Дві служби за одним прапорцем

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

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

Рішення 1: хто видає адресу

Якщо віртуальний DHCP увімкнено, клієнти мають отримувати оренду з налаштованого вами пулу, зі шлюзом у вигляді віртуального інтерфейсу хоста й тим резолвером, який ви вказали. Дивіться на оренду, а не на текст стану клієнта, бо «підключено» описує тунель, а не призначення адреси:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

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

Рішення 2: хто пересилає за віртуальний шлюз

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

Власний шлях хоста — це третя річ

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

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

Сімейства адрес заслуговують на окрему перевірку. Робочий приклад DHCP для IPv4 не доводить, що у вашій збірці є всі можливості IPv6, тож прочитайте посібник для тієї версії, яку ви справді запускаєте, перш ніж обіцяти поведінку подвійного стека. Розділ SecureNAT у посібнику описує функції віртуального NAT і DHCP для поточного випуску.

Перевіряйте кожне рішення його власним тестом

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

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

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