Adres peer PPP a punkt końcowy VPN: który trafia do via

Jedna linia na interfejsie PPP rozstrzyga większość sporu o routing na skrzynce VPN: adres wewnętrzny i peer wydrukowany obok. Przeczytaj tę parę jako maleńką podsieć, a będziesz szukać bramy, która nie istnieje. Przeczytaj ją jako dwa końce jednego łącza, a następny skok staje się oczywisty. Porównanie tutaj dotyczy tych dwóch odczytań, bo każda tabela zbudowana później dziedziczy tę, którą wybrano. Nic w zewnętrznym punkcie końcowym VPN nie jest rozstrzygane przez żadne z nich.

Dwa odczytania jednej linii interfejsu

Weź sesję, w której interfejs zgłasza inet 10.64.3.9 peer 10.64.3.1/32. Odczytanie jako podsieć traktuje 10.64.3.9 jako samotnego hosta na wysepce /32, a potem szuka routera, by dotrzeć do czegokolwiek poza nią. Ponieważ jedynym innym adresem na łączu jest peer, to odczytanie kończy się proponowaniem 10.64.3.9 jako bramy, co jest cyrkularne.

Odczytanie jako punkt końcowy jest tym udokumentowanym. Na interfejsie punkt-do-punktu peer nazywa odległy koniec tego jednego łącza, więc 10.64.3.1 jest użytecznym następnym skokiem, a 10.64.3.9 jest zawsze tylko adresem źródłowym.

Ta różnica rządzi tym, co może pojawić się w via. Wpisanie tam adresu lokalnego daje trasę, której jądro nie potrafi rozwiązać do sąsiada, więc wpis albo nie przechodzi walidacji, albo pożera ruch, wyglądając przy tym w wykazie całkowicie zdrowo. Peer działa, bo jest prawdziwym celem na łączu. Oba odczytania zgadzają się co do zewnętrznego punktu końcowego VPN, który jest całkowicie osobną tożsamością: dociera się do niego przez underlay, a nie przez tunel, który kończy.

Co sesja już zainstalowała

Zanim napiszesz jakąkolwiek własną tabelę, wydrukuj to, co przyszło z łączem. Wspierana integracja PPP zwykle instaluje trasę urządzenia i trasę peera podczas konfiguracji sesji, a te dwa wpisy już kodują właściwe odczytanie.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Trasa urządzenia taka jak 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nie niesie bramy, bo sam interfejs jest drogą. Trasa nazywająca peera przez via to inny obiekt o innym czasie życia, i znika, gdy sesja padnie. Kopiowanie którejkolwiek z tych dwóch form do trwałej tabeli bez sprawdzenia, jak jest reinstalowana, to zwykły powód, dla którego działający tunel traci trasę po ponownym połączeniu.

Porównaj oba wykazy, zamiast ufać pamięci. Jeśli trasa peera istnieje w main, ale twoja dodatkowa tabela jest pusta, nauczyłeś się czegoś, czego linia adresu nigdy ci nie powiedziała.

Reguła i tabela to osobne decyzje

Wybór tabeli i jej wypełnienie to niezależne kroki, a porównanie ma tu znaczenie, bo oba bywają mylone podczas debugowania. Reguła, która wysyła oznaczony ruch do tabeli 100, nie robi nic, jeśli tabela 100 nie ma pasującej trasy, a dobrze wypełniona tabela jest nieosiągalna, jeśli żadna reguła na nią nie wskazuje.

Połowa trasy domyślnej to nie trasa domyślna. Pojedyncza 0.0.0.0/1 obejmuje dolną połowę przestrzeni IPv4, więc polityka, która chce przechwycić wszystko, potrzebuje też pasującej 128.0.0.0/1 albo prawdziwej default. Czytanie działającej konfiguracji i kopiowanie jednej z dwóch połówek to sposób, w jaki ludzie kończą z pętlą routingu, która psuje się tylko przy niektórych celach.

Zostaw świadome wyjątki dla adresów, które muszą pozostać w sieci LAN, i zdecyduj, co się dzieje, gdy wyszukiwanie niczego nie znajdzie w wybranej tabeli. Jawna trasa zapasowa jest łatwiejsza do przemyślenia niż pusta tabela, która zwraca wynik nieosiągalny i sprawia, że aplikacja wygląda na zepsutą, a nie na źle kierowaną.

Zadaj wyszukiwaniu pytanie, które zadaje twoja aplikacja

ip route get rozwiązuje ścieżkę, ip route show wymienia zapisane wpisy, i oba mogą się różnić, choć żaden nie jest błędny. Uwzględnij kontekst źródła, bo reguły oparte na źródle pasują tylko wtedy, gdy wyszukiwanie niesie źródło.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Pierwsze polecenie zadaje pytanie od strony hosta. Drugie dodaje interfejs wejściowy, co jest bliższe temu, czego doświadcza ruch przekazywany dalej, a odpowiedź często wskazuje inną tabelę. Żaden z celów nie jest usługą testową na żywo, 198.51.100.23 to adres dokumentacyjny, więc zastąp go hostem, który wolno ci sondować.

Nawet poprawne wyszukiwanie dowodzi tylko, że wybrano ścieżkę. Nie mówi nic o tym, czy druga strona przyjmuje ruch ani czy odpowiedź może wrócić przez to samo rozumowanie.

Gdzie porównanie się odwraca

Ruch hosta i ruch przekazywany nie tylko wykonują inne wyszukiwania, spotykają też inne filtry w drodze powrotnej. Linux stosuje walidację odwrotnej ścieżki, używając surowszego z ustawień wszystkich interfejsów i interfejsu odbierającego, więc zmiana wartości jednego interfejsu może nie mieć widocznego efektu. Routing oparty na znacznikach dodaje relację src_valid_mark, w której znacznik musi się zgadzać, by źródło uznano za prawidłowe.

Jeśli odpowiedzi znikają, a routing wychodzący wygląda dobrze, odczytaj efektywne wartości, zanim ich dotkniesz, i zmieniaj je tylko z podanym uzasadnieniem polityki.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Wybierz między dwoma projektami na podstawie dowodów: jeśli aplikacja wiąże się z adresem PPP, wystarczy reguła źródłowa plus tabela trzymająca trasę peera. Jeśli skrzynka przekazuje ruch dla sieci LAN za sobą, potrzebujesz też zgodności kontekstu wejściowego i ścieżki powrotnej. Gdy się nie zgadzają, popraw własność trasy, zamiast poluzowywać walidację dla całej maszyny.