Четири семейства протоколи покриват почти всяко устройство, което още стои в стойка, и всяко от тях се проваля по различен начин под Linux. Публикуваните портове и настроените предложения на отсрещната страна определят пакета ви, а не дистрибуцията, която случайно използвате. Да инсталирате каквото се споменава във форум и после да редактирате, докато нещо се свърже, е начинът, по който изчезва един следобед. Прочетете устройството, инсталирайте второ, проверете трето.

Запишете какво публикува отсрещната страна

Запишете протокола, портовете и удостоверяването, които устройството очаква, преди да отворите мениджър на пакети. Четири семейства покриват по-голямата част от старото оборудване, а таблицата по-долу е цялото решение на един екран.

FamilyPortsLinux side
PPTPTCP 1723 plus GRE, IP protocol 47pppd with a peer file
L2TP/IPsecUDP 500, 4500, 1701NetworkManager plugin over strongSwan
IKEv1 aggressive with XAuthUDP 500native strongSwan connection
AnyConnect-style portalTCP 443openconnect 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 след счупен маршрут не ви учи на нищо. Запазете копие на работещия профил, преди да експериментирате, защото изтрит файл на връзка лесно се губи и е досадно да се възстановява. Пазете стойностите на предложението в същата бележка като модела на устройството и версията на фърмуера, защото тази бележка е разликата между миграция и археологически проект, когато кутията бъде сменена.

Подобни статии