VPN nie aktualizuje metryk interfejsów

VPN nieaktualizujący metryk interfejsów sieciowych oznacza, że priorytet trasowania między kartą fizyczną a wirtualną kartą VPN pozostaje niezmieniony, co może kierować ruch przez niewłaściwy interfejs.

Na czym polega problem z aktualizacją metryk interfejsów VPN

Określenie „VPN nie aktualizuje metryk interfejsów” opisuje sytuację, w której system operacyjny nie przelicza albo nie stosuje oczekiwanych wartości określających pierwszeństwo poszczególnych połączeń sieciowych. Metryka jest jednym z parametrów wykorzystywanych przy wyborze drogi dla pakietów. Jeżeli komputer ma jednocześnie aktywne połączenie przewodowe lub bezprzewodowe oraz tunel VPN z własnym interfejsem wirtualnym, system porównuje dostępne trasy i przypisane im priorytety.

W prawidłowo działającym środowisku zmiana stanu połączenia VPN może spowodować pojawienie się nowych wpisów routingu, modyfikację ich kosztu albo przejęcie części ruchu przez interfejs tunelowy. Gdy metryka pozostaje stara, nie jest zapisywana lub jest ignorowana przez mechanizm wyboru trasy, pakiety mogą nadal korzystać z fizycznej karty sieciowej, mimo że aplikacja VPN sygnalizuje zestawienie tunelu. W innych przypadkach tylko wybrany zakres adresów trafia do VPN, natomiast pozostały ruch jest kierowany zwykłą drogą.

Nie musi to oznaczać całkowitego zerwania połączenia. Często występuje pozornie działający VPN, w którym dostęp do niektórych zasobów jest możliwy, lecz inne adresy są niedostępne, otwierają się z opóźnieniem albo odpowiadają z niewłaściwego segmentu sieci. Problem dotyczy zatem współpracy kilku elementów: tabeli routingu, wirtualnego adaptera, ustawień klienta VPN, protokołu tunelowania oraz reguł obowiązujących w systemie.

Znaczenie metryk, tras i interfejsów w praktyce

Metryka nie jest przepustowością łącza ani pomiarem jakości sygnału. Jest wartością używaną do porównywania tras prowadzących do tego samego celu lub do nakładających się zakresów adresowych. W uproszczeniu niższy koszt trasy może zostać uznany za korzystniejszy, jednak ostateczna decyzja zależy również od długości prefiksu, reguł routingu, tablic polityk oraz sposobu, w jaki dany klient VPN tworzy interfejs wirtualny.

W typowym komputerze może równolegle działać karta Ethernet, moduł Wi-Fi, wirtualny adapter VPN oraz dodatkowe interfejsy utworzone przez oprogramowanie zabezpieczające lub narzędzia do zdalnego dostępu. Każdy z nich może otrzymywać własne adresy, bramy i wpisy tras. Jeżeli klient VPN ustawia trasę tylko dla wybranych podsieci, korzysta się z tunelowania dzielonego. Jeżeli cały ruch ma przechodzić przez tunel, potrzebne są odpowiednie trasy domyślne i poprawna obsługa bramy po stronie wirtualnego interfejsu.

Nieaktualna metryka może być mylona z awarią serwera VPN, niedziałającym DNS-em albo problemem z autoryzacją. Weryfikacja wymaga więc porównania kilku stanów: konfiguracji przed połączeniem, parametrów po zestawieniu tunelu, tras do konkretnego adresu oraz zachowania po rozłączeniu. Istotne jest również ustalenie, czy modyfikacja odbywa się automatycznie, czy jest nadpisywana przez zasady grupowe, usługę sieciową, aktualizację sterownika albo kolejny program zarządzający adapterami.

W środowiskach, w których występuje więcej niż jedna aktywna ścieżka, sama zmiana metryki może nie wystarczyć. Trasa o bardziej szczegółowym zakresie może mieć pierwszeństwo przed trasą ogólną nawet wtedy, gdy jej koszt jest wyższy. Z tego powodu analizuje się nie tylko wartości liczbowe, lecz także maski, prefiksy, bramy, tablice routingu oraz reguły wyboru źródłowego adresu IP. Dopiero taki zestaw informacji pozwala ustalić, dlaczego pakiet opuszcza komputer przez konkretny interfejs.

Najczęstsze przyczyny i objawy nieprawidłowego działania

Jedną z przyczyn jest konflikt pomiędzy automatycznym ustawianiem metryk przez system a konfiguracją dostarczaną przez aplikację VPN. Po zestawieniu połączenia klient może utworzyć adapter i dodać trasy, ale system może zachować wcześniejsze wpisy albo ponownie nadać interfejsom własne wartości. Podobny efekt pojawia się po uśpieniu komputera, zmianie sieci bezprzewodowej, przełączeniu punktu dostępowego lub szybkim rozłączeniu i ponownym połączeniu tunelu.

Problemy mogą wynikać także z uszkodzonego lub niekompletnego sterownika wirtualnej karty. Objawami bywają znikające wpisy routingu, brak adresu na adapterze, opóźnione pojawienie się bramy albo pozostawione trasy po zakończeniu sesji. W takiej sytuacji ponowne uruchomienie klienta czasem przywraca działanie, lecz nie usuwa źródła problemu. Należy wtedy sprawdzić kolejność uruchamiania usług, wersję sterownika, stan urządzenia oraz logi klienta VPN.

Inny scenariusz dotyczy tunelowania dzielonego. Ruch do sieci firmowej może być kierowany przez VPN, natomiast zapytania DNS, połączenia do usług chmurowych lub adresy prywatne mogą nadal korzystać z lokalnej bramy. Jeżeli zakresy adresów nakładają się na siebie, wybranie trasy może być odmienne od oczekiwanego. Prowadzi to do dostępu do niewłaściwego urządzenia, komunikatu o przekroczeniu czasu oczekiwania albo pozornego braku Internetu.

Na działanie metryk wpływają również reguły zapory, oprogramowanie antywirusowe, narzędzia do filtrowania ruchu, wirtualne przełączniki oraz pozostałe aplikacje tworzące własne adaptery. Nie można wykluczyć błędnej konfiguracji po stronie koncentratora VPN, szczególnie gdy serwer przekazuje klientowi trasy lub parametry DNS. Warto odnotować moment wystąpienia problemu, typ sieci używanej przed połączeniem, zakres niedostępnych adresów oraz zachowanie po zmianie profilu VPN. Takie informacje pomagają odróżnić błąd lokalny od nieprawidłowości w infrastrukturze zdalnej.

Do typowych symptomów należą: dostęp do Internetu przy jednoczesnym braku dostępu do zasobów przez tunel, dostęp do zasobów VPN bez prawidłowego rozwiązywania nazw, różne wyniki połączenia przy użyciu Wi-Fi i Ethernetu, utrata łączności po wybudzeniu oraz konieczność ręcznego odświeżania adaptera. Sam test ping nie zawsze daje pełny obraz, ponieważ zapora może blokować odpowiedzi ICMP. W diagnostyce przydatne jest sprawdzenie rzeczywistej trasy do kilku adresów, test po nazwie i po adresie IP oraz porównanie wyników przed i po aktywacji VPN.

Kiedy potrzebna jest diagnostyka serwisowa - VPN nie aktualizuje metryk interfejsów

Zgłoszenie do serwisu ma sens, gdy połączenie VPN formalnie zostaje zestawione, lecz ruch nie płynie przez właściwy interfejs, problem powraca po każdym restarcie albo ręczne poprawki działają tylko do następnej zmiany sieci. Szczególnej uwagi wymaga sytuacja, w której zmiana metryki nie utrzymuje się, wpisy routingu znikają po kilku minutach lub system pokazuje kilka podobnych adapterów VPN. Wtedy analizuje się konfigurację systemu, sterowniki, kolejność usług, profile sieciowe i zależności pomiędzy trasami.

Przed przekazaniem urządzenia warto przygotować nazwę używanego klienta VPN, informację o wersji systemu, opis momentu wystąpienia usterki oraz przykłady adresów, które działają i nie działają. Pomocne bywają również zrzuty konfiguracji interfejsów i tabeli routingu, o ile nie zawierają haseł, kluczy ani innych danych uwierzytelniających. Nie powinno się udostępniać sekretów dostępowych w zgłoszeniu. Do sprawdzenia pozostaje między innymi to, czy problem jest związany z samym komputerem, konkretnym profilem VPN, lokalną siecią czy polityką narzuconą przez zdalną infrastrukturę.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić sprawdzenie komputera, na którym trasy VPN są wybierane niezgodnie z oczekiwaniem. W ramach diagnostyki ustala się, czy przyczyną jest metryka interfejsu, błędna trasa, konflikt adapterów, sterownik, DNS lub reguła filtrująca ruch, a następnie porządkuje się konfigurację w zakresie możliwym do wykonania na danym urządzeniu. Takie zgłoszenie jest szczególnie uzasadnione wtedy, gdy ręczne modyfikowanie tras nie daje trwałego rezultatu albo powoduje utratę dostępu do zwykłej sieci.