Yksi palveluosoite jokaisessa OpenVPN-solmussa: mitä se ei tee

Asiakas yhdistää yhteen useasta OpenVPN-palvelimesta ja tarvitsee sitten pienen palvelun, joka pyörii juuri siinä solmussa: tilasivun, metriikkapäätepisteen, varmuuskopioagentin. Kun jokaiselle solmulle annetaan sama yksityinen palveluosoite, asiakkaan kokoonpano pysyy samana riippumatta siitä, mille palvelimelle se osui. Tämä mukavuus on todellista, ja se on myös helppo ylitulkita: jaettu osoite kertoo, mihin solmuun pääsit, ei sitä, että jokin olisi kahdennettu.

Miksi sama osoite jokaisessa solmussa toimii

Jokainen solmu omistaa osoitteen paikallisesti ja vastaa siitä, joten asiakas, joka tavoittaa sen nykyisen tunnelinsa kautta, saa palvelun juuri sen tunnelin toisesta päästä. Solmujen välillä ei sovita mitään, eikä liikenne kulje solmusta toiseen.

Osoite on paikallinen nimilappu, toistettu eikä replikoitu. Jokainen solmu vastaa vain omasta puolestaan, eikä yksikään niistä välitä liikennettä osoitteelle toisen solmun puolesta. Juuri se pitää yhden asiakaskokoonpanon kelvollisena, kun palvelimet pysyvät riippumattomina. Se on myös syy siihen, miksi suunnittelu ei tarvitse solmujen välistä koordinointia.

Siksi sama kokoonpano toimii jokaisella palvelimella ilman niiden välistä reititysprotokollaa. Se on myös syy siihen, miksi suunnittelu ei sano terveydestä mitään: osoite on sairaassa solmussa täsmälleen samoin kuin terveessä, koska se on sidottu isäntään eikä siihen, että palvelu on hyödyllinen.

Anna se loopbackille, älä tunnelille

Osoitteen laittaminen loopback-liitäntään irrottaa sen minkä tahansa tunnelilaitteen eliniästä, joten uudelleenyhdistäminen tai kokoonpanon uudelleenlataus ei poista sitä. Osoite on olemassa niin kauan kuin isäntä on.

Osoite lo:ssa ei ole suodatin. Palvelun on yhä kuunneltava sitä, ja isännän palomuuri arvioi yhä todellisen saapuvan polun, joka saapuu tunneliliitännästä. Se, joka olettaa loopbackin tarkoittavan vain paikallista, päätyy joko estämään laillisia asiakkaita tai paljastamaan jotain, mitä ei tarkoittanut.

Tee määrityksestä pysyvä isännän verkkokokoonpanon kautta sen sijaan, että lisäisit sen uudelleen hookista. Asennushook ei laukea solmussa, johon ei noussut tunnelia, eikä palveluosoitteen pitäisi riippua tunnelin toiminnasta. Laita osoite sen liitännän kokoonpanoon, jota jakelusi hallinnoi, käynnistä sitten kerran uudelleen ja tarkista se. Uudelleenkäynnistys on ainoa testi, joka kestää myöhemmän kokoonpanomuutoksen.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Työnnä yksi reitti ja tarkoita yhtä kohdetta

Asiakas tarvitsee osoitteelle isäntäreitin, jonka tarjoaa se palvelin, johon se yhdistää. Koska jokainen palvelin tarjoaa saman kohteen, profiili ei muutu, kun asiakas liikkuu.

Tarkista, mitä asiakas asensi, ennen kuin syytät palvelua.

ip route get 10.250.0.1

Anna HTTP-palvelulle osoitteelle nimi ja nimelle varmenne. Jaettu IP ei ole identiteetti, eikä se poista TLS-varmennusta, eikä se oikeuta kopioimaan yhtä yksityistä avainta jokaiseen solmuun. Nimi, joka ratkeaa jaettuun osoitteeseen, pitää varmennetarinan tavallisena ja sallii solmukohtaisen identiteetin, jos sellaista tarvitset.

Mitä jaettu osoite ei voi tehdä

Se ei tarjoa vikasietoa. Jos valittu solmu kuolee, osoite kuolee sen mukana, ja asiakkaan on yhdistettävä uudelleen muualle.

Se ei siirrä elävää TCP-istuntoa, koska uusi yhteys päättyy toiseen isäntään, joka ei tiedä vanhasta mitään.

Se ei valitse tervettä solmua, tasapainota kuormaa eikä synkronoi tietoja solmujen välillä. Jokainen näistä on erillinen mekanismi omine vikatiloineen, ja sen teeskenteleminen, että osoitekuski kattaa ne, on tapa, jolla yksinkertainen suunnittelu saa ansaitsemattoman maineen kestävyydessä. Jos kaksi tunnelia on aktiivisena yhtä aikaa, kohteen merkitys muuttuu monitulkintaiseksi, joten pidä yhden aktiivisen tunnelin oletus selvästi esillä.

Pidä palvelun identiteetti nimen yhteydessä

Kirjoita ylös, mitä osoite tarkoittaa: se tavoittaa palvelun solmussa, johon asiakas on parhaillaan yhteydessä. Yksi lause estää suurimman osan siitä väärinkäsityksestä, jota tämä kaava vetää puoleensa.

Dokumentoi sitten osat yhdessä: osoite, liitäntä jolla se elää, reitti jonka palvelin työntää, sekä nimi ja varmenne jonka palvelu esittää. Neljä pientä tosiseikkaa, jotka tuleva lukija voi tarkistaa, siinä järjestyksessä kuin hän ne tarkistaa.

Jos vaatimus on vakaa kohde solmun paikalliselle palvelulle, kaava sopii ja maksaa lähes ei mitään.

Jos vaatimus on käytettävyys, siirry kerrosta ylös: kuormantasain, terveystarkistuksilla varustettu palvelunimi tai orkestrointijärjestelmä, joka jo tietää, miten solmu korvataan.

Sen varhainen päättäminen pitää jaetun osoitteen sellaisena kuin se on, kätevänä nimilappuna, eikä komponenttina, jolta hiljaa odotetaan työtä, jota varten sitä ei koskaan suunniteltu.