Czy wspólny plik opcji pppd psuje inny VPN?

Dodajesz jedną linię, żeby uparty profil PPTP się połączył, a tydzień później klient L2TP, który działał od miesięcy, przestaje działać. Oczywiste odczytanie: oba protokoły zaczęły ze sobą kolidować. Częściej jednak oba klienty uruchamiają pppd, oba czytają te same wartości domyślne, a dodana linia nigdy nie została ograniczona do profilu, który naprawiałeś. Sprzężeniem jest wspólny plik opcji, a protokoły są niewinne.

Co klient dziedziczy przy starcie

Klient oparty na PPP rzadko buduje wiersz poleceń od zera. Uruchamia pppd, który czyta wartości domyślne systemu, potem plik użytkownika lub terminala, a następnie argumenty przekazane przez klienta; klient może też wskazać plik peer. Każda z tych warstw może nieść wtyczkę, metodę uwierzytelniania albo dyrektywę trasy, a pierwsza warstwa, która ustawi opcję chronioną, może zablokować ją przed późniejszymi zmianami.

Pożyteczne pytanie nie brzmi więc, który VPN jest zepsuty, lecz która warstwa dostarczyła to ustawienie. Klient generujący własne argumenty wygląda na samowystarczalny, a mimo to dziedziczy wszystko, co zawiera plik systemowy.

Ustal pochodzenie linii, zanim ją zmienisz

Zacznij od procesu działającego podczas aktywnego połączenia. Wiersz poleceń pokazuje, które pliki przekazano jawnie; wszystko, czego tam nie wymieniono, pochodzi ze ścieżki domyślnej.

ps -o pid=,args= -C pppd

Jeśli na liście argumentów jest nazwa peer, przeczytaj ten plik. Jeśli nie ma, szukane ustawienie mieszka we wspólnej ścieżce. podręcznik pppd wymienia kolejność czytania tych plików oraz opcje, których zwykły użytkownik nie może nadpisać; dlatego późniejsza linia czasem nie robi nic. Opcji chronionej, takiej jak ścieżka wtyczki, nie da się zastąpić późniejszą linią na poziomie użytkownika, więc edycja niewłaściwego pliku nie daje widocznego efektu.

Linia wtyczki, która idzie za każdym klientem

Wtyczka ładowana w pliku systemowym jest najgorszym przypadkiem, bo zmienia to, co próbuje załadować nowy proces PPP, niezależnie od tego, który przycisk nacisnął użytkownik. Wtyczka L2TP to klasyczny przykład: poprawna dla jednego profilu, bez znaczenia lub szkodliwa dla profilu PPTP startującego z tych samych wartości domyślnych.

Przenieś ją do pliku peer wybieranego przez klienta albo do ustawień pojedynczego połączenia w kliencie, jeśli je obsługuje. Zwykłe usunięcie naprawia drugi klient i psuje pierwszy — właśnie w ten sposób takie problemy wędrują między zespołami.

Sprawdź każdy klient po przeniesieniu

Przetestuj oba połączenia z tej samej maszyny, jedno po drugim, i czytaj wynegocjowane opcje, a nie okno sukcesu. Zrzut poniżej wypisuje zbiór opcji, który pppd faktycznie złożył, i tylko ta lista się liczy.

sudo pppd call office debug dump

Powtórz to dla drugiego klienta i porównaj oba wyniki. Przeniesiona opcja powinna pojawić się dokładnie w jednym z nich. Jeśli występuje w obu, klient generuje ją ponownie i poprawka należy do tego profilu, a nie do wspólnego pliku. Zapisz obok połączenia, gdzie teraz mieszka to ustawienie, żeby następna osoba nie odkrywała sprzężenia od nowa przez jego zepsucie.