Get-NetRoute – tablica routingu

Get-NetRoute to polecenie PowerShell wyświetlające tablicę routingu systemu — odpowiednik starszego polecenia route print.

Get-NetRoute jako tablica routingu systemu Windows

Get-NetRoute jest poleceniem PowerShell służącym do odczytywania informacji o trasach zapisanych w systemie Windows. Wynik pokazuje, w jaki sposób komputer podejmuje decyzję o przekazaniu pakietu do określonej sieci. Dzięki temu można sprawdzić, przez który interfejs ma zostać wysłany ruch, jaki adres bramy zostanie wykorzystany oraz z jakim priorytetem dana trasa jest brana pod uwagę. Tablica routingu nie jest zwykłą listą podłączonych urządzeń. Opisuje reguły wyboru drogi dla różnych adresów docelowych.

W praktyce Get-NetRoute pełni podobną funkcję diagnostyczną jak starsze polecenie route print, ale prezentuje dane w sposób lepiej dopasowany do nowoczesnych narzędzi PowerShell. Informacje są zwracane jako obiekty, dlatego można je filtrować, sortować i łączyć z innymi poleceniami. Ułatwia to zarówno jednorazowe sprawdzenie konfiguracji, jak i przygotowanie powtarzalnej diagnostyki. Polecenie może być przydatne przy analizie połączenia przewodowego, bezprzewodowego, tunelu VPN oraz sytuacji, w której komputer ma więcej niż jeden aktywny interfejs.

Najważniejszym elementem wyniku jest kierunek trasy, czyli sieć docelowa zapisana za pomocą adresu prefiksu i długości maski. Trasa dla konkretnego hosta może mieć długość maski 32 w przypadku IPv4 albo 128 w przypadku IPv6. Trasa obejmująca większy zakres adresów ma krótszy prefiks. Widać również interfejs, przez który odbywa się komunikacja, adres następnego punktu przekazania oraz metrykę. Te pola razem wyjaśniają, dlaczego pakiet może być kierowany inną drogą, niż sugerowałoby samo podłączenie kabla lub połączenie z siecią bezprzewodową.

Get-NetRoute i porównanie tras IPv4 oraz IPv6

Tablica routingu może zawierać jednocześnie wpisy IPv4 i IPv6. Rozdzielenie tych rodzin adresów jest ważne, ponieważ dostępność jednej z nich nie oznacza prawidłowego działania drugiej. Przy analizie IPv4 spotyka się adresy zapisane w postaci czterech oktetów, natomiast IPv6 wykorzystuje dłuższy zapis szesnastkowy. Get-NetRoute pozwala odczytać oba rodzaje tras, a wybór rodziny można ograniczyć parametrem związanym z adresem. Takie zawężenie zmniejsza liczbę wyników i ułatwia skupienie się na rzeczywistym problemie.

W typowej konfiguracji znajduje się trasa lokalna, trasa rozgłoszeniowa lub odpowiednik używany przez daną rodzinę adresów, a także trasa domyślna. Trasa lokalna wskazuje adresy należące bezpośrednio do interfejsu. Trasa dla danej podsieci pozwala przekazywać ruch do urządzeń znajdujących się w tym samym segmencie. Trasa domyślna jest wykorzystywana wtedy, gdy nie znaleziono bardziej szczegółowego dopasowania. Zwykle prowadzi do bramy, która przekazuje pakiety poza bieżącą sieć.

Przy wyborze trasy w pierwszej kolejności znaczenie ma najbardziej szczegółowy prefiks. Jeżeli istnieje wpis dokładnie pasujący do adresu docelowego, zostanie wybrany przed trasą obejmującą szerszy zakres. Gdy kilka tras ma ten sam poziom szczegółowości, znaczenie może mieć metryka oraz właściwości interfejsu. Z tego powodu dwa aktywne połączenia nie muszą działać równoważnie. Jedno może obsługiwać ruch do określonej podsieci, a drugie pozostały ruch kierowany przez trasę domyślną.

Do szybkiego przeglądu można użyć polecenia Get-NetRoute. Przydatne bywa także zawężenie wyniku do trasy domyślnej za pomocą Get-NetRoute -DestinationPrefix "0.0.0.0/0". Dla IPv6 analogicznym punktem odniesienia jest prefiks ::/0. Sam wynik nie powinien być interpretowany bez uwzględnienia aktualnego stanu interfejsów. Pomocne jest porównanie go z poleceniami Get-NetIPConfiguration oraz Get-NetIPInterface, które pokazują adresację, bramy i stan poszczególnych połączeń.

Problemy widoczne w wynikach Get-NetRoute

Jednym z częstszych problemów jest brak prawidłowej trasy domyślnej. W takiej sytuacji dostęp do urządzeń w tej samej podsieci może działać, ale komunikacja z dalszymi adresami może być niemożliwa. W wyniku Get-NetRoute może być widoczna trasa lokalna, lecz brak wpisu prowadzącego do bramy. Taki obraz wskazuje na problem z automatycznym uzyskaniem konfiguracji, ręcznie ustawioną adresacją albo nieprawidłowym działaniem interfejsu.

Inny przypadek występuje wtedy, gdy trasa domyślna istnieje, ale wskazuje nieaktywny lub niewłaściwy interfejs. Może się to zdarzyć po zmianie sieci, instalacji oprogramowania VPN, ponownym podłączeniu adaptera albo pozostawieniu kilku aktywnych połączeń. Należy zwrócić uwagę na identyfikator interfejsu, stan połączenia oraz zgodność adresu bramy z podsiecią przypisaną do tego interfejsu. Sama obecność wpisu w tablicy routingu nie potwierdza jeszcze, że wybrana droga jest osiągalna.

Problemy mogą wynikać również z nieoczekiwanych tras bardziej szczegółowych. Wpis kierujący określony zakres do niewłaściwej bramy może powodować dostęp do części zasobów przy jednoczesnym braku dostępu do innych. Czasem objawem jest działanie stron internetowych przy niedostępności wybranej aplikacji, brak połączenia z konkretną podsiecią albo niestabilne działanie po uruchomieniu tunelu VPN. W takim przypadku trzeba porównać prefiksy, metryki i interfejsy zamiast ograniczać diagnostykę do testu odpowiedzi pojedynczego adresu.

Warto pamiętać, że odczytana trasa nie wyjaśnia wszystkich przyczyn problemów z komunikacją. Pakiet może zostać zatrzymany przez zaporę, usługę filtrującą, błędną konfigurację DNS albo urządzenie pośredniczące. Get-NetRoute pokazuje lokalną decyzję systemu dotyczącą drogi, ale nie potwierdza przejścia pakietu przez kolejne punkty. Z tego powodu wynik należy zestawić z testem osiągalności, sprawdzeniem rozwiązywania nazw i analizą konfiguracji interfejsu.

Wskazówki do pracy z Get-NetRoute

Najbezpieczniej rozpocząć od odczytu całej tablicy i odnotowania, które interfejsy są aktywne. Następnie można ograniczyć wynik do jednej rodziny adresów, jednego interfejsu albo wybranego prefiksu. W PowerShell przydatne są potoki, na przykład filtrowanie obiektów według właściwości DestinationPrefix, InterfaceAlias lub NextHop. Pozwala to szybciej wychwycić wpisy powiązane z konkretną siecią lub połączeniem.

Przykładowe polecenie Get-NetRoute | Sort-Object DestinationPrefix porządkuje wynik według prefiksu. Do wyświetlenia podstawowych kolumn można użyć konstrukcji Get-NetRoute | Select-Object DestinationPrefix, NextHop, RouteMetric, InterfaceAlias. Taki widok jest czytelniejszy podczas ręcznej analizy, ponieważ skupia uwagę na sieci docelowej, bramie, metryce i nazwie interfejsu. Przy większej liczbie wpisów warto zapisać wynik do pliku tekstowego lub tabelarycznego, aby porównać stan przed zmianą konfiguracji i po niej.

Nie powinno się usuwać ani zmieniać tras wyłącznie na podstawie ich nietypowego wyglądu. Część wpisów jest tworzona automatycznie przez system, aktywne interfejsy lub oprogramowanie obsługujące bezpieczne połączenia. Przed modyfikacją trzeba ustalić, do czego służy dana trasa, czy jest stała, oraz co spowodowało jej utworzenie. Warto również wykonać kopię informacji o bieżącej konfiguracji. Pozwala to wrócić do punktu odniesienia, gdy po zmianie wystąpi utrata łączności.

Jeżeli podejrzewa się konflikt tras, przydatne jest sprawdzenie adresu docelowego, który nie działa, a następnie wyszukanie wpisów obejmujących ten adres. Najbardziej szczegółowa zgodna trasa zwykle wyjaśnia wybór drogi. Dalsze testy powinny obejmować ping lub Test-NetConnection, sprawdzenie bramy oraz porównanie działania przy wyłączonym dodatkowym interfejsie. Takie podejście ogranicza ryzyko pochopnych zmian i pomaga oddzielić problem routingu od problemu zapory albo usługi sieciowej.

Kiedy zgłosić Get-NetRoute do serwisu

Do serwisu warto zgłosić się wtedy, gdy wynik Get-NetRoute jest niezrozumiały, trasy zmieniają się bez wyraźnej przyczyny albo po zmianie ustawień sieciowych nadal występują przerwy w komunikacji. Dotyczy to również sytuacji, w której połączenie działa tylko przez jeden interfejs, wybrane zasoby są niedostępne mimo prawidłowego adresu IP albo problem powraca po każdym ponownym uruchomieniu komputera. Przydatne będzie przekazanie opisu objawów, informacji o tym, czy dotyczy to IPv4, IPv6 czy obu rodzin, oraz fragmentu wyniku polecenia bez danych, których nie powinno się udostępniać.

Warszawskie Pogotowie Komputerowe 24/7 może przeanalizować konfigurację systemu, stan interfejsów i zależności między trasami a działaniem połączenia. Diagnostyka powinna obejmować nie tylko samą tablicę routingu, lecz także adresację, bramę, rozwiązywanie nazw, zaporę i wpływ dodatkowych programów sieciowych. Dzięki temu można ustalić, czy przyczyną jest brak wpisu, niewłaściwy priorytet, niedziałający interfejs, błędna brama czy problem znajdujący się poza komputerem.

Przed przekazaniem sprzętu można przygotować wynik Get-NetRoute, Get-NetIPConfiguration oraz opis momentu, w którym pojawia się problem. Nie należy jednak samodzielnie usuwać tras, jeśli nie jest znane ich przeznaczenie. Prawidłowa interpretacja tablicy routingu pozwala szybciej odtworzyć przebieg komunikacji i dobrać dalsze czynności do konkretnego przypadku.