Согласуйте VPN-клиент Linux с протоколом старого устройства
Прочитайте опубликованные порты устройства, затем установите подходящий клиент: pppd поверх GRE, strongSwan для IKEv1 XAuth или openconnect для портала.
Четыре семейства протоколов покрывают почти каждое устройство, ещё стоящее в стойке, и каждое из них на Linux отказывает по-своему. Опубликованные порты и настроенные предложения дальней стороны определяют ваш пакет, а не дистрибутив, который вы случайно запускаете. Поставить то, что упомянуто в посте на форуме, и потом править, пока что-нибудь не подключится, — так и пропадает полдня. Читайте устройство, устанавливайте вторым, проверяйте третьим.
Запишите, что публикует дальняя сторона
Запишите протокол, порты и аутентификацию, которых ждёт устройство, прежде чем открывать менеджер пакетов. Четыре семейства покрывают большую часть старого оборудования, а таблица ниже — всё решение на одном экране.
| Family | Ports | Linux side |
|---|---|---|
| PPTP | TCP 1723 plus GRE, IP protocol 47 | pppd with a peer file |
| L2TP/IPsec | UDP 500, 4500, 1701 | NetworkManager plugin over strongSwan |
| IKEv1 aggressive with XAuth | UDP 500 | native strongSwan connection |
| AnyConnect-style portal | TCP 443 | openconnect with a TUN device |
Руководство и собственные правила межсетевого экрана устройства надёжнее названия протокола на его странице входа. Устройство, рекламирующее 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 ниже сломанного маршрута ничему вас не научит. Сохраните копию работающего профиля, прежде чем экспериментировать, потому что удалённый файл подключения легко потерять и утомительно восстанавливать. Держите значения предложения в той же заметке, что и модель устройства с версией прошивки, потому что эта заметка — разница между миграцией и археологическим проектом, когда коробку заменят.