Listen, Bind kaj BindSame en Tinyproxy: kiu adreso venkas
Listen elektas la adreson, kiu akceptas klientojn, Bind elektas la fonton por elirantaj konektoj. Neniu el ili instalas itineron, do kontrolu la vojon aparte.
La prokuro respondas, la peto kompletiĝas, kaj tamen la celo ankoraŭ registras la LAN-adreson. Nenio en la protokolo de la prokuro aspektas malĝuste, kaj la linio, kiun vi ŝanĝis, estas ĝuste tiu, kiun la dokumentaro diris ŝanĝi. Sur gastiganto kun kaj LAN-adreso kaj tunela adreso, tri direktivoj decidas, kiu adreso aperas kie, kaj nur unu el ili temas pri la elira flanko. Se vi legas ilin en malĝusta ordo, vi senkaŭze eniras la enkursigan tabelon.
La simptomo: la celo vidas la LAN-adreson
Kliento konektiĝas al la prokuro ĉe la LAN-adreso, kaj la prokuro malfermas sian propran konekton al la celo. Tiu dua konekto elektas fontan adreson laŭ la reguloj de la kerno, kaj defaŭlte ĝi estas tio, kion elektas la itinera serĉo. La celo do registras la primaran adreson de la gastiganto, kvankam ĉiu bajto pasis tra la prokuro. Laŭ plusenda senco nenio rompiĝis, kaj tial la protokolo de la prokuro havas nenion por diri pri tio.
La spegula bildo de tiu fuŝo estas pli facile rimarkebla: fiksu la eliran fonton al la tunela adreso kaj la LAN-klientoj tute ĉesas atingi la aŭskultanton. Tiu versio anoncas sin mem, dum la unua kaŝiĝas malantaŭ funkcianta peto. Ambaŭ venas de tio, ke oni traktas unu direktivon kvazaŭ ĝi respondus al ambaŭ demandoj.
Tri direktivoj, tri malsamaj adresoj
Listen nomas la lokan adreson, kiu akceptas la klientojn de la prokuro. Bind donas fontan adreson por la konektoj, kiujn la prokuro faras eksteren, kaj BindSame ordonas al ĝi reuzi la lokan adreson de la konekto, kiun ĝi ĵus akceptis. Tiuj estas tri apartaj demandoj, kaj unu linio respondas nur al unu el ili. Konfuzi ilin estas la kutima kialo, ke ŝanĝo ŝajnas fari nenion.
| 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 |
Legu la komentitan agordon liveritan kun la instalita versio, ĉar defaŭltoj kaj akceptata sintakso moviĝas inter eldonoj. La ekzempla agordo de la projekto dokumentas ĉiun direktivon apud la aliaj. Komparu tiun dosieron kun tiu sur la disko, ne kun gvidilo verkita por alia distribuo.
Agordu la aŭskultanton kaj la eliran fonton sendepende
Prenu gastiganton, kies LAN-adreso estas 192.168.50.10 kaj kies tunela adreso estas 10.90.0.3. Se LAN-klientoj devas atingi la prokuron dum iliaj petoj eliras el la tunelo, temas pri du sendependaj decidoj kaj ambaŭ devas esti skribitaj. La suba fragmento esprimas ĝuste tion kaj nenion alian.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noTio ne estas kompleta agordo, do konservu la aprobitan pordon, la aŭtentigon, la klientajn alirregulojn kaj la celajn limigojn. Ambaŭ adresoj devas aparteni al ĉi tiu gastiganto ene de la reta nomspaco de Tinyproxy, ĉar Bind-valoro, kiun la procezo ne povas posedi, malsukcesas ĉe konekto, ne ĉe starto. BindSame yes priskribas alian politikon, kie la loka adreso de la akceptita konekto fariĝas la elira fonto. En nunaj eldonoj tiu branĉo havas prioritaton super la Bind-listo, kaj tiel agordita fonto malaperas sen eraro.
Kontrolu la itineron, kiun la fonto implicas
Elekti fontan adreson ne kreas vojon, do demandu la kernon, kion ĝi farus kun tiu fonto kaj tiu celo. Serĉo, kiu nomas la tunelan interfacon, estas la minimuma pruvo, kaj tiu, kiu nomas la LAN-interfacon, signifas, ke la fonto ne povas funkcii tiel, kiel skribite. La serĉo estas kunteksta: ĝi taksas la politikajn regulojn kaj la tabelon validajn por tiu nomspaco. Ĝi ne estas konekto, kaj ĝi diras nenion pri tio, kion malsupra NAT prezentos al la servo.
ip -4 route get 203.0.113.25 from 10.90.0.3Uzu dokumentaran adreson en la ekzemplo kaj anstataŭigu ĝin per la servo, kiun vi rajtas testi. Rulu la serĉon ene de la nomspaco de la prokuro, kiam la prokuro funkcias en ujo, ĉar la reguloj de la gastiganto ne estas la reguloj, kiujn la procezo vidas. Kiam la intencita tunela itinero mankas, lasu la retan posedanton ripari ĝin anstataŭ aldoni cel-specifajn regulojn al la prokura gastiganto. Ne forviŝu gastigantajn itinerojn kaj ne malŝaltu servile puŝitajn itinerojn por sukcesigi serĉon, eĉ se pli malnova gvidilo tion faris, ĉar tiaj ŝanĝoj movas la tutan aprobitan VPN-konduton de la gastiganto por ripari unu prokuran vojon.
Konfirmu la fonton ĉe la celo
Legu la fonton tie, kie la peto alvenas, ne kie ĝi foriras. La aplikaĵa protokolo de la celo, aŭ la randa aparato antaŭ ĝi, registras la adreson, kiun ĝi efektive vidis, dum la prokuro povas nur diri al vi, kion ĝi intencis. Faru unu novan peton tra la intencita aŭskultanto post la ŝanĝo, ĉar kaŝmemora konekto pruvas nenion pri la nova ligo. Poste komparu tiun registritan adreson kun tiu, kiun vi agordis.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl estas nur la trafika generatoro; la adreso inda je kontrolo estas tiu, kiun registris la malproksima flanko, ne la samtavolano, al kiu curl hazarde konektiĝis. Se la du malkongruas, decida ĉu la diferenco venas de fonta elekto aŭ de traduko pli antaŭen, ĉar tiuj ripariĝas en malsamaj lokoj. Planu adresajn ŝanĝojn kaj prokurajn restartojn kune, ĉar ligi adreson, kiun la tunelo ne plu tenas, malsukcesas silente post rekonekto. Difinu ankaŭ la konduton de DNS kaj IPv6 aparte, ĉar la supra IPv4-fragmento pruvas nenion pri iu ajn el ili.