Listen, Bind og BindSame i Tinyproxy: kva adresse vinn

Proxyen svarar, førespurnaden blir fullført, og likevel registrerer destinasjonen framleis LAN-adressa. Ingenting i proxy-loggen ser gale ut, og linja du endra er nettopp den dokumentasjonen bad deg endre. På ein vert med både LAN-adresse og tunneladresse avgjer tre direktiv kva adresse som blir vist kvar, og berre eitt av dei gjeld den utgåande sida. Les du dei i feil rekkjefølgje, hamnar du i rutetabellen utan grunn.

Symptomet: destinasjonen ser LAN-adressa

Ein klient koplar til proxyen på LAN-adressa, og proxyen opnar si eiga tilkopling til destinasjonen. Den andre tilkoplinga vel ei kjeldadresse etter reglane til kjernen, og som standard er det den ruteoppslaget vel. Derfor registrerer destinasjonen den primære adressa til verten sjølv om kvar byte gjekk gjennom proxyen. I videresendingssamanheng er ingenting øydelagt, og derfor har proxy-loggen ingenting å seie om det.

Spegelbiletet av den feilen er lettare å sjå: fest den utgåande kjelda til tunneladressa, og LAN-klientar når ikkje lyttaren i det heile. Den versjonen kunngjer seg sjølv, medan den første gøymer seg bak ein førespurnad som verkar. Begge kjem av å handsame eitt direktiv som om det svara på båe spørsmåla.

Tre direktiv, tre ulike adresser

Listen namngir den lokale adressa som tek imot proxyklientar. Bind gir ei kjeldadresse for tilkoplingane proxyen lagar utover, og BindSame ber han bruke den lokale adressa til tilkoplinga han nettopp tok imot på nytt. Det er tre separate spørsmål, og éi linje svarar berre på eitt av dei. Å blande dei er den vanlege grunnen til at ei endring ser ut til å gjere ingenting.

Les den kommenterte konfigurasjonen som følgjer med den installerte versjonen, fordi standardverdiar og godteken syntaks endrar seg mellom utgjevingar. Prosjektet sin døme på konfigurasjon dokumenterer kvart direktiv attmed dei andre. Samanlikn den fila med den på disken, ikkje med ein rettleiar skriven for ein annan distribusjon.

Set lyttaren og den utgåande kjelda kvar for seg

Ta ein vert der LAN-adressa er 192.168.50.10 og tunneladressa er 10.90.0.3. Viss LAN-klientar skal nå proxyen medan førespurnadene deira går ut gjennom tunnelen, er det to uavhengige avgjerder, og båe må skrivast ned. Fragmentet nedanfor uttrykkjer nett dette og ingenting anna.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Dette er ikkje ein fullstendig konfigurasjon, så hald på den godkjende porten, autentiseringa, klienttilgangskontrollane og destinasjonsavgrensingane. Båe adressene må høyra til denne verten inne i nettverksnamnerommet til Tinyproxy, fordi ein Bind-verdi prosessen ikkje kan eige, feilar ved tilkopling, ikkje ved oppstart. BindSame yes skildrar ein annan politikk, der den lokale adressa til den godtekne tilkoplinga blir den utgåande kjelda. I gjeldande utgjevingar har den greina forrang framfor Bind-lista, og slik forsvinn ei konfigurert kjelde utan feil.

Kontroller ruta kjelda føreset

Å velje ei kjeldadresse lagar ikkje ein sti, så spør kjernen kva han ville gjere med den kjelda og den destinasjonen. Eit oppslag som namngir tunnelegrensesnittet er minstebeviset, og eitt som namngir LAN-grensesnittet tyder at kjelda ikkje kan verke som skriven. Oppslaget er kontekstuelt: det vurderer politikkreglane og tabellen som gjeld i det namnerommet. Det er ikkje ei tilkopling, og det seier ingenting om kva ein NAT lenger nede vil presentere for tenesta.

ip -4 route get 203.0.113.25 from 10.90.0.3

Bruk ei dokumentasjonsadresse i dømet og byt inn tenesta du har løyve til å teste. Køyr oppslaget inne i namnerommet til proxyen når proxyen køyrer i ein container, fordi reglane til verten ikkje er reglane prosessen ser. Når den tiltenkte tunnelruta manglar, la netteigaren rette det i staden for å leggje destinasjonsspesifikke reglar på proxyverten. Ikkje tøm vertsruter eller slå av server-skutte ruter for å få eit oppslag til å lukkast, sjølv om ein eldre rettleiar gjorde det, fordi slike endringar flyttar heile den godkjende VPN-åtfærda til verten for å reparere ein proxysti.

Stadfest kjelda ved destinasjonen

Les kjelda der førespurnaden kjem, ikkje der han går ut. Applikasjonsloggen til destinasjonen, eller eininga framfor han, registrerer adressa han faktisk såg, medan proxyen berre kan fortelje kva han hadde til hensikt. Lag éin ny førespurnad gjennom den tiltenkte lyttaren etter endringa, fordi ei bufra tilkopling ikkje beviser noko om den nye bindinga. Samanlikn så den registrerte adressa med den du konfigurerte.

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

curl er berre trafikk-generatoren; adressa som er verdt å stadfeste er den den fjerne sida logga, ikkje den peeren curl tilfeldigvis kopla til. Viss dei to er usamde, avgjer om skilnaden kjem frå kjeldervalet eller frå ei omsetjing lenger fram, fordi dei blir retta på ulike stader. Planlegg adresseendringar og omstart av proxyen saman, fordi binding av ei adresse tunnelen ikkje lenger har, feilar stille etter ei attilkopling. Definer òg DNS- og IPv6-åtfærd kvar for seg, fordi IPv4-fragmentet ovanfor ikkje beviser noko om nokon av dei.