Ten adres tunelu to peer, a nie podsieć, którą można przeglądać

Twój klient łączy się i pokazuje parę adresów albo jeden adres z 255.255.255.255 maską, a pierwszą reakcją jest, że serwer wydał coś zepsutego. Nic nie jest zepsute: interfejs tunelowy to łącze punkt-punkt, a maska opisuje drugi koniec tego jednego łącza, nie zakres sąsiadów. Czytanie pary jako adresu lokalnego i peera wyjaśnia dziwną maskę, trasę do jednego hosta obok i brakującą tablicę sąsiadów. Czego to samo czytanie nie usprawiedliwia, to plan adresów, który pokrywa się z siecią biura.

Dlaczego maska wygląda źle na łączu tunelowym

Na interfejsie Ethernet adres i maska mówią dwie rzeczy: ten host posiada adres, a wszystko w obrębie prefiksu to bezpośredni sąsiad. Jądro wyprowadza z tych dwóch faktów trasę na łączu, a następnie rozwiązuje adresy łącza dla sąsiadów, których uważa za obecnych. Interfejs punkt-punkt zachowuje własność i odrzuca sąsiadów, więc drugi adres w wierszu klienta to drugi koniec, a nie inny host w segmencie współdzielonym. Nie ma adresowania sprzętowego, ruchu rozwiązywania ani domeny rozgłoszeniowej, do której można by dołączyć, dlatego interfejs zachowuje się jak rura z dokładnie jednym celem.

To także powód, dla którego trasa do jednego hosta obok szerokiej maski jest tu normalna, a nie objawem. Osiągalność na tym łączu oznacza jeden adres, i jądro zapisuje dokładnie to. Czytaj oba adresy razem zanim uznasz, że konfiguracja jest błędna, bo każdy z nich osobno wygląda jak błąd.

Dwie topologie, dwa kształty adresu

Starsza topologia punkt-punkt daje każdemu klientowi mały blok i używa dwóch środkowych adresów, więc maska wygląda jak fragment sieci, a nie pula. Topologia podsieci przydziela adres z puli z maską puli i nazywa adres tunelu serwera peerem. Obie dają poprawne łącze, i różnią się tylko tym, które adresy pojawiają się w profilu i jaką maskę użytkownik prawdopodobnie zakwestionuje.

Którykolwiek wiersz pasuje do twojego klienta, najpierw czytaj peera, bo nazywa drugi koniec i dlatego wyjaśnia maskę. Profil skopiowany między serwerami o różnych topologiach pokaże zły kształt dla swojego nowego domu, a tę niezgodność łatwo wziąć za usterkę serwera.

Kiedy pula i sieć biura żądają tych samych bitów

Ponieważ łącze jest routowane, pula potrzebuje prefiksu, który nie występuje nigdzie wśród sieci osiągalnych dla serwera. Podziel jeden, a klient będzie miał jedną trasę dla zakresu oznaczającego dwa miejsca, a o tym, które miejsce wygra, decyduje trasa zainstalowana ostatnia. Awaria ujawnia się u klienta, choć decyzja za nią należy do planu adresów. Użytkownicy zgłaszają, że lokalny router znika, gdy tunel się podnosi, albo że odpowiadają tylko niektóre hosty biurowe.

Prefiksy, które tylko wyglądają podobnie, to inny przypadek, a porównywanie oktetów na oko nie jest porównaniem prefiksów. Wypisz oba i policz zamaskowane bity: 192.168.4.0/24 wobec 192.168.6.0/24 zgadzają się do bitu 22 i rozchodzą na bicie 23, bo trzeci oktet czyta się jako 00000100 wobec 00000110, więc te dwie sieci są naprawdę rozdzielne. Postaw 10.8.0.0/24 obok innej 10.8.0.0/24 i wszystkie 24 zamaskowane bity się zgadzają, co oznacza, że jedna trasa nie wyrazi obu miejsc. Długość maski decyduje, gdzie porównanie się zatrzymuje, a sieć zainstalowana druga jest tą, która przegrywa.

Czego łącze routowane nie potrafi dostarczyć

Rozgłaszanie i multicast nie podróżują przez łącze routowane, a kilka znanych funkcji jest na nich zbudowanych. Listy przeglądania, ogłoszenia nazw i wykrywanie usług zakładają wspólny segment, więc serwer plików może odpowiedzieć na każde żądanie po adresie i mimo to nigdy nie pojawić się na liście. Rozwiązywanie nazw zależne od lokalnego rozgłaszania łącza zawodzi z tego samego powodu, a żadna edycja profilu nie zmienia tego, co tunel potrafi przenieść. Czy to ma znaczenie, jest kwestią wymagań, a nie routingu.

Klient, który naprawdę potrzebuje tych dostaw, wymaga interfejsu mostkowanego, który przenosi ramki Ethernet i dlatego zachowuje domenę rozgłoszeniową. Ceną jest głośniejsze łącze, utrata czystego adresowania opisanego wyżej i znacznie większa powierzchnia awarii, gdy pojawią się pętle. Uzasadnij wymaganie przed zmianą i preferuj usługę nazw działającą przez łącza routowane, gdy wymaganie dotyczy tylko nazw.

Czytanie interfejsu przed edycją profilu

Zapytaj jądro, co zainstalowało, a nie co zdaje się mówić profil. Wyjście adresów pokazuje peera, który wyjaśnia maskę, a wyjście tras pokazuje, czy istnieje do niego droga. Uruchomienie obu wobec urządzenia tunelowego zajmuje chwilę i rozstrzyga pytanie.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

Jeśli te trzy się zgadzają, profil robi to, do czego został skonfigurowany, a pozostały problem leży gdzie indziej. Zmieniaj topologię tylko z powodu, który nazywa brakującą możliwość, bo nieznana maska nią nie jest.