Listen, Bind dhe BindSame në Tinyproxy: cila adresë fiton

Proksi përgjigjet, kërkesa përfundon dhe, megjithatë, destinacioni vazhdon të regjistrojë adresën e LAN-it. Asgjë në regjistrin e proksit nuk duket gabim, dhe rreshti që ndryshuat është pikërisht ai që dokumentacioni ju tha të ndryshonit. Në një host me adresë LAN dhe adresë tuneli, tre direktiva vendosin cila adresë shfaqet ku, dhe vetëm njëra prej tyre ka të bëjë me anën dalëse. Leximi në rendin e gabuar ju çon në tabelën e rrugëzimit pa arsye.

Simptoma: destinacioni sheh adresën e LAN-it

Një klient lidhet me proksin në adresën e LAN-it, dhe proksi hap lidhjen e vet drejt destinacionit. Ajo lidhje e dytë zgjedh një adresë burimi sipas rregullave të kernelit dhe, si parazgjedhje, është ajo që zgjedh kërkimi i rrugës. Prandaj destinacioni regjistron adresën parësore të hostit, ndonëse çdo bajt kaloi përmes proksit. Nga ana e përcjelljes asgjë nuk është prishur, dhe për këtë arsye regjistri i proksit nuk ka çfarë të thotë.

Pasqyra e këtij defekti është më e lehtë për t’u parë: fiksoni burimin dalës në adresën e tunelit dhe klientët e LAN-it nuk arrijnë fare te dëgjuesi. Ajo version njofton vetveten, ndërsa i pari fshihet pas një kërkese që funksionon. Të dyja vijnë nga trajtimi i një direktive sikur të përgjigjej për të dyja pyetjet.

Tre direktiva, tre adresa të ndryshme

Listen emërton adresën lokale që pranon klientët e proksit. Bind siguron një adresë burimi për lidhjet që proksi krijon jashtë, dhe BindSame i thotë të ripërdorë adresën lokale të lidhjes që sapo pranoi. Këto janë tre pyetje të ndara, dhe një rresht i përgjigjet vetëm njërës. Përzierja e tyre është arsyeja e zakonshme pse një ndryshim duket se nuk bën asgjë.

Lexoni konfigurimin e komentuar që vjen me versionin e instaluar, sepse vlerat e parazgjedhura dhe sintaksa e pranuar ndryshojnë midis botimeve. Konfigurimi shembull i projektit dokumenton çdo direktivë pranë të tjerave. Krahasoni atë skedar me atë në disk, jo me një udhëzues të shkruar për një shpërndarje tjetër.

Vendosni dëgjuesin dhe burimin dalës veçmas

Merrni një host, adresa e LAN-it e të cilit është 192.168.50.10 dhe adresa e tunelit 10.90.0.3. Nëse klientët e LAN-it duhet të arrijnë proksin ndërsa kërkesat e tyre dalin përmes tunelit, këto janë dy vendime të pavarura dhe të dyja duhet të shkruhen. Fragmenti më poshtë shpreh pikërisht këtë dhe asgjë tjetër.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Ky nuk është një konfigurim i plotë, prandaj mbani portën e miratuar, vërtetimin, kontrollet e aksesit të klientëve dhe kufizimet e destinacionit. Të dyja adresat duhet t’i përkasin këtij hosti brenda hapësirës së emrave të rrjetit të Tinyproxy, sepse një vlerë Bind që procesi nuk mund ta zotërojë dështon gjatë lidhjes, jo gjatë nisjes. BindSame yes përshkruan një politikë tjetër, ku adresa lokale e lidhjes së pranuar bëhet burimi dalës. Në botimet aktuale ajo degë ka përparësi ndaj listës Bind, dhe kështu një burim i konfiguruar zhduket pa gabim.

Kontrolloni rrugën që nënkupton burimi

Zgjedhja e një adrese burimi nuk krijon një shteg, prandaj pyesni kernelin çfarë do të bënte me atë burim dhe atë destinacion. Një kërkim që emërton ndërfaqen e tunelit është prova minimale, dhe një që emërton ndërfaqen e LAN-it do të thotë që burimi nuk mund të funksionojë siç është shkruar. Kërkimi është kontekstual: vlerëson rregullat e politikës dhe tabelën në fuqi për atë hapësirë emrash. Nuk është lidhje dhe nuk thotë asgjë për atë që një NAT më tej do t’i paraqesë shërbimit.

ip -4 route get 203.0.113.25 from 10.90.0.3

Përdorni një adresë dokumentacioni në shembull dhe zëvendësojeni me shërbimin që jeni të autorizuar të provoni. Ekzekutoni kërkimin brenda hapësirës së emrave të proksit kur proksi xhiron në një kontejner, sepse rregullat e hostit nuk janë rregullat që sheh procesi. Kur mungon rruga e synuar e tunelit, lëreni pronarin e rrjetit ta rregullojë, në vend që të shtoni rregulla specifike për destinacionin në hostin e proksit. Mos i pastroni rrugët e hostit dhe mos i çaktivizoni rrugët e shtyra nga serveri që një kërkim të ketë sukses, edhe pse një udhëzues më i vjetër e bënte këtë, sepse ndryshime të tilla zhvendosin të gjithë sjelljen e miratuar të VPN-së së hostit për të rregulluar një shteg të proksit.

Konfirmoni burimin në destinacion

Lexoni burimin atje ku kërkesa mbërrin, jo atje nga del. Regjistri i aplikacionit në destinacion, ose pajisja e skajit përpara tij, regjistron adresën që pa vërtet, ndërsa proksi mund t’ju thotë vetëm çfarë synonte. Bëni një kërkesë të re përmes dëgjuesit të synuar pas ndryshimit, sepse një lidhje e ruajtur në memorie nuk provon asgjë për lidhjen e re. Pastaj krahasoni adresën e regjistruar me atë që konfiguruat.

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

curl është vetëm gjeneratori i trafikut; adresa që meriton verifikim është ajo që regjistroi ana e largët, jo pala me të cilën curl u lidh rastësisht. Nëse të dyja nuk përputhen, përcaktoni nëse diferencën e sjell zgjedhja e burimit apo një përkthim më tej, sepse ato rregullohen në vende të ndryshme. Planifikoni bashkë ndryshimet e adresave dhe rinisjet e proksit, sepse lidhja e një adrese që tuneli nuk e mban më dështon në heshtje pas një rilidhjeje. Përcaktoni veçmas edhe sjelljen e DNS-së dhe IPv6-së, sepse fragmenti IPv4 më sipër nuk provon asgjë për asnjërën.