Staattiset reitit vai reititysprotokolla sivusto-sivusto VPN:n yli?

Molemmat vaihtoehdot kuljettavat paketteja sivustojen välillä, joten päätös ei ole siitä, kumpi protokolla on uudempi, eikä tunnelin koko ratkaise sitä. Sen ratkaisevat kolme ehtoa: kuinka monta etuliitettä muuttuu ja kuinka usein, tarvitseeko suunnittelu automaattista siirtymistä polkujen välillä, ja kuinka paljon ohjaustason koneistoa tiimi pystyy käyttämään kolmelta aamuyöllä. Vastaa näihin rehellisesti, niin valinta tekee yleensä itse itsensä. Tämän tekstin loppuosa on se, mitä kukin vastaus maksaa.

Kolme ehtoa ratkaisee

Ensimmäinen ehto on muutosherkkyys. Kourallinen vakaita aliverkkoja, joilla on selkeä omistajuus, voidaan pitää käsityönä vuosia, ja jokainen reitti pysyy rivinä, jonka joku voi lukea ja tarkistaa. Kymmenet etuliitteet, jotka liikkuvat projektien tullessa ja mennessä, ovat toinen ongelma, koska jokaisen siirron on saavutettava jokainen laite, joka vielä muistaa vanhan polun.

Toinen on vikatilannekäyttäytyminen. Kun varapolun on tultava aktiiviseksi ilman, että ihminen huomaa sitä, jonkin on havaittava vika ja vedettävä reitti pois. Staattinen reititys voi tehdä sen vain seurannan tai ehdollisen asennuksen kautta, ja vain niille vioille, jotka olet ennakolta ajatellut.

Kolmas on halukkuus toiseen ohjaustasoon. Reititysprotokolla lisää istunnot, todennuksen, suodattimet ja valintakäytännön, ja jokainen niistä vaatii valvontaa ja muutosprosessin. Se on pysyvä käyttökustannus, ei kertaluonteinen määritystehtävä.

Kolmannen kappaleen alla oleva taulukko on lyhyt versio, ja sen jälkeiset kolme osaa selittävät, miksi kukin rivi on siinä missä on. Lue rivit omaa sivustomäärääsi vasten ennen valintaa, koska käyttökustannuksen sivuuttava päätös on vain puoli päätöstä.

Mitä staattinen reititys todella maksaa

Staattisen reitin on oltava oikein tunnelin molemmilla puolilla. Aliverkon lisääminen tarkoittaa etäyhdyskäytävän, paikallisen yhdyskäytävän ja yleensä paluupolun muokkaamista, ja minkä tahansa niistä unohtaminen tuottaa yksisuuntaisen vian, joka näyttää sovellusvirheeltä. Sovellustiimi näkee aikakatkaisuja, kun taas verkkotiimi näkee reitin, joka on olemassa ja näyttää terveeltä. Kumpikaan tiimi ei ole väärässä, ja siksi tämän vian paikantaminen kestää niin kauan.

Staattinen merkintä jää myös asennetuksi sen jälkeen, kun sen alla oleva polku katoaa. Ellei alusta tarjoa seurantaa, reitti osoittaa edelleen seuraavaan hyppyyn, joka ei enää välitä, ja liikenne katoaa sen sijaan, että se vaihtuisi. Se hiljaisuus on kustannus, jonka hyväksyt valitessasi yksinkertaisen vaihtoehdon.

Kirjoita seurantamenetelmä jokaisen reitin viereen, merkitse mitkä viat se kattaa ja pidä luettelo tunnelin määrityksen yhteydessä. Muuten seuraavan katkoksen löytää käyttäjä eikä verkko, mikä on aina kalliimpi löytö.

Mitä dynaaminen reititys todella maksaa

Protokolla ilmoittaa uudet etuliitteet, vetää pois tavoittamattomat ja ilmaisee mieltymyksen polkujen välillä. Siitä on todella hyötyä, kun useat sivustot tai redundantit tunnelit muuten vaatisivat sovitettuja muutoksia joka muutoksessa. Se on myös syy siihen, miksi protokolla voi yllättää sinut pahimmalla hetkellä. Jokainen noista toiminnoista on tilanmuutos, jota et tehnyt itse.

Se luo kaksi tilaa, jotka voivat olla eri mieltä. Tunneli voi olla ylhäällä, kun reititysistunto on alhaalla, ja istunto voi olla ylhäällä, kun sen ilmoitukset jättävät pois aliverkon, jota sovellus tarvitsee. Molemmat näyttävät verkolta, joka toimii puoliksi, eikä kumpikaan näy tunnelin tilasivulta.

Siksi suodattimista ja käytännöstä tulee osa suunnittelua eikä jälkiajatus. Protokolla, joka ilmoittaa kaiken, ilmoittaa lopulta jotain väärää, ja väärä etuliite kulkee nopeammin kuin henkilö, joka voi korjata sen. Kirjoita suodattimet ennen ensimmäisen istunnon käyttöönottoa, jotta ensimmäinen ilmoitus on jo tarkoituksellinen.

Hallitse, mitä reititysistunto saa sanoa

Päätä sallittu etuliiteluettelo kumppania kohden ja valvo sitä sisääntulossa, koska lähtevä suodatin ei voi estää kumppania lähettämästä sinulle oletusreittiä. Oletusreitit ja koosteet ovat kalliita virheitä tässä: ne voivat hiljaa korvata toisiinsa liittymättömät polut yhdellä opitulla merkinnällä, joka näyttää lailliselta. Hylkää ne nimenomaisesti, ellei suunnittelu todella halua niitä.

Kirjoita omistajasivusto jokaisen verkon viereen ennen kuin ensimmäinen istunto nousee, koska tuo kartoitus on suodatinluettelon lähde, ei dokumentaation koriste. Ilman sitä suodatinta muokkaavan on arvattava, minkä sivuston pitäisi ilmoittaa etuliite.

Uudelleenjakelu kahden protokollan välillä on paikka, jossa silmukat alkavat ja jossa sama etuliite saapuu kahdesti attribuuteilla, joita ei voi verrata puhtaasti. Pidä uudelleenjakelu poissa suunnittelusta, kunnes jokin erityinen vaatimus pakottaa sen, ja jos sen on oltava, merkitse ja suodata reitit rajalla.

Reittipohjaiset tunneliliitännät tekevät dynaamisen reitityksen esittämisestä helpompaa, koska tunnelista tulee liitäntä, jolla on reittejä, valitsimia vastaavan käytännön sijaan. Se ei poista kumppanin laajuuden kysymystä: IPsec-valitsimien on edelleen sallittava liikenne, jonka aiot reitittää.

Testaa vikapolku, älä onnellista polkua

Mitä ikinä valitsetkin, ota yksi ylälinkki alas ja varmista, että liikenne siirtyy tai että se epäonnistuu dokumentoimallasi tavalla. Suunnittelu, jota on testattu vain molempien polkujen ollessa terveitä, on suunnittelu, jota ei ole testattu lainkaan. Mittaa havaitsemisaika, kun olet paikalla, koska mittaamasi luku on luku, jonka käyttäjät kokevat.

Vahvista sitten paluupolku erikseen, koska epäsymmetrinen reititys VPN:n yli on yleistä ja näkymätöntä, kunnes tilaa ylläpitävä laite pudottaa vastaukset. Yhteen suuntaan toimiva virtaus todistaa vain puolet polusta.

Työjärjestys: laske etuliitteet, päätä miten viat havaitaan, tarkista kuka pystyy käyttämään protokollaa, hallitse mitä ilmoitetaan, ja testaa sitten yksi katkos päästä päähän. Jokainen vaihe tuottaa tosiasian, jota seuraava tarvitsee.