Kaksi VPN-hyppyä yhdellä Pi:llä: mikä reitti kantaa minkä vertaiskumppanin

Kaksi tunneliosoitetta yhdellä pienellä levyllä näyttävät virheeltä, ja refleksi on poistaa toinen. Se refleksi rikkoo sen, mitä sen piti siistiä. Kaksi hyppyä kantava isäntä pitää yhden osoitteen liitäntää kohden, ja jokaisen osoitteen valitsee eri reitti. Kysymys, joka kannattaa esittää, on mikä reitti valitsee minkä kantajan mille kohteelle, ei se, kuinka monta osoitetta on olemassa.

Kolme kohdetta, jotka tarvitsevat eri kantajat

Kahden hypyn ketju on kolme pinottua kohdeluokkaa, ja kutakin kantaa eri liitäntä. Ulompaan vertaiskumppaniin on päästävä fyysisen linkin kautta. Sisempään vertaiskumppaniin on päästävä ulomman tunnelin kautta. Peitetyn sovelluksen kohteeseen on päästävä sisemmän tunnelin kautta, jonka oman siirron ulompi kantaa.

Täytä rivit lukijan todellisilla osoitteilla ennen kuin kosket reittiin, koska taulukko on hyödyllinen vain kun se on konkreettinen. Toimiva ketju täyttää kaikki neljä riviä samanaikaisesti, ja puoliksi toimiva ketju täyttää yleensä yhden niistä väärällä kantajalla. Juuri väärän rivin lukeminen vikana muuttaa reititysongelman koko iltapäivän mittaisiksi muokkauksiksi.

Osoitteilla on roolit, ei määrä

Linux sallii useita osoitteita yhdellä liitännällä ja useita tunneleita yhdellä isännällä, joten määrä ei kerro mitään oikeellisuudesta. Merkitsevää on, mikä osoite kuuluu mille liitännälle ja valitseeko tietyn vertaiskumppanin reitti sen liitännän, jota tarkoitit. Kolme näkymää vastaa siihen kolmesta suunnasta, ja ne kannattaa lukea samassa järjestyksessä joka kerta.

Osoitelinventaario näyttää, mitä on olemassa ja mikä liitäntä sen omistaa. Reittitaulukko vastaa kantajakysymykseen tavalliselle kohdeliikenteelle. Käytäntönäkymä vastaa siihen uudelleen liikenteelle, joka valitaan lähteen tai merkin perusteella, mikä on tavallinen järjestely, kun kaksi asiakasta jakaa yhden isännän.

ip -4 addr show
ip -4 route show table all
ip rule show

Osoitteen poistaminen, koska lista näyttää pitkältä, voi poistaa osan polusta, ja reitin poistaminen, koska se näyttää tarpeettomalta, tekee saman hiljaisemmin. Kumpikaan ei tuota virhettä; vertaiskumppani yksinkertaisesti lakkaa vastaamasta polulla, jota tarkoitit, mutta pysyy saavutettavana toista kautta. Sovellus, joka ilmoittaa sisemmän vertaiskumppanin lähtöosoitteen, ei todista, että liikenne ylitti ulomman tunnelin, koska suora pääsy tuottaa saman havainnon. Juuri tämä kuilu havainnon ja todisteen välillä on syy siihen, miksi kantaja tarkistetaan reititystasolla.

Aktivointijärjestys voittaa kiinteän unen

Jos sisempi asiakas riippuu osoitteesta tai reitistä, jonka ulompi asiakas tarjoaa, aktivoinnin on odotettava sitä resurssia eikä viivettä. Uni toimii siihen päivään asti, jolloin ulompi tunneli on hidas, ja silloin se epäonnistuu ajoittain tavalla, jota kukaan ei voi toistaa. Riippuvuuksiin perustuva järjestys poistaa arvailun eikä maksa mitään muuta kuin riippuvuuden kuvaamisen kerran. Myöskään liitäntöjen nimet eivät ole järjestysmekanismi.

Ydin jakaa nimiä kuten tun0 ja tun1 luomisjärjestyksessä, ja tämä järjestys voi muuttua uudelleenkäynnistysten tai uudelleenyhdistämisten välillä. Sido kokoonpano identiteettiin, jonka työkalu tarjoaa, tai nimeen, jonka määrität tarkoituksella. Valitsemasi nimi on sopimus; ytimen valitsema nimi on sattuma.

Pidä kunkin asiakkaan siirto poissa toisen sovellusreitiltä ja ole täsmällinen siitä, mitä OpenVPN 2.6:n reititysvalinnat todella lupaavat. Dokumentoitu oletusohjauksen mekanismi pitää asiakkaan kykenevän tavoittamaan oman etävertaiskumppaninsa jo olemassa olleen yhdyskäytävän kautta, mikä katkaisee yhden tietyn rekursiosilmukan. Se ei tee yhdestä asiakkaasta toisen kantajaa, joten ketjun loppuosa on edelleen sinun suunnittelusi. Kun ketju tarvitsee reitin sijaan käytännön, kirjoita selkeä lähde- tai merkintäsääntö ja testaa sitä liikenteellä, jonka sen on tarkoitus vastata.

Mitä tapahtuu, kun ulompi hyppy kuolee

Ennen kuin ketju lasketaan valmiiksi, päätä, mitä tapahtuu, kun ulompi hyppy katoaa. Sisemmän asiakkaan siirto kuolee sen mukana, ja seuraava siirto on käytäntökysymys eikä tekninen: epäonnistua, yrittää uudelleen vai yhdistää suoraan fyysisen linkin kautta. Juuri kolmas lopputulos on se, jota kannattaa miettiä. Se muuttaa hiljaa kahden hypyn suunnitelman yhden hypyn suunnitelmaksi hetkellä, jolloin käyttäjä uskoo kattavuuden olevan vielä ehjä.

Jos kaksi hyppyä on pakollista, sisempi asiakas ei saa pystyä muodostamaan suoraa polkua, kun ulompi on poissa, ja tapa tietää se on katkaista ulompi hyppy ja katsoa, mitä sisempi tekee. Hyväksytty varasuunnitelma on laillinen vastaus, mutta se on kirjoitettava, testattava ja kerrottava. Varasuunnitelma, jota kukaan ei dokumentoinut, on tapauksen jälkitarkastelussa erottamaton vuodosta.

DNS ja toinen osoiteperhe kuuluvat samaan päätökseen. Paikallisesti luotu haku noudattaa isännän omaa käytäntöä eikä välitetyn asiakkaan käytäntöä, joten välitetylle liikenteelle toimiva nimipalvelin ei välttämättä ole se, jota isäntä itse käyttää.

Hyväksy jokainen kerros siinä järjestyksessä, jossa rakensit sen

Testaa siinä järjestyksessä, jossa ketju rakennettiin: ensin ulompi tunneli yksin, sitten sisemmän asiakkaan siirto ulomman tunnelin kautta, sitten sovellus sisemmän tunnelin kautta. Jokaisen hyväksynnän on oltava tuore yhteys eikä jo avoinna ollut sivu. Katkaise ja palauta sitten jokainen kerros erikseen ja katso, mitä seuraava tekee.

Varasuunnitelman tulos on täällä arvokkain havainto ja se, jota julkinen IP-sivu ei koskaan näytä. Tallenna vertaiskumppanien polut, niiden käyttämät osoitteet ja tuo tulos kokoonpanon viereen, koska onnellinen polku ei ole se osa, jota myöhemmin kyseenalaistetaan.