Listen, Bind a BindSame v Tinyproxy: která adresa vyhraje

Proxy odpovídá, požadavek se dokončí, a cíl stále zaznamenává adresu z LAN. V logu proxy nic nevypadá špatně a řádek, který jste změnili, je přesně ten, který vám dokumentace řekla změnit. Na hostiteli s adresou v LAN i adresou tunelu rozhodují tři direktivy o tom, která adresa se kde objeví, a jen jedna z nich se týká odchozí strany. Když je přečtete ve špatném pořadí, skončíte bez důvodu v routovací tabulce.

Příznak: cíl vidí adresu z LAN

Klient se připojí k proxy na adrese v LAN a proxy otevře vlastní spojení k cíli. Toto druhé spojení vybírá zdrojovou adresu podle pravidel jádra a ve výchozím nastavení je to ta, kterou zvolí vyhledání trasy. Cíl tedy zaznamená primární adresu hostitele, i když každý bajt prošel přes proxy. Z hlediska předávání není nic rozbité, a proto k tomu log proxy nemá co říct.

Zrcadlová verze této závady se pozná snáz: připněte odchozí zdroj na adresu tunelu a klienti z LAN přestanou na posluchače dosáhnout úplně. Ta verze se sama ohlásí, zatímco první se schovává za fungujícím požadavkem. Obě vznikají z toho, že se s jednou direktivou zachází, jako by odpovídala na obě otázky.

Tři direktivy, tři různé adresy

Listen pojmenovává místní adresu, která přijímá klienty proxy. Bind dodává zdrojovou adresu pro spojení, která proxy vytváří ven, a BindSame mu říká, aby znovu použil místní adresu spojení, které právě přijal. To jsou tři oddělené otázky a jeden řádek odpovídá jen na jednu z nich. Záměna mezi nimi je obvyklý důvod, proč se změna jeví bez účinku.

Přečtěte si okomentovanou konfiguraci dodávanou s nainstalovanou verzí, protože výchozí hodnoty a přijímaná syntaxe se mezi vydáními mění. ukázková konfigurace projektu dokumentuje každou direktivu vedle ostatních. Porovnejte tento soubor s tím na disku, ne s návodem psaným pro jinou distribuci.

Nastavte posluchač a odchozí zdroj nezávisle

Vezměte hostitele s adresou v LAN 192.168.50.10 a adresou tunelu 10.90.0.3. Pokud mají klienti z LAN dosáhnout na proxy a jejich požadavky mají vycházet z tunelu, jsou to dvě nezávislá rozhodnutí a obě je třeba zapsat. Fragment níže vyjadřuje přesně to a nic jiného.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Není to úplná konfigurace, proto zachovejte schválený port, ověřování, řízení přístupu klientů a omezení cílů. Obě adresy musí patřit tomuto hostiteli uvnitř síťového jmenného prostoru Tinyproxy, protože hodnota Bind, kterou proces nemůže vlastnit, selže při připojení, ne při startu. BindSame yes popisuje jinou politiku, kdy se místní adresa přijatého spojení stane odchozím zdrojem. V současných vydáních má tato větev přednost před seznamem Bind, a takto se nakonfigurovaný zdroj ztratí bez chyby.

Ověřte trasu, kterou zdroj předpokládá

Volba zdrojové adresy nevytváří cestu, proto se jádra zeptejte, co by s tímto zdrojem a tímto cílem udělalo. Vyhledání, které jmenuje rozhraní tunelu, je minimálním důkazem, a to, které jmenuje rozhraní LAN, znamená, že zdroj nemůže fungovat tak, jak je napsán. Vyhledání je kontextové: vyhodnocuje pravidla politiky a tabulku platnou pro daný jmenný prostor. Není to spojení a nic neříká o tom, co službě představí následný NAT.

ip -4 route get 203.0.113.25 from 10.90.0.3

V příkladu použijte dokumentační adresu a nahraďte ji službou, kterou máte oprávnění testovat. Spouštějte vyhledání uvnitř jmenného prostoru proxy, když proxy běží v kontejneru, protože pravidla hostitele nejsou pravidla, která proces vidí. Když zamýšlená trasa tunelem chybí, ať ji opraví vlastník sítě, místo abyste na hostitele proxy přidávali pravidla specifická pro cíl. Nevymazávejte trasy hostitele ani nevypínejte trasy posílané serverem, aby vyhledání prošlo, i když to starší návod dělal, protože takové změny posouvají celé schválené chování VPN hostitele kvůli opravě jedné cesty proxy.

Potvrďte zdroj na cíli

Čtěte zdroj tam, kam požadavek dorazí, ne odkud odchází. Log aplikace na cíli nebo hraniční zařízení před ním zaznamená adresu, kterou skutečně vidělo, zatímco proxy vám může říct jen, co zamýšlela. Po změně pošlete jeden nový požadavek přes zamýšlený posluchač, protože uložené spojení nic nedokazuje o novém navázání. Potom porovnejte zaznamenanou adresu s tou, kterou jste nastavili.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl je jen generátor provozu; adresa, kterou stojí za to ověřit, je ta, kterou zaznamenala vzdálená strana, ne protějšek, ke kterému se curl náhodou připojil. Pokud se obě neshodují, určete, zda rozdíl pochází z volby zdroje, nebo z překladu dále na cestě, protože to se opravuje na různých místech. Plánujte změny adres a restarty proxy společně, protože navázání adresy, kterou tunel už nemá, po opětovném připojení tiše selže. Chování DNS a IPv6 definujte také zvlášť, protože fragment IPv4 výše nic z toho nedokazuje.