Trasa odrzucona z powodu bitów hosta? Znajdź zamierzony prefiks
Odrzucony wiersz trasy zwykle wynika z bitów hosta, a nie z problemu z przekazywaniem. Ustal zamierzony prefiks, zamiast poszerzać maskę, aż zostanie zaakceptowana.
Twój wiersz trasy wraca odrzucony, a znaleziona porada mówi, aby włączyć przekazywanie IP. Te dwie rzeczy są na różnych etapach problemu. Przekazywanie decyduje, czy host może przenosić pakiety między interfejsami; nie ma zdania o tym, czy wpisany cel jest prawidłową siecią. Najpierw popraw prefiks, bo przekazywanie nie uratuje adresu i maski, które się nie zgadzają.
Na co parser naprawdę się skarży
Cel zapisany jako adres plus maska musi opisywać sieć, a sieć zaczyna się od wyzerowanych bitów hosta. Gdy podany adres nadal niesie wartość w części hosta, para jest wewnętrznie niespójna: 172.20.130.0 wygląda schludnie, bo kończy się zerem, ale zero w czwartym oktecie nie jest jedyną ważną rzeczą. To trzeci oktet trzyma tutaj zbłąkane bity.
Narzędzia radzą sobie z tą niespójnością różnie. Ścisłe parsery odrzucają wiersz i nazywają bity hosta. Łagodne parsery maskują adres i instalują coś, o co nie prosiłeś, co jest gorsze, bo konfiguracja kieruje teraz zakres, którego nigdy nie zamierzałeś. Moduł ipaddress w Pythonie pokazuje wybór wprost: ścisłe parsowanie sieci zgłasza błąd, a strict=False maskuje bity hosta. Twój klient może być ścisły, łagodny lub niespójny między wersjami, więc czytaj komunikat, zamiast ufać nawykowi.
Przejdź przez przykład ręcznie
Weź tunel, który musi dotrzeć do 172.20.130.0 z maską /20. /20 pożycza cztery bity z trzeciego oktetu, więc ten oktet liczy się tylko krokami po 16: 0, 16, 32 i dalej aż do 240. Wartość 130 wypada między 128 a 143, co oznacza, że otaczająca sieć zaczyna się na 172.20.128.0, a nie na 172.20.130.0 z wyzerowanym ostatnim oktetem.
Wypisane, blok biegnie od 172.20.128.0 do 172.20.143.255 i zawiera 4,096 adresów. Podanie tych samych wartości niesformatowanemu parserowi pokazuje podstawienie, które wykonałby w twoim imieniu:
$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096Zdecyduj, który cel naprawdę miałeś na myśli
Odrzucony wiersz zwykle ukrywa jedną z trzech intencji, a wybrać możesz tylko ty. Jeśli tunel potrzebuje całego bloku, wpisz 172.20.128.0/20, kanoniczny adres sieci. Jeśli tunel potrzebuje tylko segmentu 130, maska była błędna i 172.20.130.0/24 jest uczciwą formą. Jeśli celem jest jedna maszyna, trasa do hosta IPv4 to /32 i nie ma w tym żadnej arytmetyki masek.
Każda z nich zezwala na inną ilość ruchu, i to jest prawdziwy powód, by nie poszerzać maski, dopóki skarga nie ustanie. /16 przyjmuje wiersz niemal wszędzie i wysyła ruch do celów, których nigdy nie chciałeś trasować przez tunel. Wpisz najwęższy prefiks zgodny z intencją, a potem potwierdź go względem oczekiwanego następnego skoku, a nie względem ciszy parsera.
Dlaczego przekazywanie nigdy nie było rozwiązaniem
Odrzucona trasa nigdy nie dociera do ścieżki przekazywania, więc przełączenie net.ipv4.ip_forward nie może zmienić wyniku. To ustawienie ma znaczenie później, gdy host musi przepuszczać pakiety między interfejsami, a włączenie go przed poprawieniem tabeli zmienia tylko to, który etap zawiedzie następny.
W tym samym miejscu często obwinia się dwie inne rzeczy. Trasa może zostać przyjęta i mimo to przegrać z bardziej szczegółową trasą, a reguła zapory może odrzucić ruch po poprawnym wyszukaniu. Trzymaj etapy osobno: składnia, instalacja, wybór, filtrowanie. Praca na niewłaściwym etapie wydaje się produktywna, bo każda zmiana coś restartuje.
Sprawdź zainstalowaną trasę i ścieżkę, którą wygrywa
Gdy klient przyjmie wiersz, zobacz, co zainstalował i którą trasę jądro wybiera dla reprezentatywnego adresu w bloku. Jeśli zainstalowany prefiks różni się od wpisanego, normalizator zadziałał w twoim imieniu.
Zapytaj o adres członkowski oraz o jeden spoza bloku, aby porównanie było sensowne, a nie tylko jednym uspokajającym wierszem:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10Trzecie zapytanie powinno wypaść poza tunelem, jeśli prefiks jest poprawny, a gdy tak się nie dzieje, zbudowana trasa jest szersza, niż myślisz. Zapisz, co prefiks miał obejmować, zanim dotkniesz następnego ustawienia, bo trasa, która się parsuje, i ścieżka, która działa, pozostają osobnymi obserwacjami.