Dopasuj klienta VPN w Linuksie do protokołu starego urządzenia

Cztery rodziny protokołów obejmują prawie każde urządzenie, które wciąż stoi w szafie, a każda z nich zawodzi na Linuksie inaczej. Opublikowane porty i skonfigurowane propozycje drugiej strony decydują o pakiecie, a nie dystrybucja, którą akurat uruchamiasz. Zainstalowanie tego, co wspomina post na forum, a potem edytowanie, aż coś się połączy, to sposób, w jaki znika popołudnie. Przeczytaj urządzenie, zainstaluj jako drugie, zweryfikuj jako trzecie.

Zapisz, co publikuje druga strona

Zapisz protokół, porty i uwierzytelnianie, których oczekuje urządzenie, zanim otworzysz menedżer pakietów. Cztery rodziny obejmują większość starego sprzętu, a tabela poniżej to cała decyzja na jednym ekranie.

Instrukcja i własne reguły zapory urządzenia są bardziej wiarygodne niż nazwa protokołu na jego stronie logowania. Urządzenie reklamujące IPsec może mówić tylko IKEv1, a wydanie firmware, którego nikt nie zastosował, może być tym, co ostatecznie dodaje IKEv2. Potwierdź zarówno ścieżkę danych, jak i port konfiguracji, bo właśnie tam stary sprzęt i nowoczesne sieci się rozchodzą. Pomyłka na tym etapie oznacza debugowanie klienta pod funkcję, której druga strona nigdy nie miała.

PPTP: udowodnij GRE, zanim edytujesz pppd

PPTP na Linuksie to nie demon, który uruchamiasz, lecz wywołanie pppd, a parametry połączenia żyją w nazwanym pliku peer, który pppd czyta, gdy jest wywoływany. Dystrybucje wciąż go pakują, choć znane słabości protokołu czynią go nieodpowiednim do czegokolwiek wrażliwego, więc trzymaj go wyłącznie dla urządzenia, które nie oferuje niczego innego. Obserwuj GRE, gdy klient negocjuje, krótkim przechwyceniem zamiast domysłu. Awaria, która marnuje najwięcej czasu, to nie uwierzytelnianie, lecz brakująca ścieżka danych.

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

Jeśli konfiguracja się kończy, a łącze nigdy nie przenosi ruchu, podejrzewaj ścieżkę GRE, zanim dotkniesz poświadczeń. Grupy zabezpieczeń w chmurze wymagają jawnej reguły dla protokołu 47, a niektóre sieci blokują go całkowicie bez widocznego błędu. Testuj z sieci, której naprawdę będziesz używać, a nie z laboratorium, które pozwala na wszystko.

L2TP/IPsec: jedna dopasowana propozycja bije dziesięć prób

Czytaj dziennik demona, a nie okno dialogowe pulpitu, bo okno scala kilka różnych awarii w jeden komunikat. Błąd NO_PROPOSAL_CHOSEN należy do pierwszej fazy: klient zaproponował szyfrowanie, skrót lub grupę Diffie-Hellmana, których serwer nie zaakceptuje. Wypisz, co obsługuje urządzenie, i napisz jedną dopasowaną propozycję, bo losowe kombinacje zwykle dają ten sam błąd wolniej. Na pulpicie praktycznym klientem jest wtyczka NetworkManager L2TP z strongSwan lub Libreswan pod spodem.

Ciąg propozycji, który dla wtyczki pulpitu znaczy jedno, dla demona, któremu przekazuje pracę, może znaczyć co innego, więc zachowaj składnię odpowiednią dla edytowanej warstwy. Jeśli urządzenie wymaga też sekretu tunelu, to osobny etap od klucza IPsec. Potwierdź, o który z dwóch pyta interfejs, zanim cokolwiek w nim wpiszesz.

Agresywny IKEv1 z XAuth i przypadek portalu

Punkt końcowy w stylu FortiGate zwykle chce trybu agresywnego z XAuth i adresu w trybie skonfigurowanym, czego wtyczka graficzna może w ogóle nie udostępniać. Natywny demon sobie z tym radzi, a blok poniżej to kształt tej konfiguracji, nie pełny plik. Sprawdź aktualną dokumentację producenta pod kątem wartości propozycji.

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

Starsze wydania strongSwan używały xauth=client tam, gdzie wersja 5 używa leftauth2=xauth, więc skopiowany fragment może zawieść już na składni. Dla portalu TLS openconnect mówiący protokołem AnyConnect obsługuje Cisco i większość przemianowanych marek, i potrzebuje urządzenia TUN oraz uprawnień do jego skonfigurowania. Przekaż adres portalu dokładnie tak, jak pokazuje go przeglądarka, łącznie z każdą ścieżką, której oczekuje urządzenie, a potem sprawdź przypisany adres, zanim przetestujesz cokolwiek za nim. Wcześniejsze utworzenie interfejsu usuwa jedną klasę niespodzianek podczas konfiguracji.

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

Połącz, a następnie zweryfikuj w ustalonej kolejności

Uruchamiaj dokładnie jeden menedżer VPN naraz, bo profil NetworkManager i demon uruchomiony ręcznie będą walczyć o trasy i DNS. Wyłącz profil przed testowaniem połączenia ręcznego i potwierdź, że nie przetrwał żaden stary interfejs tunelu. Następnie weryfikuj w tej kolejności: adres tunelu, trasa do jedynego wewnętrznego hosta, którego potrzebujesz, rozwiązywanie nazw i wreszcie rzeczywiste żądanie. Zielona ikona dowodzi uwierzytelnienia i niczego więcej.

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

Jeśli któryś krok zawiedzie, zatrzymaj się tam zamiast testować następny, bo awaria DNS poniżej zerwanej trasy niczego cię nie nauczy. Zapisz kopię działającego profilu, zanim zaczniesz eksperymentować, bo usunięty plik połączenia łatwo zgubić i trudno odtworzyć. Trzymaj wartości propozycji w tej samej notatce co model urządzenia i wersję firmware, bo ta notatka to różnica między migracją a projektem archeologicznym, gdy skrzynka zostanie wymieniona.