ifconfig-noexec nie uratuje twojej sesji SSH: co naprawdę robi

W pewnym wątku na forum ifconfig-noexec oferuje się to jako poprawkę, która utrzymuje sesję SSH przy życiu, gdy podnosi się tunel. Rozumowanie brzmi przekonująco, dopóki nie sprawdzisz, czego ta opcja naprawdę dotyka. Powstrzymuje OpenVPN przed skonfigurowaniem adresu interfejsu tunelu i zamiast tego przekazuje te wartości skryptom; o tym, dokąd trafiają odpowiedzi do twojego połączenia zarządzającego, nie mówi nic. Wiara w coś przeciwnego daje tunel bez użytecznego adresu i sesję SSH, która i tak ginie.

Co ta opcja naprawdę deleguje

Domyślnie klient podnosi urządzenie tunelu i przypisuje adres lokalny oraz zdalny, które przekazał mu serwer. Gdy ifconfig-noexec jest ustawione, ten krok jest pomijany, a wynegocjowane wartości są eksportowane do środowiska skryptów, żeby coś innego mogło je zastosować.

Własność się przesuwa. W jej miejsce nic nie jest wymyślane.

Pytaniem, na które odpowiada ta opcja, jest więc to, kto konfiguruje interfejs, a pytaniem, na które nie odpowiada, jest to, jak pakiety znajdują drogę powrotną do ciebie. Trzymaj te dwie sprawy osobno, bo inaczej spędzisz cały wieczór na edytowaniu tras, żeby zrekompensować interfejs bez adresu.

Trzy podobne opcje o różnych zadaniach

Tę rodzinę łatwo pomylić, bo nazwy różnią się jednym słowem, a objawy się nakładają. Przeczytaj, co każda tłumi, zanim którąkolwiek wybierzesz.

To alternatywy do zrozumienia osobno, a nie zestaw do sklejenia razem. Tłumienie konfiguracji adresu nie tłumi zmian tras, reguł zapory ani wypychanych opcji, które niosą DNS. Delegowany skrypt też może swobodnie zmieniać trasy, a to decyzja, którą przekazujesz, a nie której unikasz.

Jeśli klient dostawcy opakowuje silnik, użyj jego obsługiwanej integracji, zamiast wrzucać dyrektywę niskiego poziomu do profilu i mieć nadzieję, że opakowanie ją uszanuje. Opakowania często regenerują profil przy połączeniu, więc ręczna zmiana znika bez błędu. Sprawdź, gdzie klient trzyma swoje ustawienia, zanim spędzisz wieczór nad plikiem. Dotyczy to każdego wiersza tabeli, nie tylko tego, po który przyszedłeś.

Sesja SSH, którą chciałeś chronić

Połączenie SSH ma adres źródłowy, adres docelowy i ścieżkę odpowiedzi. Na serwerze, który właśnie zainstalował domyślną trasę pełnego tunelu, odpowiedź na twój publiczny adres pasuje do tunelu, a brama VPN ją odrzuca.

Nic w konfiguracji adresu interfejsu tunelu tego nie zmienia.

Naprawia to bardziej szczegółowa trasa dla twojego adresu zarządzającego przez bramę sprzed tunelu lub reguła polityki, która kieruje ten ruch, plus ustawienia filtra stosowane przez twój host. Oba problemy czasem pojawiają się razem i dlatego jeden bywa brany za lekarstwo na drugi. Testuj je osobno: podnieś tunel bez opcji, spójrz na adres interfejsu i ścieżkę odpowiedzi, a potem zdecyduj, który z dwóch jest naprawdę zepsuty.

Co musi przejąć delegowany skrypt

Jeśli naprawdę chcesz, żeby inny właściciel skonfigurował interfejs, wylicz pracę: zastosuj adres lokalny i zdalny, podnieś urządzenie, przywróć lub usuń adresowanie przy rozłączeniu i zrób to samo jeszcze raz po ponownym połączeniu. Wartości z jednej udanej sesji nie mogą być zakodowane na stałe, bo serwer może następnym razem dać inną parę.

Zmienne środowiskowe eksportowane przez klienta to jedyne obsługiwane wejście dla tej pracy.

env | grep -E '^ifconfig_|^route_'

Wewnątrz skryptu route-up te zmienne są dostępne; z zadania cron lub ręcznej powłoki już nie. Potwierdź, którego haka cyklu życia używa twoja wersja, i potwierdź, że hak działa z wystarczającymi uprawnieniami do zmiany interfejsu, ponieważ klient mógł już zejść do nieuprzywilejowanego użytkownika.

Testuj cały cykl życia, nie jedną sesję

Podnieś tunel, sprawdź adres na urządzeniu, połącz się ponownie i sprawdź jeszcze raz. Konfiguracja, która działa raz i zawodzi przy drugiej próbie, zwykle oznacza, że delegowany krok uruchamia się tylko przy pierwszym połączeniu.

Następnie sprawdź oba kryteria akceptacji razem: nowe połączenie SSH przez zamierzoną ścieżkę zarządzania działa, a dozwolona aplikacja poprawnie korzysta z tunelu.

Stara sesja SSH, która przypadkiem przeżyje, gdy tunel nie ma adresu, nie jest sukcesem, i to jest dokładnie ten stan, który ta opcja tworzy, gdy nikt nie przejmie pracy. Najpierw sprawdź adres interfejsu, potem ścieżkę odpowiedzi zarządzania, a potem aplikację. Jeśli dwa z trzech są złe, opcja przeniosła pracę, ale nie dała jej właściciela.