Sisäkkäinen VPN: mikä tunneli kuljettaa ulompaa yhteyttä?

Kaksi samanaikaisesti käynnissä olevaa VPN-asiakasta eivät tuota sisäkkäistä tunnelia; ne tuottavat kaksi tunnelia ja riidan reitityksestä. Sisäkkäinen tunneli on olemassa, kun sisemmän asiakkaan yhteys omaan palvelimeensa kulkee itse ulomman tunnelin läpi, ja se on järjestely, joka rakennetaan tarkoituksella. Jos se menee oikein, sisempi palvelin näkee ulomman palvelimen osoitteen; jos väärin, yksi asiakas yhdistää hiljaa uudelleen toisen ohi. Kolme ehtoa ratkaisee, onko sisäkkäisyys todellinen vai sattumanvarainen.

Kolme ehtoa ratkaisee sisäkkäisyyden

Ensimmäinen on, kumpi päätepiste tarvitsee kumman polun. Nimeä sisemmän palvelimen osoite, nimeä ulomman palvelimen osoite ja totea selvästi, että sisempi palvelin on tavoitettavissa vain ulomman tunnelin kautta. Kaikki muu seuraa tuosta lauseesta, mukaan lukien se, mitkä reitit kuuluvat mihinkin tauluun.

Toinen on, näetkö polun jokaisella kerroksella. Jos et voi kysyä ytimeltä, mitä reittiä tietty kohde käyttäisi, päättelet ketjun lopullisesta lähtevästä IP-osoitteesta, ja juuri se on todiste, joka ei pysty erottamaan sisäkkäisyyttä sattumasta.

Kolmas on, mitä tapahtuu, kun ulompi tunneli putoaa. Sisempi tunneli voi pysähtyä sen mukana, yhdistää uudelleen tavallisen verkon kautta tai pysyä estettynä, kunnes ulompi polku palaa, ja kaikki kolme ovat puolustettavia käytäntöjä. Ne eivät ole sama käytäntö, ja useimpien asiakkaiden oletuskäyttäytyminen on toinen. Asiakas, joka yhdistää päätepisteensä uudelleen fyysisen verkon kautta näyttäen samalla terveen yhteyden, on yleisin tapa, jolla aiottu ketju muuttuu hiljaa kahdeksi toisiinsa liittymättömäksi tunneliksi.

Ehto yksi: kumpi päätepiste tarvitsee kumman polun

ip route get 203.0.113.10 vastaa tähän kysymykseen suoraan: se tulostaa reitin, lähdeosoitteen ja liittymän, jota ydin käyttäisi kyseiselle kohteelle juuri nyt.

Aja se sisemmälle palvelimelle ennen sisemmän asiakkaan käynnistymistä ja vielä kerran sen jälkeen, ja vertaa. Jos vastaus vaihtuu fyysisestä liittymästä ulomman tunnelin liittymään, sisäkkäisyys on tuolla hetkellä todellinen. Jos se ei muutu, sisempi asiakas yhdistää suoraan, mitä paneeli sanoo tahansa. Toista ulomman palvelimen osoitteelle, joka on edelleen ratkaistava fyysisen liittymän kautta, koska reitti, joka nappaa molemmat päätepisteet rekursiivisesti, on vika, joka irrottaa koneen kokonaan verkosta.

Ehto kaksi: tarkastele polkua jokaisella kerroksella

Reitin valinta on nykyaikaisessa asiakkaassa enemmän kuin päätaulu. Käytäntösäännöt voivat lähettää merkityt paketit toiseen tauluun, asiakas voi sitoa pistokkeensa liittymään, ja kontilla tai nimiavaruudella on omat taulunsa. ip rule ja ip route show table all ovat tapa selvittää, mikä näistä mekanismeista on pelissä.

Asiakas, joka asettaa SO_MARK-arvon omaan pistokkeeseensa tai on määritetty sitoutumaan tiettyyn laitteeseen, ohittaa oletusreitin, jonka luulit järjestäneesi. Se on ominaisuus, ei vika, ja se tarkoittaa, että ainoa luotettava tarkistus on se, joka ajetaan samassa nimiavaruudessa kuin asiakas. Jos asiakkaat toimivat konteissa, aja tarkistukset niissä konteissa isäntäkoneen sijaan.

Ehto kolme: mitä tapahtuu, kun ulompi tunneli putoaa

Vikatilanteen käyttäytyminen vaatii päätöksen, ei oletusarvoa. Kirjoita ylös, mitä sisemmälle tunnelille pitää tapahtua, kun ulompi katoaa, ja pane asiakkaat tekemään niin.

Vaihtoehdot ovat konkreettisia. Sisemmän asiakkaan pysäyttäminen, kun ulompi polku katoaa, antaa puhtaan ketjun ja ilmeisen katkoksen. Sen salliminen yhdistää suoraan antaa käytettävyyttä ja poistaa hiljaa ominaisuuden, jota varten ketju rakennettiin. Estäminen ulomman polun paluuseen asti on tiukin ja ylläpidollisesti hankalin vaihtoehto, koska jokainen ulomman tunnelin heilahdus muuttuu näkyväksi tapaukseksi.

Testaa kaikki kolme vaarattomalla liikenteellä ja tarkoituksellisella ulomman tunnelin vialla, koska asetusten lukeminen ei kerro, kumpi sinulla on. Tapa ulompi tunneli, seuraa mitä sisempi asiakas tekee ja tarkista reitti uudelleen, kun se on alhaalla. Palauta sitten ulompi tunneli ja vahvista, että ketju muodostuu uudelleen sen sijaan että sisempi asiakas jäisi suoralle polulle, jonka se valitsi sillä välin.

Mitä ketju ei anna sinulle

Lisäkerrokset lisäävät päätepisteitä, avaimia ja vikatiloja; ne eivät lisää mitään anonymiteettitakuuta eivätkä estä ulompaa operaattoria näkemästä, että tunneli on olemassa. Jokaisen väitteen siitä, miltä sisäkkäisyys suojaa, on nimettävä se tarkkailija, jolta se suojaa.

Tulos on lyhyt asiakirja eikä toimiva yhteys: mikä päätepiste käyttää mitä polkua, mitä ulomman vian sattuessa tapahtuu ja kolme komentoa, jotka näyttävät nykytilan. strongSwanin dokumentaatio edelleenlähetyksestä on hyödyllinen lähde siitä, miten tunneliliikennettä välitetään liittymien välillä Linux-isäntäkoneessa. Aja tarkistukset uudelleen jokaisen asiakaspäivityksen jälkeen, koska oletukset, jotka loivat ketjusi, eivät ole sopimus. Sisäkkäinen tunneli, jota et voi tarkastella, on huhu, jossa on tilavalaisin.