Listen, Bind og BindSame i Tinyproxy: hvilken adresse vinder
Listen vælger den adresse, der accepterer klienter, Bind vælger kilden til udgående forbindelser. Ingen af dem installerer en rute, så verificér stien selv.
Proxyen svarer, anmodningen fuldføres, og alligevel registrerer destinationen stadig LAN-adressen. Intet i proxyens log ser forkert ud, og den linje, du ændrede, er netop den, dokumentationen bad dig ændre. På en vært med både en LAN-adresse og en tunneladresse afgør tre direktiver, hvilken adresse der vises hvor, og kun ét af dem handler om den udgående side. Læser du dem i forkert rækkefølge, ender du i rutetabellen uden grund.
Symptomet: destinationen ser LAN-adressen
En klient forbinder til proxyen på LAN-adressen, og proxyen åbner sin egen forbindelse til destinationen. Den anden forbindelse vælger en kildeadresse efter kernens regler, og som standard er det den, ruteforespørgslen vælger. Derfor registrerer destinationen værtens primære adresse, selv om hver byte gik gennem proxyen. I videresendelsesforstand er intet i stykker, og derfor har proxyens log intet at sige om det.
Spejlbilledet af den fejl er lettere at se: fastlås den udgående kilde til tunneladressen, og LAN-klienter når slet ikke lytteren. Den version annoncerer sig selv, mens den første gemmer sig bag en anmodning, der virker. Begge kommer af at behandle ét direktiv, som om det svarede på begge spørgsmål.
Tre direktiver, tre forskellige adresser
Listen angiver den lokale adresse, der accepterer proxyklienter. Bind leverer en kildeadresse til de forbindelser, proxyen laver udad, og BindSame beder den genbruge den lokale adresse fra den forbindelse, den netop har accepteret. Det er tre separate spørgsmål, og én linje besvarer kun ét af dem. At blande dem sammen er den sædvanlige grund til, at en ændring ser ud til at gø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 |
Læs den kommenterede konfiguration, der følger med den installerede version, fordi standardværdier og accepteret syntaks flytter sig mellem udgivelser. Projektets eksempelkonfiguration dokumenterer hvert direktiv ved siden af de andre. Sammenlign den fil med den på disken, ikke med en vejledning skrevet til en anden distribution.
Indstil lytteren og den udgående kilde uafhængigt
Tag en vært, hvis LAN-adresse er 192.168.50.10, og hvis tunneladresse er 10.90.0.3. Hvis LAN-klienter skal nå proxyen, mens deres anmodninger forlader via tunnelen, er det to uafhængige beslutninger, og begge skal skrives ned. Fragmentet nedenfor udtrykker præcis det og intet andet.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noDet er ikke en fuldstændig konfiguration, så behold den godkendte port, godkendelsen, klientadgangskontrollerne og destinationsbegrænsningerne. Begge adresser skal tilhøre denne vært inde i Tinyproxys netværksnavnerum, fordi en Bind-værdi, processen ikke kan eje, fejler ved forbindelse, ikke ved start. BindSame yes beskriver en anden politik, hvor den accepterede forbindelses lokale adresse bliver den udgående kilde. I aktuelle udgivelser har den gren forrang foran Bind-listen, og det er sådan en konfigureret kilde forsvinder uden en fejl.
Kontrollér den rute, kilden forudsætter
At vælge en kildeadresse skaber ikke en sti, så spørg kernen, hvad den ville gøre med den kilde og den destination. Et opslag, der navngiver tunnelegrænsefladen, er det mindste bevis, og et, der navngiver LAN-grænsefladen, betyder, at kilden ikke kan virke som skrevet. Opslaget er kontekstuelt: det vurderer policyreglerne og tabellen, der gælder for det navnerum. Det er ikke en forbindelse, og det siger intet om, hvad en NAT længere fremme præsenterer for tjenesten.
ip -4 route get 203.0.113.25 from 10.90.0.3Brug en dokumentationsadresse i eksemplet, og indsæt den tjeneste, du har tilladelse til at teste. Kør opslaget inde i proxyens navnerum, når proxyen kører i en container, fordi værtens regler ikke er de regler, processen ser. Når den tilsigtede tunnelrute mangler, lad netværksejeren rette det i stedet for at tilføje destinationsspecifikke regler på proxyværten. Ryd ikke værtsruter og deaktiver ikke server-skubbede ruter for at få et opslag til at lykkes, selv om en ældre vejledning gjorde det, fordi sådanne ændringer flytter hele værtens godkendte VPN-adfærd for at reparere én proxysti.
Bekræft kilden ved destinationen
Læs kilden, hvor anmodningen ankommer, ikke hvor den forlader. Destinationens applikationslog, eller enhedens kant foran den, registrerer den adresse, den faktisk så, mens proxyen kun kan fortælle, hvad den havde til hensigt. Lav én ny anmodning gennem den tilsigtede lytter efter ændringen, fordi en cachet forbindelse ikke beviser noget om den nye binding. Sammenlign derefter den registrerede adresse med den, du konfigurerede.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl er kun trafikgeneratoren; den adresse, der er værd at verificere, er den, den fjerne side loggede, ikke den peer, curl tilfældigvis forbandt til. Hvis de to er uenige, afgør, om forskellen kommer fra kildevalg eller fra oversættelse længere fremme, fordi de rettes på forskellige steder. Planlæg adresseændringer og proxygenstarter sammen, fordi binding af en adresse, tunnelen ikke længere har, fejler stille efter en genforbindelse. Definer DNS- og IPv6-adfærd separat, fordi IPv4-fragmentet ovenfor ikke beviser noget om nogen af dem.