Routing nie działa z interfejsu przypisanego ręcznie

Routing niedziałający z interfejsu przypisanego ręcznie wskazuje na brak zdefiniowanej trasy domyślnej przy statycznej konfiguracji IP.

Routing nie działa z interfejsu przypisanego ręcznie – czym jest ten problem

Komunikat lub obserwacja określana jako „routing nie działa z interfejsu przypisanego ręcznie” opisuje sytuację, w której urządzenie ma ustawiony adres IP, maskę sieci oraz interfejs, lecz nie potrafi przekazać pakietów do sieci znajdującej się poza lokalnym segmentem. Samo przypisanie parametrów do karty sieciowej nie tworzy jeszcze pełnej ścieżki komunikacji. Potrzebna jest również informacja, dokąd kierować ruch przeznaczony dla innych podsieci oraz jaki następny punkt pośredni ma zostać wykorzystany.

W praktyce najczęściej chodzi o brak trasy domyślnej, błędny adres bramy albo niezgodność pomiędzy adresem interfejsu i maską. Komputer może wtedy odpowiadać na urządzenia znajdujące się w tej samej sieci lokalnej, ale nie otwiera stron, nie komunikuje się z siecią firmową lub nie uzyskuje dostępu do zasobów znajdujących się poza lokalnym zakresem adresów. Zdarza się również, że trasa jest obecna, lecz ma nieprawidłowy priorytet, wskazuje niewłaściwy interfejs albo została dodana tylko tymczasowo i zniknęła po ponownym uruchomieniu.

Ręczne ustawienie adresu IP bywa stosowane przy urządzeniach wymagających stałej lokalizacji w sieci, podczas testów, w systemach monitoringu, przy drukarkach sieciowych lub w odizolowanych stanowiskach roboczych. W takim układzie każdy parametr musi być spójny. Adres, maska, brama, tablica routingu i reguły zapory tworzą jeden mechanizm. Zmiana tylko jednego elementu może spowodować, że interfejs będzie widoczny lokalnie, ale routing przestanie działać.

Routing nie działa z interfejsu przypisanego ręcznie – kontekst techniczny i porównania

W konfiguracji automatycznej parametry sieciowe są zwykle przekazywane przez usługę DHCP. Oprócz adresu i maski może ona dostarczyć adres bramy, serwery DNS oraz dodatkowe informacje wpływające na komunikację. Przy konfiguracji ręcznej te dane nie pojawiają się samoczynnie. Wprowadzenie samego adresu IP nie jest odpowiednikiem kompletnej konfiguracji uzyskiwanej automatycznie.

Trasa domyślna można opisać jako regułę używaną wtedy, gdy tablica routingu nie zawiera bardziej szczegółowego wpisu dla danego celu. Jeżeli komputer chce połączyć się z urządzeniem w tej samej podsieci, może wysłać pakiet bezpośrednio, korzystając z rozpoznania adresu warstwy lokalnej. Jeżeli cel znajduje się poza tą podsiecią, potrzebna jest brama. Brak takiego wpisu powoduje, że system nie ma decyzji dotyczącej dalszej drogi pakietu.

Warto odróżnić brak routingu od problemu z DNS. Przy błędnym DNS adres internetowy może się nie tłumaczyć na adres liczbowy, ale połączenie z poprawnie znanym adresem może działać. Przy braku trasy domyślnej często nie działa również bezpośrednia komunikacja z adresem znajdującym się poza lokalną podsiecią. Inną sytuacją jest blokowanie ruchu przez zaporę. Wtedy trasa może być prawidłowa, lecz pakiety zostaną odrzucone przez regułę bezpieczeństwa.

Znaczenie ma także liczba interfejsów. Laptop lub komputer może mieć jednocześnie połączenie przewodowe, bezprzewodowe, tunel oraz dodatkowy interfejs wirtualny. Każdy z nich może otrzymać własny adres i własne trasy. System wybiera wpis według jego szczegółowości oraz priorytetu. Jeżeli dwie drogi konkurują ze sobą, ruch może być wysyłany przez interfejs, który nie ma dostępu do właściwej bramy. Wtedy problem wygląda jak awaria routingu, mimo że pojedyncze ustawienia wydają się poprawne.

Routing nie działa z interfejsu przypisanego ręcznie – typowe problemy

Najczęstszym błędem jest pozostawienie pustego pola bramy domyślnej. Interfejs otrzymuje wtedy adres i maskę, lecz nie ma wskazania urządzenia przekazującego ruch poza podsieć. Podobny skutek daje wpisanie bramy należącej do innego zakresu adresowego. Brama musi być osiągalna z używanego interfejsu, a jej adres powinien znajdować się w tej samej logicznej sieci lokalnej, zgodnie z zastosowaną maską.

Kolejną przyczyną jest nieprawidłowa maska. Zbyt szeroka maska może sprawić, że system uzna odległy adres za lokalny i spróbuje komunikować się z nim bez pośrednictwa bramy. Zbyt wąska maska może natomiast spowodować uznanie części lokalnych urządzeń za zewnętrzne. W obu przypadkach tablica routingu nie odpowiada rzeczywistej topologii.

Problem może wynikać również z ręcznie dodanej trasy zawierającej błędny interfejs, adres następnego skoku lub zbyt niski priorytet. Czasami wpis dotyczy wyłącznie jednego zakresu, podczas gdy oczekiwany jest dostęp do wielu sieci. W takim przypadku komunikacja z jednym zasobem może działać, a z pozostałymi pozostawać niedostępna. Należy wtedy sprawdzić, czy zastosowano trasę do konkretnej podsieci, czy trasę domyślną.

W środowisku z kilkoma kartami sieciowymi przyczyną może być konflikt tras. Jeden interfejs może prowadzić do sieci lokalnej, drugi do odseparowanego segmentu, a trzeci do tunelu. Jeżeli trasa domyślna jest przypisana do niewłaściwego połączenia, pakiety zostaną wysłane w kierunku, z którego nie nadejdzie odpowiedź. Prawidłowa diagnoza wymaga wtedy sprawdzenia, który interfejs jest aktywny, jaki adres ma brama oraz jaka reguła została wybrana dla konkretnego celu.

Nie należy pomijać warstwy fizycznej. Uszkodzony przewód, wyłączony port, niestabilne połączenie bezprzewodowe albo brak synchronizacji urządzenia dostępowego mogą wyglądać jak problem z trasą. Różnicę można ustalić przez sprawdzenie stanu interfejsu, adresu lokalnego oraz odpowiedzi bramy. Jeżeli brama nie odpowiada, dalsze testowanie routingu internetowego nie przyniesie miarodajnych wyników.

Routing nie działa z interfejsu przypisanego ręcznie – praktyczne wskazówki diagnostyczne

Diagnozę warto rozpocząć od zebrania pełnego obrazu konfiguracji. Należy zapisać adres IP, maskę, adres bramy, serwery DNS, nazwę interfejsu oraz informację, czy połączenie jest przewodowe, bezprzewodowe czy tunelowane. Następnie powinno się sprawdzić tablicę routingu i odszukać wpis wskazujący trasę domyślną. W systemach korzystających z zapisu prefiksowego jest ona często przedstawiana jako trasa obejmująca wszystkie adresy, ale sposób prezentacji zależy od systemu operacyjnego.

W pierwszym teście sprawdza się własny adres i komunikację z innym urządzeniem w tej samej podsieci. Następny krok obejmuje próbę połączenia z bramą. Jeżeli komunikacja lokalna działa, a brama nie odpowiada, należy skoncentrować się na masce, adresie bramy, stanie portu oraz konfiguracji urządzenia dostępowego. Jeżeli brama odpowiada, lecz nie działa dostęp do dalszych sieci, trzeba przeanalizować trasę domyślną, reguły zapory i odpowiedzi zwrotne.

Przydatne jest wykonanie testu śledzenia drogi do wybranego celu. Pierwszy zatrzymany punkt może wskazać, czy pakiet w ogóle opuszcza komputer. Brak pierwszego skoku zwykle kieruje uwagę na lokalną konfigurację lub filtr ruchu. Pojawienie się pierwszego skoku i zatrzymanie na kolejnych może oznaczać problem po stronie bramy albo dalszej infrastruktury. Wynik należy interpretować razem z tablicą routingu, ponieważ samo śledzenie drogi nie pokazuje wszystkich przyczyn odrzucenia pakietu.

Po każdej zmianie konfiguracji należy ponowić testy w tej samej kolejności. Dobrą praktyką jest wykonywanie kopii pierwotnych ustawień oraz zapisywanie wprowadzonych zmian. Trasa dodana tymczasowo może zniknąć po restarcie, a ustawienie interfejsu jako ręczne może zostać nadpisane przez narzędzie zarządzające siecią. W przypadku urządzeń korzystających z profili sieciowych należy sprawdzić, czy modyfikowany jest właściwy profil, a nie nieaktywny zapis.

Nie zaleca się zmieniania wielu parametrów jednocześnie. Przydatniejsze jest rozdzielenie problemu na etapy: dostęp do własnego interfejsu, dostęp do podsieci lokalnej, dostęp do bramy, przejście do dalszej sieci oraz rozwiązywanie nazw. Takie podejście ułatwia ustalenie, czy przyczyną jest brak trasy, zła maska, konflikt interfejsów, filtr bezpieczeństwa czy awaria urządzenia pośredniczącego.

Routing nie działa z interfejsu przypisanego ręcznie – kiedy zgłosić się do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy po sprawdzeniu adresu, maski i bramy problem powraca, tablica routingu zmienia się bez wyraźnej przyczyny albo komputer traci dostęp po wznowieniu pracy. Pomoc może być potrzebna również wtedy, gdy występuje kilka interfejsów, aktywny jest tunel, połączenie zależy od profilu sieciowego lub konieczne jest zachowanie ręcznej konfiguracji przy jednoczesnym dostępie do różnych podsieci.

Przed przekazaniem urządzenia warto przygotować opis objawów: kiedy pojawia się problem, czy działa komunikacja lokalna, czy odpowiada brama, jakie zmiany wykonano oraz czy inne urządzenia korzystają z tej samej sieci. Pomocne mogą być zrzuty tablicy routingu i wynik testu śledzenia drogi, o ile nie zawierają poufnych danych. Nie powinno się jednak ujawniać haseł ani kluczy dostępowych.

W Warszawie takie przypadki obsługuje Warszawskie Pogotowie Komputerowe 24/7, gdzie analizie może zostać poddana konfiguracja interfejsu, tablica routingu, działanie bramy oraz współpraca z zaporą. Przywrócenie komunikacji wymaga nie tylko dopisania trasy, lecz także potwierdzenia, że wybrana droga odpowiada rzeczywistemu układowi sieci i pozostanie aktywna po ponownym uruchomieniu.

Nie każdy brak dostępu oznacza awarię samego komputera. Czasem źródłem jest urządzenie sieciowe, błędna reguła dostępu, konflikt adresów albo zmiana po stronie dostawcy połączenia. Z tego powodu sprawdzenie powinno obejmować zarówno stację roboczą, jak i elementy znajdujące się na drodze pakietu. Dopiero porównanie konfiguracji oraz wyników testów pozwala rozstrzygnąć, czy problem dotyczy ręcznie przypisanego interfejsu, bramy domyślnej, routingu pośredniego czy filtrowania ruchu.