Listen, Bind og BindSame i Tinyproxy: hvilken adresse vinner
Listen velger adressen som tar imot klienter, Bind velger kilden for utgående tilkoblinger. Ingen av dem installerer en rute, så verifiser stien selv.
Proxyen svarer, forespørselen fullføres, og likevel registrerer destinasjonen fortsatt LAN-adressen. Ingenting i proxy-loggen ser galt ut, og linjen du endret er nettopp den dokumentasjonen ba deg endre. På en vert med både en LAN-adresse og en tunneladresse avgjør tre direktiver hvilken adresse som vises hvor, og bare ett av dem gjelder den utgående siden. Leser du dem i feil rekkefølge, havner du i rutetabellen uten grunn.
Symptomet: destinasjonen ser LAN-adressen
En klient kobler til proxyen på LAN-adressen, og proxyen åpner sin egen tilkobling til destinasjonen. Den andre tilkoblingen velger en kildeadresse etter kjernens regler, og som standard er det den ruteoppslaget velger. Derfor registrerer destinasjonen vertens primære adresse selv om hver byte gikk gjennom proxyen. I videresendingsforstand er ingenting ødelagt, og derfor har proxy-loggen ingenting å si om det.
Speilbildet av den feilen er lettere å se: fest den utgående kilden til tunneladressen, og LAN-klienter når ikke lytteren i det hele tatt. Den versjonen kunngjør seg selv, mens den første gjemmer seg bak en forespørsel som virker. Begge kommer av å behandle ett direktiv som om det svarte på begge spørsmålene.
Tre direktiver, tre forskjellige adresser
Listen navngir den lokale adressen som tar imot proxyklienter. Bind gir en kildeadresse for tilkoblingene proxyen lager utover, og BindSame ber den gjenbruke den lokale adressen til tilkoblingen den nettopp har godtatt. Det er tre separate spørsmål, og én linje besvarer bare ett av dem. Å blande dem er den vanlige grunnen til at en endring ser ut til å gjøre ingenting.
| 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 |
Les den kommenterte konfigurasjonen som følger med den installerte versjonen, fordi standardverdier og akseptert syntaks endrer seg mellom utgivelser. Prosjektets eksempelkonfigurasjon dokumenterer hvert direktiv ved siden av de andre. Sammenlign den filen med den på disken, ikke med en veiledning skrevet for en annen distribusjon.
Sett lytteren og den utgående kilden uavhengig av hverandre
Ta en vert der LAN-adressen er 192.168.50.10 og tunneladressen er 10.90.0.3. Hvis LAN-klienter skal nå proxyen mens forespørslene deres går ut gjennom tunnelen, er det to uavhengige beslutninger, og begge må skrives ned. Fragmentet nedenfor uttrykker nøyaktig det og ingenting annet.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noDette er ikke en fullstendig konfigurasjon, så behold den godkjente porten, autentiseringen, klienttilgangskontrollene og destinasjonsbegrensningene. Begge adressene må tilhøre denne verten inne i Tinyproxys nettverksnavnerom, fordi en Bind-verdi prosessen ikke kan eie feiler ved tilkobling, ikke ved oppstart. BindSame yes beskriver en annen policy, der den lokale adressen til den godtatte tilkoblingen blir den utgående kilden. I gjeldende utgivelser har den grenen forrang foran Bind-listen, og slik forsvinner en konfigurert kilde uten feil.
Kontroller ruten kilden forutsetter
Å velge en kildeadresse lager ikke en sti, så spør kjernen hva den ville gjort med den kilden og den destinasjonen. Et oppslag som navngir tunnelegrensesnittet er minimumsbeviset, og ett som navngir LAN-grensesnittet betyr at kilden ikke kan virke som skrevet. Oppslaget er kontekstuelt: det vurderer policyreglene og tabellen som gjelder i det navnerommet. Det er ikke en tilkobling, og det sier ingenting om hva en NAT lenger ned vil presentere for tjenesten.
ip -4 route get 203.0.113.25 from 10.90.0.3Bruk en dokumentasjonsadresse i eksempelet og bytt inn tjenesten du har tillatelse til å teste. Kjør oppslaget inne i proxyens navnerom når proxyen kjører i en container, fordi vertens regler ikke er reglene prosessen ser. Når den tiltenkte tunnelruten mangler, la nettverkseieren rette det i stedet for å legge destinasjonsspesifikke regler på proxyverten. Ikke tøm vertsruter eller deaktiver server-skutte ruter for å få et oppslag til å lykkes, selv om en eldre veiledning gjorde det, fordi slike endringer flytter hele vertens godkjente VPN-atferd for å reparere én proxysti.
Bekreft kilden ved destinasjonen
Les kilden der forespørselen ankommer, ikke der den forlater. Applikasjonsloggen til destinasjonen, eller enheten foran den, registrerer adressen den faktisk så, mens proxyen bare kan fortelle deg hva den hadde til hensikt. Lag én ny forespørsel gjennom den tiltenkte lytteren etter endringen, fordi en bufret tilkobling ikke beviser noe om den nye bindingen. Sammenlign deretter den registrerte adressen med den du konfigurerte.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl er bare trafikkgeneratoren; adressen som er verdt å verifisere er den den fjerne siden logget, ikke den peeren curl tilfeldigvis koblet til. Hvis de to er uenige, avgjør om forskjellen kommer fra kildevalget eller fra en oversettelse lenger frem, fordi de rettes på forskjellige steder. Planlegg adresseendringer og omstarter av proxyen sammen, fordi binding av en adresse tunnelen ikke lenger har feiler stille etter en gjenoppkobling. Definer DNS- og IPv6-atferd separat også, fordi IPv4-fragmentet ovenfor ikke beviser noe om noen av dem.