Listen, Bind és BindSame a Tinyproxyban: melyik cím győz
A Listen azt a címet választja, amely a klienseket fogadja, a Bind a kimenő kapcsolatok forrását. Egyik sem telepít útvonalat, ezért az útvonalat külön ellenőrizze.
A proxy válaszol, a kérés lefut, és mégis a cél továbbra is a LAN-címet rögzíti. A proxy naplójában semmi sem tűnik hibásnak, és a módosított sor pontosan az, amit a dokumentáció módosítani kért. Egy olyan gazdagépen, amelynek LAN-címe és alagútcíme is van, három direktíva dönti el, melyik cím hol jelenik meg, és közülük csak egy érinti a kimenő oldalt. Rossz sorrendben olvasva ok nélkül az útválasztási táblában köt ki.
A tünet: a cél a LAN-címet látja
Egy kliens a LAN-címen kapcsolódik a proxyhoz, a proxy pedig megnyitja saját kapcsolatát a cél felé. Ez a második kapcsolat a kernel szabályai szerint választ forráscímet, és alapértelmezés szerint az lesz, amelyet az útvonalkeresés kiválaszt. A cél ezért a gazdagép elsődleges címét rögzíti, pedig minden bájt a proxyn ment át. Továbbítás szempontjából semmi sem tört el, és ezért a proxy naplójának nincs mit mondania róla.
A hiba tükörképe könnyebben észrevehető: rögzítse a kimenő forrást az alagútcímhez, és a LAN-kliensek egyáltalán nem érik el a figyelőt. Az a változat magától jelzi a bajt, míg az első egy működő kérés mögé bújik. Mindkettő abból ered, hogy egy direktívát úgy kezelünk, mintha mindkét kérdésre válaszolna.
Három direktíva, három különböző cím
A Listen megnevezi azt a helyi címet, amely a proxy klienseit fogadja. A Bind forráscímet ad a proxy kifelé épített kapcsolataihoz, a BindSame pedig arra utasítja, hogy használja újra az éppen elfogadott kapcsolat helyi címét. Ez három külön kérdés, és egyetlen sor csak egyre válaszol. Összekeverésük a szokásos oka annak, hogy egy módosítás hatástalannak látszik.
| 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 |
Olvassa el a telepített verzióhoz mellékelt kommentált konfigurációt, mert az alapértékek és az elfogadott szintaxis kiadásról kiadásra változik. A projekt példakonfigurációja minden direktívát a többi mellett dokumentál. Hasonlítsa össze azt a fájlt a lemezen lévővel, ne egy másik disztribúcióhoz írt útmutatóval.
Állítsa be a figyelőt és a kimenő forrást egymástól függetlenül
Vegyen egy gazdagépet, amelynek LAN-címe 192.168.50.10, alagútcíme pedig 10.90.0.3. Ha a LAN-klienseknek el kell érniük a proxyt, miközben kéréseik az alagúton keresztül távoznak, az két független döntés, és mindkettőt le kell írni. Az alábbi részlet pontosan ezt fejezi ki, és semmi mást.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noEz nem teljes konfiguráció, ezért tartsa meg az engedélyezett portot, a hitelesítést, a kliens-hozzáférési szabályokat és a célkorlátozásokat. Mindkét címnek ehhez a gazdagéphez kell tartoznia a Tinyproxy hálózati névterében, mert az a Bind-érték, amelyet a folyamat nem tud birtokolni, kapcsolódáskor bukik el, nem indításkor. A BindSame yes más irányelvet ír le, ahol az elfogadott kapcsolat helyi címe lesz a kimenő forrás. A jelenlegi kiadásokban ez az ág elsőbbséget élvez a Bind listával szemben, és így tűnik el egy beállított forrás hibaüzenet nélkül.
Ellenőrizze az útvonalat, amelyet a forrás feltételez
A forráscím kiválasztása nem hoz létre útvonalat, ezért kérdezze meg a kernelt, mit tenne ezzel a forrással és ezzel a céllal. Az a keresés, amely az alagút interfészét nevezi meg, a minimális bizonyíték, és amelyik a LAN interfészét nevezi meg, azt jelenti, hogy a forrás így nem működhet. A keresés kontextusfüggő: kiértékeli az adott névtérben érvényes házirend-szabályokat és táblát. Ez nem kapcsolat, és semmit sem mond arról, mit mutat majd egy lejjebbi NAT a szolgáltatásnak.
ip -4 route get 203.0.113.25 from 10.90.0.3A példában használjon dokumentációs címet, és helyettesítse be azt a szolgáltatást, amelynek tesztelésére jogosult. A keresést a proxy névterében futtassa, amikor a proxy konténerben fut, mert a gazdagép szabályai nem azok a szabályok, amelyeket a folyamat lát. Ha a tervezett alagútútvonal hiányzik, a hálózat tulajdonosa javítsa ki, ahelyett hogy célspecifikus szabályokat adna a proxy gazdagépéhez. Ne törölje a gazdagép útvonalait, és ne kapcsolja ki a kiszolgáló által küldött útvonalakat azért, hogy egy keresés sikerüljön, még ha egy régebbi útmutató így tett is, mert az ilyen változtatások az egész gazdagép jóváhagyott VPN-viselkedését mozgatják meg egyetlen proxyútvonal javításáért.
Erősítse meg a forrást a célnál
A forrást ott olvassa, ahová a kérés megérkezik, nem ahonnan elindul. A cél alkalmazásnaplója vagy az előtte lévő peremeszköz azt a címet rögzíti, amelyet valóban látott, míg a proxy csak a szándékáról tud beszélni. A módosítás után indítson egy friss kérést a tervezett figyelőn keresztül, mert egy gyorsítótárazott kapcsolat semmit sem bizonyít az új kötésről. Ezután hasonlítsa össze a rögzített címet a beállított címmel.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sSA curl csak a forgalomgenerátor; az ellenőrzésre érdemes cím az, amelyet a távoli oldal naplózott, nem az a partner, amelyhez a curl véletlenül kapcsolódott. Ha a kettő nem egyezik, döntse el, hogy a különbség a forrásválasztásból vagy egy későbbi átalakításból ered, mert ezeket más helyen javítják. Tervezze együtt a címváltozásokat és a proxy újraindításait, mert egy olyan cím kötése, amellyel az alagút már nem rendelkezik, újracsatlakozás után csendben meghiúsul. A DNS és az IPv6 viselkedését is külön határozza meg, mert a fenti IPv4-részlet egyikről sem bizonyít semmit.