Dlaczego za tym samym routerem łączy się tylko jeden klient VPN

Dwa laptopy są w tej samej sieci domowej, a firmowy VPN akceptuje dokładnie jeden z nich. Drugi albo kończy na przekroczeniu czasu, albo czeka, aż pierwszy się rozłączy, i nikt między obiema próbami nie dotknął ustawienia klienta. Dane logowania są te same, które działały minutę temu, i to jest wskazówka, że uwierzytelnianie nie jest awarią. Ten wzorzec tworzą trzy mechanizmy, a dziennik samego serwera mówi, z którym masz do czynienia.

Przeczytaj dziennik bramy, zanim dotkniesz klienta

Zapis serwera o obu próbach odpowiada na pierwsze pytanie, i odpowiada na jeden z trzech sposobów. Jeśli druga próba nigdy nie pojawia się w tym dzienniku, pakiet nigdy nie dotarł do nasłuchującego procesu, a problem należy do routera domowego lub do ścieżki dostawcy. Jeśli dziennik notuje próbę i ją odrzuca, tunel dotarł, więc chodzi o tożsamość, licencję lub limit sesji, a nie o coś na kablu. Jeśli dziennik notuje udaną sesję, podczas gdy klient nadal zgłasza awarię, sprawdź ścieżkę powrotną albo to, czy dwa klienty nie dostają tego samego adresu tunelu.

Hotspot z telefonu tanio rozdziela te rodziny: uruchom drugiego klienta przez dane komórkowe, podczas gdy pierwszy pozostaje połączony. Sukces tam wskazuje na sieć domową, a ta sama awaria tam wskazuje na bramę, co zostawia router bez winy. Żaden wynik nie jest sam rozstrzygający, ale każdy usuwa połowę przestrzeni poszukiwań w jednej próbie.

Zapisz wynik, zanim cokolwiek zmienisz, bo trzy wyniki z dziennika prowadzą do trzech niepowiązanych napraw. Notatka, która nazywa, który z trzech widziałeś, jest warta więcej niż zrzut ekranu błędu klienta.

Co router robi z GRE i NAT-T

PPTP to klasyczny winowajca: kanał kontrolny to TCP 1723, a ścieżka danych to GRE, protokół IP 47. Wiele routerów konsumenckich ma pomocnika PPTP, który śledzi jedno połączenie kontrolne, więc drugi klient za tym samym NAT otwiera swój kanał kontrolny i potem nie dostaje żadnej ścieżki danych. Przekierowanie portu TCP o numerze 47 nic nie daje dla GRE, bo GRE to numer protokołu, a nie port.

L2TP po IPsec zachowuje się inaczej z założenia: IKE używa UDP 500, przechodzenie przez NAT przenosi chroniony ładunek na UDP 4500, a enkapsulacja istnieje właśnie po to, by kilka klientów za jednym adresem mogło dotrzeć do tej samej bramy. To założenie nie przeszkadza bramie ani pośredniczącemu pudełku narzucić limitu sesji na adres, a z kanapy obie awarie wyglądają identycznie. Własny protokół SoftEthera ma tę samą klasę problemu: router bez działającego przepuszczania wpuszcza pierwszego klienta z sieci lokalnej i odrzuca drugiego. Przetestuj przełącznik ALG lub przepuszczania routera w obu położeniach, bo pomocnik napisany dla starszego klienta może uszkodzić pakiety wysyłane przez obecnego.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Limity tożsamości, które wyglądają jak limity transportu

Router nie jest jedynym podejrzanym, a dziennik odróżnia go od alternatywy. Gdy serwer OpenVPN przypina wspólną nazwę do jednego adresu tunelu, oba urządzenia dostają ten adres, a bez duplicate-cn nowsza sesja wypycha starszą. Włączenie tej opcji zostawia oba połączone, ale zostawia je z jedną tożsamością, jednym certyfikatem i jedną decyzją o unieważnieniu, co jest gorsze, niż wygląda. Drugiego urządzenia nie da się wtedy nigdy unieważnić osobno, więc przełącznik wygody po cichu usuwa kontrolę, której możesz później potrzebować.

Czytaj dziennik serwera i plik stanu razem, bo jeden pokazuje decyzję uwierzytelnienia, a drugi kto jest teraz połączony. Dwa wpisy ze wspólną nazwą i jednym adresem wirtualnym potwierdzają kolizję tożsamości, a nie limit routera. Komercyjne bramy dodają własne limity, takie jak plan dopuszczający jedną sesję równocześnie, liczba licencji albo reguła dopuszczająca jedną sesję na adres publiczny, i żadne ustawienie routera tego nie zmienia.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Dopasuj naprawę do wpisu w dzienniku

Odrzucenie w dzienniku wymaga osobnych danych logowania dla każdego urządzenia, wyższego limitu od tego, kto prowadzi usługę, albo drugiego punktu końcowego bramy dla jednej maszyny. Jeśli żadna druga próba nigdy nie dociera do serwera, trwałą naprawą jest router, który przekazuje protokół i utrzymuje więcej niż jedną sesję, albo transport, który router obsługuje dobrze, na przykład jeden strumień TCP lub UDP. Wybór między nimi to decyzja o żywotności sprzętu, nie o ustawieniach klienta.

Nie kopiuj profilu działającego urządzenia na drugą maszynę i nie uznawaj sprawy za skończoną. To zamienia problem połączenia w problem kontroli dostępu, bo zgubionego laptopa nie da się już odróżnić od kopii wciąż używanej. Ukrywa też pierwotną usterkę, która wraca w chwili, gdy pojawia się trzecie urządzenie.

Weryfikacja dwóch żywych sesji

Połącz oba urządzenia jednocześnie, uruchom zamierzoną aplikację na każdym, potem połącz ponownie jedno z nich i powtórz. Druga ikona, która pojawia się na chwilę, niczego nie dowodzi w kwestii ruchu, a sesja, która spada po dziesięciu minutach, to inny błąd z innym właścicielem. Porównaj to, co serwer zgłasza na końcu, z tym, co widzieli użytkownicy, bo te dwa opisy często się nie zgadzają.

Jeśli obie sesje przetrwają i przenoszą ruch, poprawka się trzyma, a notatka napisana na początku staje się zapisem tego, co było nie tak. Jeśli przetrwa tylko jedna, wróć do pierwszego kroku i sprawdź, który z trzech wyników dziennika masz teraz, bo odpowiedź mogła się zmienić. Pomocnicy routera potrafią maskować problem, który wraca w innej sieci, a limit na adres idzie za użytkownikiem, nie za urządzeniem. Testowanie z drugiej sieci to najtańszy sposób, by dowiedzieć się, co z tego naprawdę naprawiłeś.