Listen, Bind ja BindSame Tinyproxy seadistuses: milline aadress võidab
Listen valib aadressi, mis võtab kliente vastu, Bind valib väljuvate ühenduste lähteaadressi. Kumbki ei paigalda marsruuti, seega kontrollige teed eraldi.
Puhverserver vastab, päring lõpeb, ja ometi märgib sihtkoht endiselt LAN-i aadressi. Puhverserveri logis ei paista miski valesti ja muudetud rida on täpselt see, mida dokumentatsioon käskis muuta. Hostil, millel on nii LAN-i kui ka tunneliaadress, otsustavad kolm direktiivi, milline aadress kus ilmub, ja neist ainult üks puudutab väljuvat poolt. Valges järjekorras lugedes satute põhjuseta marsruutimistabelisse.
Sümptom: sihtkoht näeb LAN-i aadressi
Klient ühendub puhverserveriga LAN-i aadressil ja puhverserver avab oma ühenduse sihtkohani. See teine ühendus valib lähteaadressi kerneli reeglite järgi ja vaikimisi on selleks see, mille valib marsruudiotsing. Seetõttu märgib sihtkoht hosti esmase aadressi, kuigi iga bait läbis puhverserveri. Edasisaatmise mõttes pole miski katki ja seetõttu ei ole puhverserveri logil selle kohta midagi öelda.
Selle vea peegelpilt on kergemini märgatav: kinnitage väljuv lähteaadress tunneliaadressi külge ja LAN-i kliendid ei jõua enam üldse kuulajani. See versioon teavitab endast ise, esimene peidab end töötava päringu taga. Mõlemad tulenevad sellest, et üht direktiivi koheldakse nii, nagu vastaks see mõlemale küsimusele.
Kolm direktiivi, kolm erinevat aadressi
Listen nimetab kohaliku aadressi, mis võtab puhverserveri kliente vastu. Bind annab lähteaadressi ühendustele, mille puhverserver väljapoole loob, ja BindSame käsib tal uuesti kasutada äsja vastuvõetud ühenduse kohalikku aadressi. Need on kolm eraldi küsimust ja üks rida vastab ainult ühele neist. Nende segiajamine on tavaline põhjus, miks muudatus näib mitte midagi tegevat.
| 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 |
Lugege paigaldatud versiooniga kaasas olevat kommenteeritud konfiguratsiooni, sest vaikeväärtused ja aktsepteeritud süntaks muutuvad väljaannete vahel. Projekti näidiskonfiguratsioon dokumenteerib iga direktiivi teiste kõrval. Võrrelge seda faili kettal olevaga, mitte mõne teise distributsiooni jaoks kirjutatud juhendiga.
Seadistage kuulaja ja väljuv lähteaadress sõltumatult
Võtke host, mille LAN-i aadress on 192.168.50.10 ja tunneliaadress 10.90.0.3. Kui LAN-i kliendid peavad puhverserverini jõudma, samal ajal kui nende päringud väljuvad tunnelist, on need kaks sõltumatut otsust ja mõlemad tuleb kirja panna. Allolev fragment väljendab täpselt seda ega midagi muud.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noSee ei ole täielik konfiguratsioon, seega jätke alles kinnitatud port, autentimine, klientide juurdepääsukontroll ja sihtkoha piirangud. Mõlemad aadressid peavad kuuluma sellele hostile Tinyproxy võrgu nimeruumi sees, sest Bind-i väärtus, mida protsess omada ei saa, ebaõnnestub ühendamisel, mitte käivitamisel. BindSame yes kirjeldab teist poliitikat, kus vastuvõetud ühenduse kohalik aadress saab väljuvaks lähteks. Praegustes väljaannetes on sellel harul Bind-i nimekirja ees prioriteet ja nõnda kaob seadistatud lähteaadress veateateta.
Kontrollige marsruuti, mida lähteaadress eeldab
Lähteaadressi valimine ei loo teed, seega küsige kernelilt, mida see selle lähte ja sihtkohaga teeks. Otsing, mis nimetab tunneli liidest, on minimaalne tõend, ja see, mis nimetab LAN-i liidest, tähendab, et lähteaadress ei saa kirjutatud kujul töötada. Otsing on kontekstipõhine: see hindab poliitikareegleid ja tabelit, mis selle nimeruumi jaoks kehtivad. See ei ole ühendus ega ütle midagi selle kohta, mida allavoolu NAT teenusele esitab.
ip -4 route get 203.0.113.25 from 10.90.0.3Kasutage näites dokumentatsiooni aadressi ja asendage see teenusega, mida teil on lubatud testida. Käivitage otsing puhverserveri nimeruumi sees, kui puhverserver töötab konteineris, sest hosti reeglid ei ole need reeglid, mida protsess näeb. Kui kavandatud tunnelimarsruut puudub, laske võrgu omanikul see korda teha, selle asemel et lisada puhverserveri hostile sihtkohapõhiseid reegleid. Ärge kustutage hosti marsruute ega lülitage välja serveri lükatavaid marsruute, et otsing õnnestuks, isegi kui vanem juhend seda tegi, sest sellised muudatused nihutavad kogu hosti kinnitatud VPN-käitumist, et parandada üks puhverserveri tee.
Kinnitage lähteaadress sihtkohas
Lugege lähtekohta seal, kuhu päring saabub, mitte seal, kust see lahkub. Sihtkoha rakenduse logi või selle ees olev servaseade märgib aadressi, mida see tegelikult nägi, samal ajal kui puhverserver saab teile öelda ainult oma kavatsust. Tehke pärast muudatust üks värske päring kavandatud kuulaja kaudu, sest vahemällu jäänud ühendus ei tõesta uue sidumise kohta midagi. Seejärel võrrelge märgitud aadressi seadistatud aadressiga.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl on ainult liikluse generaator; aadress, mida tasub kontrollida, on see, mille kaugem pool logis, mitte partner, millega curl juhuslikult ühendus. Kui need kaks lahknevad, otsustage, kas erinevus tuleb lähte valikust või edasisest teisendusest, sest neid parandatakse eri kohtades. Planeerige aadressimuudatused ja puhverserveri taaskäivitused koos, sest aadressi sidumine, mida tunnel enam ei hoia, ebaõnnestub pärast taasühendamist vaikselt. Määratlege ka DNS-i ja IPv6 käitumine eraldi, sest ülalolev IPv4 fragment ei tõesta kummagi kohta midagi.