Узгодьте VPN-клієнт Linux із протоколом старого пристрою

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

Запишіть, що публікує дальній бік

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

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

PPTP: доведіть GRE, перш ніж правити pppd

PPTP у Linux — це не демон, який ви запускаєте, а виклик pppd, і параметри з'єднання живуть у названому peer-файлі, який pppd читає, коли його викликають. Дистрибутиви досі його пакують, хоч відомі слабкості протоколу роблять його непридатним для чогось чутливого, тож тримайте його суворо для пристрою, який не пропонує нічого іншого. Стежте за GRE, поки клієнт веде переговори, коротким записом, а не здогадкою. Збій, що марнує найбільше часу, — не автентифікація, а відсутній шлях даних.

pppd call branch-office
tcpdump -ni any proto gre -c 5

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

L2TP/IPsec: одна відповідна пропозиція б'є десять спроб

Читайте журнал демона, а не діалог робочого столу, бо діалог зливає кілька різних збоїв в одне повідомлення. Помилка NO_PROPOSAL_CHOSEN належить до першої фази: клієнт запропонував шифрування, хеш або групу Diffie-Hellman, які сервер не прийме. Перелічіть, що підтримує пристрій, і напишіть одну відповідну пропозицію, бо випадкові комбінації зазвичай дають ту саму помилку повільніше. На робочому столі практичний клієнт — плагін NetworkManager L2TP із strongSwan або Libreswan під ним.

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

Агресивний IKEv1 з XAuth, і випадок порталу

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

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Старіші випуски strongSwan використовували xauth=client там, де версія 5 використовує leftauth2=xauth, тож скопійований фрагмент може відмовити вже на синтаксисі. Для порталу TLS openconnect, що говорить протоколом AnyConnect, дає раду з Cisco і більшістю перейменованих марок, і йому потрібні пристрій TUN та права на його налаштування. Передайте адресу порталу точно так, як її показує браузер, включно з будь-яким шляхом, якого очікує пристрій, а потім перевірте призначену адресу, перш ніж щось за нею тестувати. Заздалегідь створений інтерфейс прибирає один клас несподіванок під час налаштування.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

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

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

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

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