VPN між майданчиками або віддалений доступ: що з’єднує кожен

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

Два рішення, дві межі

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

Візьміть 10.10.0.0/24 на одному майданчику і 10.20.0.0/24 на іншому. Шлюзу A потрібен маршрут або селектор трафіку, що надсилає префікс 10.20.0.0/24 у тунель, а шлюзу B потрібне його дзеркальне відображення. Потім хости з обох боків використовують звичайну IP-зв’язність і ніколи не дізнаються, що тунель існує. Ця невидимість і є функцією, і саме тому збої виглядають як звичайні мережеві помилки, а не як помилки тунелю.

На основі політики та на основі маршруту — це не той самий тунель

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

StrongSwan показує обидва подання напряму, і читати їх разом — це спосіб зрозуміти, яку модель ви насправді розгорнули.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

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

Сплануйте адресацію до тунелю

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

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

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

Пересилання і політика перебувають поза тунелем

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

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

Перевіряйте з хоста, а не зі шлюзу

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

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

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

Виберіть рішення за питанням, на яке відповідаєте: ви з’єднуєте мережі чи приймаєте пристрої? Усе інше, зокрема те, якого постачальника ви налаштовуєте, випливає з цієї відповіді.