OpenVPN: paikallinen osoite vastaan tunnelin osoite – kaksi eri sokettia
Osoite, joka ottaa yhteyden palvelimeen, ei ole tunnelin sisäinen osoite. Kun local, remote ja nobind luetaan erillisinä rooleina, useimmat bind-virheet selittyvät.
Asiakas kieltäytyy käynnistymästä ja valittaa, ettei voi sitoa paikallista osoitetta, ja ilmeinen korjaus näyttää siltä, että se pitäisi osoittaa tunnelin osoitteeseen, jonka se odottaa saavansa. Se ei voi toimia, ja syy kannattaa ymmärtää: ennen kuin tunneli on olemassa, sisäistä osoitetta ei ole, ja soketin, joka ottaa yhteyden palvelimeen, on oltava olemassa ensin. Mukana on kaksi eri osoitetta, ja vain toinen niistä voidaan valita paikallisesti.
Bind-virhe nimeää paikallisen osoitteen
Kun OpenVPN ilmoittaa, ettei se voi sitoa paikallista osoitetta, se puhuu kuljetussoketista: UDP- tai TCP-päätepisteestä, joka kuljettaa salatun yhteyden vertaiselle.
Nimenomainen local-direktiivi pyytää daemonin sitoa kyseisen soketin tiettyyn paikalliseen osoitteeseen. Osoitteen on oltava olemassa siinä verkon nimiavaruudessa, jossa prosessi toimii, ja sen on oltava osoitettavissa hetkellä, jolloin asiakas käynnistyy.
Julkinen osoite, joka käännetään reitittimessä tai pilven reunassa, ei ole paikallinen osoite, jonka daemon voi sitoa, vaikka se on juuri se osoite, jonka palvelin näkee. Tämä ero selittää, miksi yksi profiili toimii kotona ja epäonnistuu pilvi-instanssissa. Se selittää myös, miksi julkisen osoitteen lisääminen loopback-liitäntään ei auta, koska silloin kuljetus lähtisi osoitteesta, johon verkko ei voi vastata. Lue liitäntäluettelo ennen profiilin muokkaamista.
Mitä local ja remote todella valitsevat
remote nimeää vertaisen, johon otetaan yhteyttä. local sitoo saman soketin lähiön pään. nobind jättää käyttöjärjestelmälle sekä paikallisen osoitteen että portin valinnan, minkä vuoksi kotireitittimien takana olevat asiakkaat toimivat yleensä ilman kumpaakaan direktiiviä.
Kummallakaan direktiivillä ei ole mitään tekemistä tunnelin sisäisen osoitteen kanssa.
Kontissa tai verkon nimiavaruudessa sama sääntö pätee kapeammilla rajoilla: isäntäkoneen osoitteet eivät ole sisällä, joten isännän kokoonpanosta kopioitu local-rivi epäonnistuu täysin eri syystä kuin väärä osoite.
ip -brief address show
ip route get 203.0.113.10Sisäinen osoite tulee palvelimelta
Tunnelin sisäinen osoite neuvotellaan tai osoitetaan sen jälkeen, kun ohjauskanava on muodostettu. Dynaamisessa altaassa palvelin päättää sen yhteyden hetkellä, ja asiakaskohtaisessa kokoonpanossa se voi olla kiinteä identiteettiä kohden.
local-rivin kirjoittaminen sisäisellä osoitteella ei pyydä palvelinta osoittamaan tuota osoitetta. Parhaimmillaan sidonta epäonnistuu; pahimmillaan asiakas löytää saman arvon omaavan liittymättömän isäntäosoitteen ja alkaa käyttää sitä kuljetukseen.
Myös luettavat liitännät ovat erilaisia. ifconfig-parametrit ja altaan kokoonpano kuvaavat sisäpuolta, kun taas remote, local, proto ja nobind kuvaavat ulkopuolta. Kahden luettelon pitäminen erillään selittää lähes jokaisen hämmentävän esimerkin, jonka foorumilta löydät. OpenVPN 2.6 -käsikirja dokumentoi ne erillisissä osioissa juuri tästä syystä.
Ansakuoppa: täysi tunneli, joka vangitsee oman kuljetuksensa
Kun tunneli on ylhäällä ja kantaa oletusreittiä, sitä ylläpitäviä paketteja ei saa reitittää sen sisään. Kyse on reititys- eikä osoiteongelmasta, ja daemon hoitaa sen asentamalla tarkemman reitin palvelimen omaan osoitteeseen alkuperäisen yhdyskäytävän kautta.
Jos kiinnität kuljetuksen tiettyyn paikalliseen osoitteeseen ja muutat myöhemmin sitä polkua, jota osoite käyttää, ulompi yhteys voi eksyä, kun sisäpuoli pysyy määritettynä. Tunneli ilmoittaa edelleen olevansa yhteydessä, koska sisäpuoli on kunnossa. Vain kuljetus on rikki, ja siksi lokit luetaan ristiriitoina.
Oireet näyttävät silloin tunnelilta, joka yhdistyy ja jäätyy, tai tunnelilta, joka yhdistyy uudelleen silmukassa ilman hyödyllistä virhettä. Tarkista reitti vertaisen osoitteeseen ennen kuin tarkistat mitään tunnelin sisältä, ja varmista, että sitomasi paikallinen osoite kuuluu edelleen liitäntään, jota odotit.
Tapa, joka ehkäisee sekaannuksen
Lue jokainen profiilin osoite ja päätä ennen muokkaamista, mihin kerrokseen se kuuluu.
Jos se nimeää kuljetuksen kauimmaisen pään tai sitoo sen lähimmän pään, se on ulkoinen osoite ja sen on oltava olemassa ennen käynnistystä. Jos se kuvaa, mitä tunnelin sisällä tapahtuu, se tulee palvelimelta tai topologiasta, eikä mikään paikallinen direktiivi voi korvata sitä.
Kirjoita kaksi luetteloa profiilin viereisiin käyttöönottomuistiinpanoihin. Seuraava vianetsintäistunto alkaa silloin kerroksesta eikä arvauksesta.