Маршрутизований клієнт VPN досягає сервера, але не хостів LAN

Маршрутизований клієнт може підключитися і все одно втрачати кожну відповідь від хоста LAN. Додайте зворотний маршрут на шлюзі, потім перевірте пересилання та фільтрацію пакетів.

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

Стежте за відповіддю, а не за запитом

Сервер VPN розшифровує пакет клієнта і пересилає його в LAN, залишаючи адресу клієнта в полі джерела. Хост призначення відповідає на цю адресу, і тепер усе вирішує його власна таблиця маршрутизації. Його шлюз за замовчуванням нічого не знає про пул тунелю, тому відповідь іде до інтернет-провайдера і десь на цьому шляху відкидається.

На клієнті симптом — тихий тайм-аут: ні відмови, ні скидання, просто нічого. Перегляд спільної теки зависає, ping повідомляє про відсутність відповіді, а журнали сервера виглядають здоровими, бо сервер зробив свою справу.

Розмістіть зворотний маршрут там, куди дивляться хости

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Чому NAT джерела виглядає як виправлення

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

Цей обмін іноді правильний, наприклад коли пристрою постачальника не можна дати статичний маршрут. Не робіть правило ширшим за поточний пул, бо правило, написане для /24, перестає збігатися того дня, коли пул перенумеровують у /16, і першою ознакою буде група нових клієнтів, які підключаються і нікуди не потрапляють.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Хмарний шлях потребує трьох налаштувань

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

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

Виконайте перевірки в цьому порядку

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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

Схожі статті