Listen, Bind och BindSame i Tinyproxy: vilken adress vinner

Proxyn svarar, begäran slutförs och ändå registrerar målet fortfarande LAN-adressen. Inget i proxyloggen ser fel ut, och raden du ändrade är precis den som dokumentationen sa åt dig att ändra. På en värd med både LAN-adress och tunneladress avgör tre direktiv vilken adress som visas var, och bara ett av dem gäller den utgående sidan. Läser du dem i fel ordning hamnar du i routingtabellen utan anledning.

Symtomet: målet ser LAN-adressen

En klient ansluter till proxyn på LAN-adressen, och proxyn öppnar sin egen anslutning till målet. Den andra anslutningen väljer en källadress enligt kärnans regler, och som standard är det den som ruttuppslaget väljer. Därför registrerar målet värdens primära adress trots att varje byte gick genom proxyn. Vidarebefordran är inte trasig, och därför har proxyloggen inget att säga om det.

Spegelbilden av det felet är lättare att se: fäst den utgående källan på tunneladressen och LAN-klienterna når inte lyssnaren alls. Den versionen tillkännager sig själv, medan den första gömmer sig bakom en begäran som fungerar. Båda kommer av att behandla ett direktiv som om det svarade på båda frågorna.

Tre direktiv, tre olika adresser

Listen namnger den lokala adressen som tar emot proxyklienter. Bind ger en källadress för de anslutningar proxyn gör utåt, och BindSame säger åt den att återanvända den lokala adressen för anslutningen den just tog emot. Det är tre separata frågor, och en rad besvarar bara en av dem. Att blanda ihop dem är det vanliga skälet till att en ändring ser ut att inte göra något.

Läs den kommenterade konfigurationen som följer med den installerade versionen, eftersom standardvärden och accepterad syntax ändras mellan utgåvor. Projektets exempelkonfiguration dokumenterar varje direktiv bredvid de andra. Jämför den filen med den på disken, inte med en guide skriven för en annan distribution.

Ställ in lyssnaren och den utgående källan oberoende av varandra

Ta en värd vars LAN-adress är 192.168.50.10 och vars tunneladress är 10.90.0.3. Om LAN-klienter ska nå proxyn medan deras begäranden går ut genom tunneln, är det två oberoende beslut och båda måste skrivas ner. Fragmentet nedan uttrycker exakt det och inget annat.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Det här är inte en fullständig konfiguration, så behåll den godkända porten, autentiseringen, klientåtkomstkontrollerna och målets begränsningar. Båda adresserna måste tillhöra den här värden inne i Tinyproxys nätverksnamnrymd, eftersom ett Bind-värde som processen inte kan äga misslyckas vid anslutning, inte vid start. BindSame yes beskriver en annan policy, där den mottagna anslutningens lokala adress blir den utgående källan. I aktuella utgåvor har den grenen företräde framför Bind-listan, och så försvinner en konfigurerad källa utan fel.

Kontrollera rutten som källan förutsätter

Att välja en källadress skapar ingen väg, så fråga kärnan vad den skulle göra med den källan och det målet. Ett uppslag som namnger tunnelgränssnittet är minimibeviset, och ett som namnger LAN-gränssnittet betyder att källan inte kan fungera som skriven. Uppslaget är kontextuellt: det utvärderar policyreglerna och tabellen som gäller i den namnrymden. Det är inte en anslutning, och det säger ingenting om vad en NAT längre fram visar för tjänsten.

ip -4 route get 203.0.113.25 from 10.90.0.3

Använd en dokumentationsadress i exemplet och byt in den tjänst du har tillstånd att testa. Kör uppslaget inne i proxyns namnrymd när proxyn körs i en container, eftersom värdens regler inte är de regler processen ser. När den avsedda tunnelrutten saknas, låt nätverksägaren rätta den i stället för att lägga till målspecifika regler på proxyvärden. Töm inte värdens rutter och stäng inte av serverpushade rutter för att få ett uppslag att lyckas, även om en äldre guide gjorde det, eftersom sådana ändringar flyttar hela värdens godkända VPN-beteende för att reparera en enda proxyväg.

Bekräfta källan vid målet

Läs källan där begäran anländer, inte där den lämnar. Målets applikationslogg, eller enheten framför det, registrerar adressen den faktiskt såg, medan proxyn bara kan berätta vad den avsåg. Gör en ny begäran genom den avsedda lyssnaren efter ändringen, eftersom en cachelagrad anslutning inte bevisar något om den nya bindningen. Jämför sedan den registrerade adressen med den du konfigurerade.

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

curl är bara trafikgeneratorn; adressen som är värd att verifiera är den som fjärrsidan loggade, inte den peer som curl råkade ansluta till. Om de två inte stämmer, avgör om skillnaden kommer från källvalet eller från en översättning längre fram, eftersom de rättas på olika ställen. Planera adressändringar och omstarter av proxyn tillsammans, eftersom bindning av en adress som tunneln inte längre har misslyckas tyst efter en återanslutning. Definiera även DNS- och IPv6-beteende separat, eftersom IPv4-fragmentet ovan inte bevisar något om något av dem.