Listen, Bind ja BindSame Tinyproxyssa: mikä osoite voittaa
Listen valitsee osoitteen, joka vastaanottaa asiakkaat, Bind valitsee lähteen lähteville yhteyksille. Kumpikaan ei asenna reittiä, joten tarkista polku erikseen.
Välityspalvelin vastaa, pyyntö valmistuu, ja silti kohde kirjaa edelleen LAN-osoitteen. Mikään välityspalvelimen lokissa ei näytä väärältä, ja muuttamasi rivi on juuri se, jonka dokumentaatio käski muuttaa. Isännällä, jolla on sekä LAN-osoite että tunneliosoite, kolme direktiiviä päättää, mikä osoite näkyy missä, ja vain yksi niistä koskee lähtevää puolta. Jos luet ne väärässä järjestyksessä, päädyt ilman syytä reititystauluun.
Oire: kohde näkee LAN-osoitteen
Asiakas yhdistää välityspalvelimeen LAN-osoitteessa, ja välityspalvelin avaa oman yhteytensä kohteeseen. Tämä toinen yhteys valitsee lähdeosoitteen ytimen sääntöjen mukaan, ja oletuksena se on se, jonka reittihaku valitsee. Siksi kohde kirjaa isännän ensisijaisen osoitteen, vaikka jokainen tavu kulki välityspalvelimen kautta. Edelleenlähetyksen kannalta mikään ei ole rikki, ja siksi välityspalvelimen lokilla ei ole siitä mitään sanottavaa.
Tämän vian peilikuva on helpompi havaita: kiinnitä lähtevä lähde tunneliosoitteeseen, niin LAN-asiakkaat eivät enää tavoita kuuntelijaa lainkaan. Se versio ilmoittaa itsestään, kun taas ensimmäinen piiloutuu toimivan pyynnön taakse. Molemmat johtuvat siitä, että yhtä direktiiviä kohdellaan kuin se vastaisi molempiin kysymyksiin.
Kolme direktiiviä, kolme eri osoitetta
Listen nimeää paikallisen osoitteen, joka vastaanottaa välityspalvelimen asiakkaita. Bind antaa lähdeosoitteen yhteyksille, joita välityspalvelin tekee ulospäin, ja BindSame käskee sitä käyttämään uudelleen juuri vastaanotetun yhteyden paikallista osoitetta. Nämä ovat kolme erillistä kysymystä, ja yksi rivi vastaa vain yhteen niistä. Niiden sekoittaminen on tavallinen syy siihen, että muutos näyttää tekevän ei mitään.
| 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 |
Lue asennetun version mukana toimitettava kommentoitu kokoonpano, koska oletusarvot ja hyväksytty syntaksi muuttuvat julkaisujen välillä. Projektin esimerkkikokoonpano dokumentoi jokaisen direktiivin muiden vieressä. Vertaa sitä tiedostoa levyllä olevaan, älä toiselle jakelulle kirjoitettuun oppaaseen.
Aseta kuuntelija ja lähtevä lähde toisistaan riippumatta
Ota isäntä, jonka LAN-osoite on 192.168.50.10 ja tunneliosoite 10.90.0.3. Jos LAN-asiakkaiden pitää tavoittaa välityspalvelin ja heidän pyyntöjensä lähteä tunnelista, kyse on kahdesta riippumattomasta päätöksestä ja molemmat on kirjattava. Alla oleva katkelma ilmaisee juuri sen eikä mitään muuta.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noTämä ei ole täydellinen kokoonpano, joten säilytä hyväksytty portti, todennus, asiakkaiden pääsynvalvonta ja kohderajoitukset. Molempien osoitteiden on kuuluttava tälle isännälle Tinyproxyn verkkonimiavaruuden sisällä, koska Bind-arvo, jota prosessi ei voi omistaa, epäonnistuu yhdistettäessä, ei käynnistyksessä. BindSame yes kuvaa toisen käytännön, jossa vastaanotetun yhteyden paikallinen osoite tulee lähteväksi lähteeksi. Nykyisissä julkaisuissa tällä haaralla on etusija Bind-luetteloon nähden, ja näin konfiguroitu lähde katoaa ilman virhettä.
Tarkista reitti, jonka lähde edellyttää
Lähdeosoitteen valitseminen ei luo polkua, joten kysy ytimeltä, mitä se tekisi tällä lähteellä ja tällä kohteella. Haku, joka nimeää tunnelin rajapinnan, on vähimmäistodiste, ja se, joka nimeää LAN-rajapinnan, tarkoittaa, ettei lähde voi toimia kirjoitetusti. Haku on kontekstisidonnainen: se arvioi käytännön säännöt ja taulun, jotka ovat voimassa kyseisessä nimiavaruudessa. Se ei ole yhteys eikä kerro mitään siitä, mitä alempana oleva NAT esittää palvelulle.
ip -4 route get 203.0.113.25 from 10.90.0.3Käytä esimerkissä dokumentaatio-osoitetta ja korvaa se palvelulla, jonka testaamiseen sinulla on lupa. Suorita haku välityspalvelimen nimiavaruuden sisällä, kun välityspalvelin on kontissa, koska isännän säännöt eivät ole ne säännöt, jotka prosessi näkee. Kun aiottu tunnelireitti puuttuu, anna verkon omistajan korjata se sen sijaan, että lisäät kohdekohtaisia sääntöjä välityspalvelimen isäntään. Älä tyhjennä isännän reittejä äläkä poista palvelimen työntämiä reittejä haun onnistumiseksi, vaikka vanhempi opas niin tekikin, koska sellaiset muutokset siirtävät koko isännän hyväksytyn VPN-käyttäytymisen yhden välityspolun korjaamiseksi.
Vahvista lähde kohteessa
Lue lähde siellä, missä pyyntö saapuu, ei missä se lähtee. Kohteen sovellusloki tai sen edessä oleva reunalaite kirjaa osoitteen, jonka se todella näki, kun taas välityspalvelin voi kertoa vain aikomuksensa. Tee muutoksen jälkeen yksi tuore pyyntö aiotun kuuntelijan kautta, koska välimuistiin jäänyt yhteys ei todista mitään uudesta sidonnasta. Vertaa sitten kirjattua osoitetta konfiguroimaasi.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl on vain liikenteen tuottaja; tarkistamisen arvoinen osoite on se, jonka kaukopää kirjasi, ei se vastapuoli, johon curl sattui yhdistämään. Jos ne eroavat, selvitä johtuuko ero lähdevalinnasta vai myöhemmästä muunnoksesta, koska ne korjataan eri paikoissa. Suunnittele osoitemuutokset ja välityspalvelimen uudelleenkäynnistykset yhdessä, koska sellaisen osoitteen sitominen, jota tunnelilla ei enää ole, epäonnistuu hiljaa uudelleenyhdistämisen jälkeen. Määrittele myös DNS- ja IPv6-käyttäytyminen erikseen, koska yllä oleva IPv4-katkelma ei todista kummastakaan mitään.