Listen, Bind i BindSame u Tinyproxyju: koja adresa pobjeđuje
Listen bira adresu koja prihvata klijente, Bind bira izvor za odlazne veze. Nijedna ne postavlja rutu, pa put provjerite zasebno.
Proksi odgovara, zahtjev se završava, a odredište i dalje bilježi LAN adresu. Ništa u dnevniku proksija ne izgleda pogrešno, a linija koju ste promijenili upravo je ona koju je dokumentacija rekla da promijenite. Na hostu koji ima i LAN adresu i adresu tunela, tri direktive odlučuju koja se adresa gdje pojavljuje, a samo jedna od njih tiče se odlazne strane. Ako ih čitate pogrešnim redoslijedom, bez razloga završite u tablici rutiranja.
Simptom: odredište vidi LAN adresu
Klijent se povezuje s proksijem na LAN adresi, a proksi otvara vlastitu vezu prema odredištu. Ta druga veza bira izvornu adresu po pravilima kernela, a po defaultu je to ono što odabere pretraga rute. Zato odredište bilježi primarnu adresu hosta iako je svaki bajt prošao kroz proksi. U smislu prosljeđivanja ništa nije pokvareno, i zato dnevnik proksija o tome nema šta reći.
Zrcalna verzija te greške lakše se uočava: prikujte odlazni izvor na adresu tunela i LAN klijenti uopće prestaju dolaziti do slušača. Ta verzija se sama objavljuje, dok se prva skriva iza zahtjeva koji radi. Obje dolaze od toga da se jedna direktiva tretira kao da odgovara na oba pitanja.
Tri direktive, tri različite adrese
Listen imenuje lokalnu adresu koja prihvata klijente proksija. Bind daje izvornu adresu za veze koje proksi uspostavlja prema van, a BindSame mu nalaže da ponovo upotrijebi lokalnu adresu veze koju je upravo prihvatio. To su tri odvojena pitanja, a jedna linija odgovara samo na jedno od njih. Miješanje tih pitanja uobičajen je razlog zašto promjena izgleda bez učinka.
| 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 |
Pročitajte komentarisanu konfiguraciju koja se isporučuje s instaliranom verzijom, jer se defaultne vrijednosti i prihvaćena sintaksa mijenjaju između izdanja. primjer konfiguracije projekta dokumentuje svaku direktivu uz ostale. Uporedite tu datoteku s onom na disku, a ne s vodičem napisanim za drugu distribuciju.
Postavite slušač i odlazni izvor neovisno
Uzmite host čija je LAN adresa 192.168.50.10, a adresa tunela 10.90.0.3. Ako LAN klijenti treba da dosegnu proksi, a njihovi zahtjevi da izađu kroz tunel, to su dvije neovisne odluke i obje moraju biti zapisane. Fragment ispod izražava tačno to i ništa drugo.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noTo nije potpuna konfiguracija, zato zadržite odobreni port, autentikaciju, kontrolu pristupa klijenata i ograničenja odredišta. Obje adrese moraju pripadati ovom hostu unutar mrežnog imenskog prostora proksija, jer vrijednost Bind koju proces ne može posjedovati pada pri povezivanju, a ne pri pokretanju. BindSame yes opisuje drugačiju politiku, gdje lokalna adresa prihvaćene veze postaje odlazni izvor. U aktualnim izdanjima ta grana ima prednost nad listom Bind, i tako konfigurisani izvor nestaje bez greške.
Provjerite rutu koju izvor podrazumijeva
Odabir izvorne adrese ne stvara put, zato pitajte kernel šta bi učinio s tim izvorom i tim odredištem. Pretraga koja imenuje sučelje tunela minimalni je dokaz, a ona koja imenuje LAN sučelje znači da izvor ne može raditi kako je napisan. Pretraga je kontekstualna: ocjenjuje pravila politike i tablicu koja važi za taj imenski prostor. To nije veza i ne kaže ništa o tome šta će nizvodni NAT predstaviti usluzi.
ip -4 route get 203.0.113.25 from 10.90.0.3U primjeru koristite dokumentacijsku adresu i zamijenite je uslugom koju imate ovlaštenje testirati. Pokrenite pretragu unutar imenskog prostora proksija kad proksi radi u kontejneru, jer pravila hosta nisu pravila koja proces vidi. Kad namjeravana ruta tunela nedostaje, neka je mrežni vlasnik popravi umjesto da na host proksija dodajete pravila specifična za odredište. Ne čistite rute hosta i ne isključujte rute koje server gura da bi pretraga uspjela, čak i ako je stariji vodič to činio, jer takve promjene pomjeraju cjelokupno odobreno VPN ponašanje hosta da bi popravile jedan put proksija.
Potvrdite izvor na odredištu
Čitajte izvor tamo gdje zahtjev stiže, a ne odakle odlazi. Dnevnik aplikacije na odredištu ili rubni uređaj ispred njega bilježi adresu koju je zaista vidio, dok vam proksi može reći samo šta je namjeravao. Nakon promjene pošaljite jedan novi zahtjev kroz namjeravani slušač, jer keširana veza ništa ne dokazuje o novom povezivanju. Zatim uporedite zabilježenu adresu s onom koju ste konfigurisali.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl je samo generator saobraćaja; adresa koju vrijedi provjeriti je ona koju je zabilježila daleka strana, a ne peer s kojim se curl slučajno spojio. Ako se dvije ne slažu, odredite dolazi li razlika od odabira izvora ili od prevođenja dalje na putu, jer se to popravlja na različitim mjestima. Planirajte promjene adresa i restarte proksija zajedno, jer povezivanje s adresom koju tunel više ne drži tiho pada nakon ponovnog spajanja. Definišite i ponašanje DNS-a i IPv6 odvojeno, jer fragment za IPv4 iznad ne dokazuje ništa ni o jednom od njih.