Kenen pitäisi omistaa reitit ja DNS, kun openfortivpn yhdistää?

Neljä vaihetta kasautuu toistensa päälle toimivassa openfortivpn-istunnossa. Asiakas todentaa itsensä yhdyskäytävällä ja aloittaa TLS-yhteyden, ajaa sitten PPP:tä kyseisen yhteyden sisällä, vastaanottaa sitten osoitteen ja DNS-tiedot ja soveltaa lopuksi isäntäreitit ja resolver-asetukset. Jokainen vaihe voi olla elossa, vaikka seuraava ei ole, ja siksi “yhdistetty” on niin liukas sana tukiketjuissa.

Päätös, joka poistaa suurimman osan sekaannuksesta, on se, kuka omistaa viimeisen vaiheen. Joko VPN-asiakas soveltaa isäntämuutokset itse tai toinen komponentti tekee sen, ja näiden kahden sekoittaminen puolivälissä on syy siihen, miksi reitit ja resolver-tiedostot lopulta kuvaavat eri istuntoja.

Neljä vaihetta, jotka näyttävät yhdeltä yhteydeltä

Ensimmäinen vaihe on hyväksyntä. nimetty todennusverkkoalue tai kertakäyttökoodi, ja saa jatkamiseen tarvittavat parametrit. Kun asiakas tulostaa olevansa yhteydessä yhdyskäytävään, se tarkoittaa, että TLS-siirto on pystyssä. Se ei tarkoita, että PPP on neuvotellut, eikä varmasti tarkoita, että sisäinen sovellus on tavoitettavissa.

Toinen vaihe on PPP-linkki. Asiakas käynnistää PPP-prosessin tunnelilaitetta vastaan, ja kaksi puolta neuvottelevat linkin asetuksista ja osoitteista. Vasta sen jälkeen isäntä tietää, mitä paikallisia ja etäosoitteita istunto käyttää, ja vasta silloin tunnelia kohti osoittava reitti voi olla mielekäs.

Kolmas vaihe on kyseisen tiedon soveltaminen isäntään, ja tässä omistajuus on tärkeää. Asiakas voi lisätä reitit ja kirjoittaa resolver-kokoonpanon uudelleen, tai sille voidaan käskeä vetäytyä ja jättää molemmat sille, mikä muuten hallitsee verkkoa kyseisellä koneella. Projektin README kuvaa nämä erillisinä vastuina yhden automaattisen toiminnan sijaan.

Kuka muokkaa reititystaulukkoa

Oletuksena asiakas on omistaja. Se lisää reitin yhdyskäytävää kohti fyysisen liitännän kautta, reitin tunnelin vertaiselle ja reitit verkoille, joita istunto saa käyttää, ja poistaa ne sitten prosessin lopettaessa. Tämä oletus on kätevä kannettavassa, jossa on yksi verkkohallinta eikä muuta VPN-ohjelmistoa.

Valitse luovutus vain, kun jokin muu todella omistaa reitityksen. Verkkohallinnan integraatio, kontin verkkonimiavaruus tai koko sivuston reititysagentti voi jo tietää, miten samat etuliitteet asennetaan ja siivotaan. no-routes-valitsimen antaminen estää silloin kahta kirjoittajaa taistelemasta samasta taulukosta, mikä on kilpailu, joka näkyy yhden aliverkon ajoittaisena katoamisena puhtaan vian sijaan.

Päällekkäisyys on toinen syy luovuttaa. Jos työnnetyt reitit sisältävät etuliitteen, jota paikallisverkko jo käyttää, asiakas ei voi ratkaista ristiriitaa puolestasi. Jonkun on päätettävä, onko kyseinen etuliite tavoitettavissa tunnelin, fyysisen linkin vai tarkemman reitin kautta, ja se päätös kuuluu topologian omistajalle.

Siivous on kolmas. Asiakas, joka kaatuu ennen reittien poistamista, jättää mustan aukon, joka elää istuntoa pidempään, ja seuraava yhteys voi lisätä sen päälle kopion. Joka omistaa reitityksen, omistaa myös sen varmistamisen, että vanhat merkinnät ovat poissa. Tee tarkistuksesta osa käynnistyspolkua, älä valinnainen siivousvaihe.

Kuka omistaa DNS:n ja resolver-tiedoston

DNS on sama päätös terävämmillä reunoilla. Asiakas voi hyväksyä DNS-palvelimet, jotka yhdyskäytävä tai PPP-vertais vastaa, ja kirjoittaa ne isännän resolver-kokoonpanoon. Yksinkertaisella koneella se on juuri se, mitä haluat, koska sisäiset nimet ratkeavat silloin vain, kun tunneli on pystyssä.

Nykyaikaisella Linux-isännällä resolveria voi hallita paikallinen stub, ja resolver-tiedoston kirjoittaminen uudelleen kyseisen stubin selän takana tuottaa kokoonpanon, joka näyttää oikealta ja käyttäytyy epäjohdonmukaisesti. Jos isäntä jo ajaa resolver-hallintaa, anna sen omistaa DNS ja syötä sille tunnelin palvelimet sen tuetun rajapinnan kautta. Asiakkaan no-dns-valitsin on siellä oikea valinta, ei kiertotie.

Jaettu DNS on erillinen kysymys siitä, kuka tiedoston kirjoittaa. Jokaisen kyselyn lähettäminen tunnelin kautta on yksinkertaista ja hidasta; vain sisäisten vyöhykkeiden lähettäminen sen kautta vaatii verkkotunnuskohtaisen kokoonpanon, jota useimmat yksinkertaiset asiakkaat eivät tarjoa. Päätä, mitä käyttäytymistä isäntä tarvitsee, ennen kuin otat asiakkaan resolver-muutokset käyttöön. Väärä valinta tässä näyttää nimien ratkaisun katkoksena, vaikka itse tunneli olisi kunnossa.

Oikeudet, valmius ja luovutus

Tunnelilaitteen luominen ja isäntäreittien tai resolver-tilan muokkaaminen vaatii korotettua verkkovaltaa. Yleinen virhe on päätellä, että siksi kaiken pitäisi ajaa rootina, mukaan lukien selain tai sovellus, joka käyttää tunnelia. Pidä etuoikeutettu osa pienenä: asiakas ja sen kokoonpanotiedosto, ylläpitäjän omistuksessa, kun taas käyttäjäsovellukset säilyttävät normaalin tilinsä.

Valmius pitäisi määritellä kuluttajakohtaisesti. Valvoja voi pitää palvelua käynnistettynä, kun asiakasprosessi on käynnissä ja tunnelilaite on olemassa. Varmuuskopiointityön pitäisi pitää VPN:ää käyttökelpoisena vasta, kun sen tallennuspäätepiste vastaa tunnelin kautta. Ne ovat eri tarkistuksia, ja heikomman käyttäminen vahvempaan tarkoitukseen tuottaa töitä, jotka alkavat liian aikaisin ja epäonnistuvat ajoittain. Kirjoita valittu määritelmä muistiin, sillä valvoja ja työ, jotka ovat eri mieltä valmiudesta, ovat tukipyyntö, joka odottaa tapahtumistaan.

Testaa sopimus neljällä havainnolla: yhdyskäytävävaihe valmistuu, PPP jakaa osoitteet, aiottu reitti on läsnä ja pyyntö sisäiselle isännälle onnistuu. Pysäytä sitten asiakas ja vahvista, että jokainen näistä on poistettu tai palautettu. Jos isäntä yhä ratkaisee sisäisiä nimiä tai pitää yhä reittiä tunnelin sulkeuduttua, omistajuuden luovutus on puutteellinen.