Listen, Bind i BindSame w Tinyproxy: który adres wygrywa
Listen wybiera adres, który przyjmuje klientów, Bind wybiera źródło połączeń wychodzących. Żadna nie instaluje trasy, więc sprawdź ścieżkę osobno.
Proxy odpowiada, żądanie się kończy, a mimo to cel nadal zapisuje adres z sieci LAN. Nic w logu proxy nie wygląda źle, a linia, którą zmieniłeś, to dokładnie ta, którą dokumentacja kazała zmienić. Na hoście z adresem LAN i adresem tunelu trzy dyrektywy decydują, który adres gdzie się pojawia, i tylko jedna dotyczy strony wychodzącej. Czytanie ich w złej kolejności bez powodu prowadzi do tabeli routingu.
Objaw: cel widzi adres z sieci LAN
Klient łączy się z proxy na adresie LAN, a proxy otwiera własne połączenie do celu. To drugie połączenie wybiera adres źródłowy według reguł jądra i domyślnie jest to ten, który wybiera wyszukiwanie trasy. Dlatego cel zapisuje główny adres hosta, choć każdy bajt przeszedł przez proxy. Pod względem przekazywania nic nie jest zepsute i dlatego log proxy nie ma nic do powiedzenia.
Odwrotność tego błędu łatwiej zauważyć: przypnij źródło wychodzące do adresu tunelu, a klienci z sieci LAN w ogóle nie dotrą do nasłuchu. Ta wersja sama się ogłasza, a pierwsza ukrywa się za działającym żądaniem. Obie wynikają z traktowania jednej dyrektywy tak, jakby odpowiadała na oba pytania.
Trzy dyrektywy, trzy różne adresy
Listen nazywa adres lokalny, który przyjmuje klientów proxy. Bind dostarcza adres źródłowy dla połączeń, które proxy nawiązuje na zewnątrz, a BindSame każe mu użyć ponownie adresu lokalnego połączenia, które właśnie przyjął. To trzy osobne pytania, a jedna linia odpowiada tylko na jedno z nich. Mylenie ich to zwykła przyczyna tego, że zmiana wydaje się nic nie robić.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
Przeczytaj komentowaną konfigurację dostarczaną z zainstalowaną wersją, bo wartości domyślne i akceptowana składnia zmieniają się między wydaniami. Przykładowa konfiguracja projektu dokumentuje każdą dyrektywę obok pozostałych. Porównaj ten plik z plikiem na dysku, a nie z poradnikiem napisanym dla innej dystrybucji.
Ustaw nasłuch i źródło wychodzące niezależnie
Weź host, którego adres LAN to 192.168.50.10, a adres tunelu to 10.90.0.3. Jeśli klienci z sieci LAN mają docierać do proxy, a ich żądania mają wychodzić przez tunel, to dwie niezależne decyzje i obie trzeba zapisać. Poniższy fragment wyraża dokładnie to i nic więcej.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noTo nie jest pełna konfiguracja, więc zachowaj zatwierdzony port, uwierzytelnianie, kontrolę dostępu klientów i ograniczenia celów. Oba adresy muszą należeć do tego hosta w przestrzeni nazw sieci Tinyproxy, bo wartość Bind, której proces nie może posiadać, zawodzi przy łączeniu, a nie przy starcie. BindSame yes opisuje inną politykę, w której lokalny adres przyjętego połączenia staje się źródłem wychodzącym. W obecnych wydaniach ta gałąź ma pierwszeństwo przed listą Bind i tak skonfigurowane źródło znika bez błędu.
Sprawdź trasę, którą zakłada źródło
Wybór adresu źródłowego nie tworzy ścieżki, więc zapytaj jądro, co zrobiłoby z tym źródłem i tym celem. Wyszukiwanie, które wskazuje interfejs tunelu, jest minimalnym dowodem, a takie, które wskazuje interfejs LAN, znaczy, że źródło nie może działać tak, jak zapisano. Wyszukiwanie jest kontekstowe: ocenia reguły polityki i tabelę obowiązujące w tej przestrzeni nazw. To nie jest połączenie i nic nie mówi o tym, co NAT dalej pokaże usłudze.
ip -4 route get 203.0.113.25 from 10.90.0.3Użyj w przykładzie adresu dokumentacyjnego i zastąp go usługą, którą masz prawo testować. Uruchamiaj wyszukiwanie wewnątrz przestrzeni nazw proxy, gdy proxy działa w kontenerze, bo reguły hosta nie są regułami, które widzi proces. Gdy brakuje zamierzonej trasy tunelu, niech właściciel sieci ją naprawi, zamiast dodawać reguły specyficzne dla celu na hoście proxy. Nie czyść tras hosta i nie wyłączaj tras wypychanych przez serwer, aby wyszukiwanie się powiodło, nawet jeśli starszy poradnik tak robił, bo takie zmiany przesuwają całe zatwierdzone zachowanie VPN hosta, aby naprawić jedną ścieżkę proxy.
Potwierdź źródło u celu
Czytaj źródło tam, gdzie żądanie dociera, a nie skąd wychodzi. Log aplikacji celu albo urządzenie brzegowe przed nim zapisuje adres, który naprawdę zobaczyło, podczas gdy proxy może powiedzieć tylko, co zamierzało. Po zmianie wyślij jedno nowe żądanie przez zamierzony nasłuch, bo połączenie z pamięci podręcznej niczego nie dowodzi o nowym przypisaniu. Następnie porównaj zapisany adres z tym, który skonfigurowałeś.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl to tylko generator ruchu; adres wart sprawdzenia to ten, który zapisała strona odległa, a nie peer, z którym curl przypadkiem się połączył. Jeśli oba się nie zgadzają, ustal, czy różnica wynika z wyboru źródła, czy z późniejszego tłumaczenia, bo te poprawia się w różnych miejscach. Planuj zmiany adresów i restarty proxy razem, bo przypisanie adresu, którego tunel już nie ma, po ponownym połączeniu cicho zawodzi. Zachowanie DNS i IPv6 zdefiniuj osobno, bo powyższy fragment IPv4 niczego o żadnym z nich nie dowodzi.