General failure podczas pingowania adresu LAN przy włączonym kliencie VPN

Jedna trasa do hosta, jeden adres, a ping od razu zawodzi z General failure zamiast kończyć się przekroczeniem czasu. Ta różnica to cała diagnoza. Przekroczenie czasu oznacza, że pakiet wyszedł i coś go zignorowało. General failure oznacza, że Windows w ogóle nie zdołał przekazać pakietu żadnemu interfejsowi.

Gdy więc tabela routingu wygląda idealnie, a błąd nadal brzmi General failure, blokada zachodzi poniżej decyzji routingu, a klient dostawcy jest tym, co tam działa.

Przeczytaj błąd przed tabelą routingu

Windows zwraca ten błąd, gdy nie znajdzie interfejsu do wysłania, i nic nie mówi o tym, co cel zrobiłby z pakietem. Osiągalność, zapory po drugiej stronie i dostępność usługi to wszystko późniejsze pytania, do których jeszcze nie dotarłeś.

Klasyczna konfiguracja w tym przypadku to trasa do hosta kierująca jeden adres LAN na bramę fizyczną, aby ominąć tunel. route add ją przyjmuje, route print ją pokazuje, a ping nadal zawodzi, bo sterownik filtra już zdecydował, że pakiet nie może wyjść.

Zanim zaakceptujesz to wyjaśnienie, potwierdź, że trasa jest rzeczywiście wybierana: sprawdź indeks interfejsu i metrykę oraz upewnij się, że wpis nie jest nieaktualny po ponownym połączeniu. Trasa wskazująca interfejs, którego już nie ma, daje podobny błąd z dużo mniej ciekawego powodu.

Trzy warstwy, trzech różnych właścicieli

Wygrywa ta warstwa, która działa ostatnia, a te trzy nie są w kolejności, której większość się spodziewa.

Warstwa środkowa jest powodem, dla którego trasa może być jednocześnie poprawna i bezużyteczna. Klienci dostawców instalują filtr i reguły zapory, aby ruch poza tunelem był odrzucany, i to ten sam mechanizm, który realizuje ich kill switch. Nic w tabeli routingu nie bierze udziału w tej decyzji.

Trzecia warstwa wyjaśnia dziwny raport, który pojawia się regularnie: lokalna podsieć jest nieosiągalna nawet po odłączeniu klienta. Usługa nadal działa, a filtr nadal jest zainstalowany, więc brak połączenia to nie to samo co brak filtrowania. Wyjdź z klienta, zamiast tylko go odłączać, zanim cokolwiek wywnioskujesz.

Czego próbować, po kolei

Zacznij od usunięcia funkcji, które są tanie do usunięcia i łatwe do przywrócenia. Wykrywanie sieci LAN, nazywane czasem niewidzialnością w sieci LAN, blokuje ruch do zakresów adresów prywatnych, aby maszyna pozostawała ukryta przed sąsiadami. Drukarki, lokalne serwery plików i sam router znikają za tym przełącznikiem. Funkcje ochrony przed zagrożeniami, które filtrują DNS, instalują własne haczyki i według doniesień psują lokalną osiągalność w podobny sposób.

Wyłącz obie, zamknij całkowicie klienta i dopiero wtedy przetestuj adres. Ta kolejność oddziela funkcję blokującą ruch od tunelu, który kieruje go źle, i zajmuje dwie minuty zamiast popołudnia ze statycznymi trasami.

ping 192.168.1.50
tracert -d 192.168.1.50
route print -4

Jeśli adres odpowie po wyłączeniu funkcji, masz decyzję polityki, a nie usterkę: wybierz między pozostawieniem funkcji wyłączonej, dodaniem wyjątku albo zaakceptowaniem, że maszyna pozostanie niewidoczna w sieci lokalnej.

Użyj wyjątku klienta, wąsko

Gdy funkcja musi pozostać włączona, obsługiwanym wyjściem jest własny tunel dzielony klienta. Utrzymuj wyjątek tak mały, jak pozwala wymóg, co zwykle oznacza jeden adres hosta dla jednego serwera lub jeden prefiks dla jednego segmentu. Reguła obejmująca cały zakres prywatny to trwała dziura, o której nikt nie przypomni sobie, że ją dodał, i której nikt nie odważy się usunąć.

Następnie sprawdź najpierw po adresie, a potem po nazwie. Jeśli adres odpowiada z pierwszym skokiem na bramie fizycznej, wyjątek działa. Jeśli nazwa nadal zawodzi, przeszedłeś do DNS, bo resolver tunelu nie zna strefy lokalnej i żadna zmiana routingu go tego nie nauczy.

Zachowaj trasę albo wyjątek, nie oba, plus notatkę o tym, który wykonuje pracę. Dwa nakładające się mechanizmy ukrywają się nawzajem, a następna osoba debugująca tę maszynę usunie jeden z nich i nie zobaczy żadnej zmiany.

Gdy klient jest przeszkodą

Niektóre kompilacje filtrują ruch w sposób, którego nie pokona ani trasa statyczna, ani wyjątek klienta. Gdy taki jest wniosek, uczciwe opcje to czekanie na funkcję obejścia albo połączenie zwykłym klientem OpenVPN z własnym profilem dostawcy, co zalecała odpowiedź wsparcia producenta w pierwotnym raporcie.

Zrozum kompromis, zanim dokonasz tego podstawienia. Zwykły profil zachowuje się jak każdy zwyczajny tunel: instaluje swoje trasy i nie przebudowuje reszty stosu, więc wąska trasa do hosta nadal zachowuje się tak, jak oczekujesz. Tracisz wszystko, co markowy klient zaimplementował wokół tunelu, w tym kill switch i filtrowanie DNS, i trzeba to świadomie odtworzyć albo zaakceptować jako nieobecne.

Cokolwiek wybierzesz, zapisz, która warstwa była właścicielem blokady. Pakiet, który nigdy nie opuścił maszyny, jest wynikiem filtra, a żadna zmiana routingu nie naprawi filtra.