Listen, Bind en BindSame by Tinyproxy: hokker adres wint
Listen kiest it adres dat kliïnten akseptearret, Bind kiest de boarne foar útgeande ferbiningen. Gjint fan beide ynstallearret in rûte, ferifiearje it paad dus sels.
De proxy antwurdet, de oanfraach foltôget, en dochs registrearret de bestimming noch hieltyd it LAN-adres. Neat yn it proxyloch liket ferkeard, en de rigel dy’t jo feroare hawwe is krekt dyjinge dy’t de dokumintaasje jo sein hat te feroarjen. Op in host mei sawol in LAN-adres as in tunneladres beslisse trije rjochtlinen hokker adres wêr ferskijt, en mar ien dêrfan giet oer de útgeande kant. Lês je se yn ’e ferkearde oarder, dan bedarje je sûnder reden yn ’e rûtetabel.
It symptoom: de bestimming sjocht it LAN-adres
In kliïnt ferbynt mei de proxy op it LAN-adres, en de proxy iepenet syn eigen ferbining nei de bestimming. Dy twadde ferbining kiest in boarreadres neffens de regels fan de kernel, en by ferstek is it dat wat de rûtesykje kiest. Dêrom registrearret de bestimming it primêre adres fan de host, ek al gie elke byte troch de proxy. Oan trochstjoeren is neat stikken, en dêrom hat it proxyloch dêr neat oer te sizzen.
It spegelbyld fan dy flater is makliker te sjen: pin de útgeande boarne oan it tunneladres fêst, en LAN-kliïnten berikke de listener hielendal net mear. Dy ferzje kundiget himsels oan, wylst de earste him efter in wurkjende oanfraach ferskûlet. Beide komme fan it behanneljen fan ien rjochtline as soe dy op beide fragen antwurdzje.
Trije rjochtlinen, trije ferskillende adressen
Listen neamt it lokale adres dat proxykliïnten akseptearret. Bind jout in boarreadres foar de ferbiningen dy’t de proxy nei bûten ta makket, en BindSame seit tsjin him dat er it lokale adres fan ’e ferbining dy’t er krekt akseptearre hat opnij brûke moat. Dat binne trije aparte fragen, en ien rigel beantwurdet mar ien dêrfan. Se trochinoar helje is de gewoane reden dat in feroaring neat docht te lykjen.
| 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 de annotearre konfiguraasje dy’t mei de ynstalleare ferzje komt, want ferstekwaarden en akseptearre syntaks ferskowe tusken útjeften. De foarbyldkonfiguraasje fan it projekt dokumintearret elke rjochtline njonken de oaren. Fergelykje dat bestân mei dat op ’e skiif, net mei in gids skreaun foar in oare distribúsje.
Set de listener en de útgeande boarne los faninoar
Nim in host waans LAN-adres 192.168.50.10 is en waans tunneladres 10.90.0.3 is. As LAN-kliïnten de proxy berikke moatte wylst har oanfragen troch de tunnel nei bûten geane, binne dat twa ûnôfhinklike besluten en beide moatte opskreaun wurde. It stik hjirûnder sprekt krekt dat út en neat oars.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noDat is gjin folsleine konfiguraasje, hâld dus de goedkarde poarte, de autentikaasje, de tagongskontrôles fan kliïnten en de beheiningen fan bestimmingen. Beide adressen moatte yn ’e netwurknammeromte fan Tinyproxy by dizze host hearre, want in Bind-wearde dy’t it proses net besitte kin, mislearret by it ferbinen, net by it opstarten. BindSame yes beskriuwt in oar belied, wêrby’t it lokale adres fan ’e akseptearre ferbining de útgeande boarne wurdt. Yn aktuele útjeften hat dy tûke foarrang boppe de Bind-list, en sa ferdwynt in konfigurearre boarne sûnder flaters.
Kontrolearje de rûte dy’t de boarne ferûnderstelt
In boarreadres kieze makket gjin paad, freegje de kernel dus wat er mei dy boarne en dy bestimming dwaan soe. In sykjen dat de tunnelinterface neamt is it minimale bewiis, en ien dat de LAN-interface neamt betsjut dat de boarne sa net wurkje kin. It sykjen is kontekstueel: it beoardielet de beliedsregels en de tabel dy’t foar dy nammeromte jilde. It is gjin ferbining, en it seit neat oer wat in leger lizzende NAT oan ’e tsjinst presintearret.
ip -4 route get 203.0.113.25 from 10.90.0.3Brûk in dokumintaasje-adres yn it foarbyld en ferfange it troch de tsjinst dy’t jo teste meie. Rin it sykjen binnen de nammeromte fan ’e proxy as de proxy yn in kontener draait, want de regels fan ’e host binne net de regels dy’t it proses sjocht. As de bedoelde tunnelrûte ûntbrekt, lit de netwurkeigner dat reparearje ynstee fan bestimmingspesifike regels oan ’e proxy-host ta te foegjen. Meitsje gjin hostrûtes skjin en skeakelje gjin troch de tsjinner skode rûtes út om in sykjen te litten slagjen, ek al die in âldere gids dat, want sokke feroarings ferpleatse it hiele goedkarde VPN-gedrach fan ’e host om ien proxypaad te reparearjen.
Befêstigje de boarne by de bestimming
Lês de boarne dêr’t de oanfraach oankomt, net dêr’t er fuortgiet. It applikaasjeloch fan ’e bestimming, of it rântapparaat derfoar, registrearret it adres dat it wier seach, wylst de proxy jo allinne sizze kin wat er fan doel wie. Doch nei de feroaring ien nije oanfraach fia de bedoelde listener, want in cache ferbining bewiist neat oer de nije bining. Fergelykje dan dat registrearre adres mei dat jo konfigurearre hawwe.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl is allinnich de ferkearsgenerator; it adres dat it ferifiearjen wurdich is, is dat wat de fiere kant registrearre hat, net de peer dêr’t curl tafallich mei ferbûn wie. As de twa it net iens binne, beslute dan oft it ferskil fan boarnekar of fan fierdere oersetting komt, want dy wurde op ferskillende plakken reparearre. Plan adresferoarings en proxywerstartings tegearre, want it binen fan in adres dat de tunnel net mear hat mislearret stil nei in werferbining. Definiearje ek it gedrach fan DNS en IPv6 apart, want it IPv4-stik hjirboppe bewiist neat oer ien fan beide.