Proxy odpovedá, požiadavka sa dokončí, a napriek tomu cieľ stále zaznamenáva adresu z LAN. V logu proxy nič nevyzerá nesprávne a riadok, ktorý ste zmenili, je presne ten, ktorý vám dokumentácia povedala zmeniť. Na hostiteľovi s adresou v LAN aj adresou tunela rozhodujú tri direktívy o tom, ktorá adresa sa kde objaví, a iba jedna z nich sa týka odchádzajúcej strany. Ak ich prečítate v nesprávnom poradí, skončíte bez dôvodu v smerovacej tabuľke.

Príznak: cieľ vidí adresu z LAN

Klient sa pripojí k proxy na adrese v LAN a proxy otvorí vlastné spojenie k cieľu. Toto druhé spojenie vyberá zdrojovú adresu podľa pravidiel jadra a predvolene je to tá, ktorú zvolí vyhľadanie trasy. Preto cieľ zaznamená primárnu adresu hostiteľa, aj keď každý bajt prešiel cez proxy. Z hľadiska preposielania nie je nič pokazené, a preto k tomu log proxy nemá čo povedať.

Zrkadlová verzia tejto závady sa pozná ľahšie: pripnite odchádzajúci zdroj na adresu tunela a klienti z LAN prestanú na poslucháča dosahovať úplne. Tá verzia sa sama ohlási, zatiaľ čo prvá sa skrýva za fungujúcou požiadavkou. Obe vznikajú z toho, že sa s jednou direktívou zaobchádza, akoby odpovedala na obe otázky.

Tri direktívy, tri rôzne adresy

Listen pomenúva miestnu adresu, ktorá prijíma klientov proxy. Bind dodáva zdrojovú adresu pre spojenia, ktoré proxy vytvára smerom von, a BindSame mu hovorí, aby znova použil miestnu adresu práve prijatého spojenia. To sú tri oddelené otázky a jeden riadok odpovedá len na jednu z nich. Ich zamieňanie je obvyklý dôvod, prečo sa zmena javí bez účinku.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

Prečítajte si okomentovanú konfiguráciu dodávanú s nainštalovanou verziou, pretože predvolené hodnoty a prijímaná syntax sa medzi vydaniami menia. Ukážková konfigurácia projektu dokumentuje každú direktívu vedľa ostatných. Porovnajte tento súbor s tým na disku, nie s návodom písaným pre inú distribúciu.

Nastavte poslucháča a odchádzajúci zdroj nezávisle

Vezmite hostiteľa s adresou v LAN 192.168.50.10 a adresou tunela 10.90.0.3. Ak majú klienti z LAN dosiahnuť proxy a ich požiadavky majú vychádzať z tunela, sú to dve nezávislé rozhodnutia a obe treba zapísať. Fragment nižšie vyjadruje presne to a nič iné.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Toto nie je úplná konfigurácia, preto zachovajte schválený port, overovanie, riadenie prístupu klientov a obmedzenia cieľov. Obe adresy musia patriť tomuto hostiteľovi v rámci sieťového menného priestoru Tinyproxy, pretože hodnota Bind, ktorú proces nemôže vlastniť, zlyhá pri pripájaní, nie pri štarte. BindSame yes opisuje inú politiku, kde sa miestna adresa prijatého spojenia stane odchádzajúcim zdrojom. V súčasných vydaniach má táto vetva prednosť pred zoznamom Bind, a takto sa nakonfigurovaný zdroj stratí bez chyby.

Overte trasu, ktorú zdroj predpokladá

Voľba zdrojovej adresy nevytvára cestu, preto sa jadra opýtajte, čo by urobilo s týmto zdrojom a týmto cieľom. Vyhľadanie, ktoré pomenúva rozhranie tunela, je minimálnym dôkazom, a to, ktoré pomenúva rozhranie LAN, znamená, že zdroj nemôže fungovať tak, ako je napísaný. Vyhľadanie je kontextové: vyhodnocuje pravidlá politiky a tabuľku platnú pre daný menný priestor. Nie je to spojenie a nič nehovorí o tom, čo službe predstaví nadväzujúci NAT.

ip -4 route get 203.0.113.25 from 10.90.0.3

V príklade použite dokumentačnú adresu a nahraďte ju službou, ktorú máte oprávnenie testovať. Spúšťajte vyhľadanie v mennom priestore proxy, keď proxy beží v kontajneri, pretože pravidlá hostiteľa nie sú pravidlá, ktoré proces vidí. Keď zamýšľaná trasa tunelom chýba, nech ju opraví vlastník siete, namiesto pridávania pravidiel špecifických pre cieľ na hostiteľa proxy. Nevymazávajte trasy hostiteľa a nevypínajte trasy posielané serverom, aby vyhľadanie prešlo, aj keď to starší návod robil, pretože také zmeny posúvajú celé schválené správanie VPN hostiteľa, aby opravili jednu cestu proxy.

Potvrďte zdroj na cieli

Čítajte zdroj tam, kam požiadavka dorazí, nie odkiaľ odchádza. Log aplikácie na cieli alebo hraničné zariadenie pred ním zaznamená adresu, ktorú skutočne videlo, zatiaľ čo proxy vám môže povedať len to, čo zamýšľalo. Po zmene pošlite jednu novú požiadavku cez zamýšľaný poslucháč, pretože uložené spojenie nič nedokazuje o novom naviazaní. Potom porovnajte zaznamenanú adresu s tou, ktorú ste nastavili.

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

curl je len generátor prevádzky; adresa, ktorú stojí za to overiť, je tá, ktorú zaznamenala vzdialená strana, nie protistrana, ku ktorej sa curl náhodou pripojil. Ak sa obe nezhodujú, určite, či rozdiel pochádza z voľby zdroja alebo z prekladu ďalej na ceste, pretože to sa opravuje na rôznych miestach. Plánujte zmeny adries a reštarty proxy spolu, pretože naviazanie adresy, ktorú tunel už nemá, po opätovnom pripojení ticho zlyhá. Správanie DNS a IPv6 definujte tiež zvlášť, pretože fragment IPv4 vyššie nič z toho nedokazuje.

Súvisiace články