Tähti ja navat vai täysi verkko: mikä VPN-topologia sopii toimipaikoillesi

Kaksi sivukonttoria puhuu toistensa kanssa koko päivän, ja niiden välinen tunneli kiertää toisen alueen datakeskuksen kautta. Jokainen pyyntö maksaa tästä kierrosta kahdesti, eikä kukaan huomaa sitä ennen kuin tiedostojen synkronointi alkaa tuntua väärältä. Tässä topologiakysymys todella alkaa: ei siitä, mikä kaavio näyttää kestävämmältä, vaan siitä, mistä liikennekuviosta maksat. Molemmat mallit toimivat, ja ne epäonnistuvat eri tavoin eri hinnoin.

Laske vertaissuhteet ennen muuta

N toimipaikalla täysi verkko tarvitsee N kertaa N miinus yksi, jaettuna kahdella, tunnelia; keskitin tarvitsee N. Viidellä toimipaikalla se on kymmenen viittä vastaan, mikä kuulostaa vielä hallittavalta. Viidellätoista se on 105 viittätoista vastaan, eikä ero ole enää aritmetiikkaa vaan henkilöstöä.

Jokainen näistä suhteista kantaa tilaa, joka sinun on omistettava. IPsecissä se tarkoittaa tietoturvayhdistystä, identiteettiä, avainta tai varmennetta, kuolleen vertaisen tunnistusta ja vähintään yhtä reittiä kohden kaukaista etuliitettä. WireGuardissa se tarkoittaa julkista avainta ja AllowedIPs lohkoa kohden vertaista, mikä on halvempaa vertaista kohden mutta tulee täysin ilman löytämistä: uusi toimipaikka on joka tapauksessa kokoonpanomuutos jokaisessa olemassa olevassa.

Anna liikennevalikoiman päättää, älä piirroksen

Jos sivukonttoreiden liikenne on pääosin pyyntöjä keskitettyyn ERP:iin tai tiedostoklusteriin, keskitin ei ole kompromissi vaan oikea muoto: liikenne halusi jo sinne, ja yksi käytäntöpiste on helpompi auditoida kuin parien sääntöjen verkko. Verkko ansaitsee monimutkaisuutensa, kun sivukonttorit vaihtavat dataa keskenään — replikointi kahden toimiston välillä, puhe toimipaikkojen välillä, jaettu CAD-kansio, jonka tusina insinööriä avaa koko päivän.

Hankalat tapaukset ovat välissä, ja ne ovat enemmistö. Mittaa ennen kuin väittelet sen sijaan että arvaisit organisaatiokaaviosta.

Lue taulukkoa ratkaisijana, älä sääntönä. Kolme neljästä rivistä yhteen suuntaan ratkaisee mallin yleensä; jakautuminen tarkoittaa hybridiä, johon useimmat kypsät verkot joka tapauksessa päätyvät.

Keskitimelle on sanottava, että se välittää

Kaksi toimivaa tähti-keskitin-tunnelia ei luo tähti-tähti-yhteyttä. Keskitin tarvitsee käyttöön otetun IP-välityksen, reitin jokaiseen tähden verkkoon, palomuurisäännön joka sallii läpikulun ja lasketun paluupolun; jokainen tähti tarvitsee reitin toisen toimipaikan etuliitteille. Linux-keskitimellä se on net.ipv4.ip_forward=1 plus FORWARD ketju, joka ei hiljaa pudota paria, ja käytäntöpohjaisessa IPsecissä se on liikenteen valitsimia, jotka listaavat kaukaisen tähden aliverkon molemmissa päissä. strongSwanin välitysohjeet kattavat ytimen ja palomuurin puolen, kun juuri se kerros puuttuu. Halpa testi on lähettää liikennettä yhdestä tähdestä toisen palveluun ja seurata keskitimen laskureita; sääntö, joka ei koskaan kasva, tarkoittaa että järjestys on väärä, ei reitti.

Keskitetty käytäntö on myös se hyödyllinen osa. Sivukonttoreille voidaan sallia yhteisiin palveluihin pääsy ilman pääsyä toisiinsa, ja se käyttöoikeusmatriisi kannattaa kirjoittaa eksplisiittisesti. Puuttuvat reitit ovat huono korvike säännölle, jonka joku voi lukea.

Varo puolivalmista versiota: tähti A reitittää tähteen B keskitimen kautta, keskitin reitittää molempiin suuntiin ja keskitimen palomuuri sallii uudet yhteydet A:sta mutta ei B:stä. Ensimmäinen suunta testautuu hyvin ja toinen jää roikkumaan, mikä näyttää reititysvialta eikä ole sitä.

Suunnittele vika, sitten normaali polku

Yksi keskitin on jaettu riippuvuus ja läpikulun pullonkaula, ja redundanssi on juuri se kohta, jossa keskitinmallit yleensä menevät pieleen. Kaksi keskitintä tarkoittaa, että jokainen tähti pitää kahta tunnelia, ja paluupolun on sovittava lähtevän kanssa; kun ei sovi, tilallinen palomuuri pudottaa vastaukset ja oireena on yhteys, joka avautuu ja sitten kuolee. Suuremmat käyttöönotot ratkaisevat tämän tunnelien yli kulkevalla reititysprotokollalla staattisten etuliitteiden sijaan, mikä on enemmän koneistoa mutta poistaa arvailun. Mitä ikinä valitset, kirjoita paluupolku lähtevän viereen, koska paluupuoliskoa kukaan ei testaa.

Verkko hajauttaa tämän riskin: yhden toimipaikan linkin katkeaminen ei eristä muita. Se myös moninkertaistaa paikat, joissa polun valinta voi yllättää, eivätkä sovellusten istunnot edelleenkään selviä polun vaihdoksesta ilman apua.

Kumpikaan malli ei pidä TCP-istuntoa elossa failoverin yli itsestään. Jos sovellus ei voi yhdistää uudelleen, topologia ei ole ongelmasi.

Valitse muutoksen hinnalla ja tarkista sitten reitit

Aloita keskitimestä, koska se on halvempi asia, jossa erehtyä, ja lisää suorat tunnelit niille pareille, joiden liikenne sen oikeuttaa. Tämä hybridi ei ole päätöksenteon laiminlyönti; se on malli, johon useimmat organisaatiot päätyvät vuoden kuluessa. Tärkeää on, että jokaisella suoralla linkillä on ilmoitettu syy ja omistaja.

Tarkista sitten kaksi piirrosta yhden sijaan. Normaalille polulle, traceroute jokaisesta toimipaikasta jokaiseen palveluetuliitteeseen ja vahvista, että hypyt vastaavat kaaviota. Vikapolulle katkaise yksi tunneli ja toista, koska reitti, joka toimii vain kun kaikki on ylhäällä, ei ole suunniteltu, vain konfiguroitu.

Säilytä molemmat piirrokset käyttöoikeusmatriisin kanssa ja käy ne läpi, kun toimipaikka lisätään; hinta, jota hallitset, on seuraavan muutoksen hinta, ei nykyisen kuvan eleganssi.