Odpowiedź wychodzi przez LAN, nie przez tunel: dlaczego i jak

Usługa publikowana przez bramę działa z większości internetu i zawodzi z jednego biura. Ktoś sprawdza tunel, widzi nadchodzące żądanie i dochodzi do wniosku, że odpowiedź musi wrócić tą samą drogą. Linux tak nie działa i żadne badanie tunelu tego nie zmieni. Odpowiedź jest rutowana według celu, a ten jeden zawodzący wywołujący siedzi w podsieci, do której host już dociera bezpośrednio.

Co faktycznie decyduje o pakiecie wychodzącym

Jądro szuka trasy do celu pakietu, przegląda reguły polityki w kolejności priorytetów, a następnie tabelę wybraną przez pasującą regułę. Interfejs, przez który przyszedł pakiet, nie odgrywa żadnej roli, chyba że napisano regułę lub znacznik, aby to miało znaczenie. To fakt rutingu tego hosta, a nie usterka tunelu.

Żądanie odebrane przez tunel może więc wywołać odpowiedź wychodzącą przez interfejs fizyczny, a przepływ staje się jednokierunkowy, bez żadnego urządzenia zgłaszającego błąd. Sprawdź oba kierunki, zanim wyciągniesz wniosek o tunelu. Odpowiedź wychodząca w złą stronę znika z liczników tunelu, dlatego oba końce nie zgadzają się co do tego, czy coś wysłano. Zwróć uwagę, który licznik się zmienił, zanim dotkniesz reguły.

Dlaczego wygrywa lokalna podsieć

Host z adresem w sieci lokalnej ma w tabeli głównej trasę połączoną dla tego prefiksu, a trasa połączona to bezpośrednie dopasowanie. Gdy wywołujący pochodzi z tej samej podsieci, wyszukiwanie znajduje łącze lokalne, zanim tunel w ogóle zostanie rozważony.

To asymetria sprawia, że diagnoza jest myląca. Wywołujący z szerszego internetu działają, bo nie pasują do żadnej trasy lokalnej, natomiast jedyny wywołujący dzielący prefiks biura zawodzi, i to właśnie z nim ktoś testuje.

Zasięg peerów to nie to samo co zainstalowane trasy

Po stronie tunelu dozwolone zakresy peera opisują, co wolno wysłać do tunelu i jakie źródła są z niego akceptowane. Nie mówią nic o tym, dokąd lokalna tabela routingu wyśle pakiet.

Jeśli narzędzie tunelu zainstaluje na hoście trasę domyślną, może wciągnąć do tunelu niezwiązany ruch jako szkodę uboczną. Tam, gdzie decyzję powinna podejmować reguła polityki, opcja instalowania tras istnieje właśnie po to, by temu zapobiec, a adresy, klucze i ustawienia punktu końcowego pozostają dokładnie takie, jakie były. Trasa domyślna dodana dla wygody to częsty sposób, w jaki host traci własną sieć lokalną.

Wybierz tabelę według adresu źródłowego

Reguła oparta na źródle wysyła odpowiedzi z adresu usługi do prywatnej tabeli, której domyślną wartością jest tunel, podczas gdy wszystko inne nadal korzysta z tabeli głównej. Wybierz numery tabeli i priorytetu, które nie są używane lokalnie, i przeczytaj istniejące reguły, zanim cokolwiek wstawisz. Czytaj reguły aktywne, a nie zapisany plik, bo oba mogą się różnić po restarcie.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Ostatnia linia sprawia, że brakująca trasa zawodzi widocznie, zamiast wracać do łącza lokalnego. Źródło musi być naprawdę przypisane do hosta, a zwykłe wyszukiwania lokalne i główne muszą pozostać na wcześniejszych pozycjach. Reguła wybiera tabelę według źródła; nie porównuje długości prefiksów między tabelami.

Potwierdź trasę, a potem usługę

Zapytaj jądro, co by zrobiło, zamiast wnioskować z przechwycenia, używając adresu usługi jako selektora źródła. Prawidłowa odpowiedź tutaj oszczędza cały ślad pakietów.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Wyjście powinno wskazywać tunel. Następnie przetestuj źródło, którego nie dotykałeś, i potwierdź, że nadal wybiera łącze lokalne, aby zmiana pozostała ograniczona do jednego adresu. Szerszy selektor niczego by nie dowiódł w sprawie pierwotnej skargi.

Czego to nie naprawia

Zostaw przekazywanie, reguły zapory i zachowanie ICMPv6 na bramie takie, jakie były, bo trasa źródłowa nie zastępuje żadnego z nich. Brakujący komunikat Packet Too Big nadal psuje duże odpowiedzi, niezależnie od tego, która tabela wygrała wyszukiwanie. Napraw to przed dodaniem reguł routingu, inaczej objaw przetrwa zmianę.

Potwierdź model publikacji, zanim cokolwiek z tego zastosujesz. Odwrotny proxy, który otwiera własne połączenie backendowe, przedstawia własne źródło i nie zachowuje wywołującego, więc ta usterka nie może wystąpić w takiej konstrukcji. Zastosowanie tam reguły dodałoby wyjątek routingu, który niczego nie rozwiązuje i ukrywa prawdziwą przyczynę.

Na koniec zapisz numery reguł i tabelę w zarządzaniu konfiguracją hosta. Reguła polityki dodana ręcznie znika przy następnej przebudowie, a wywołujący z biura wraca z tą samą skargą.