Statiese roetes of ’n roeteringsprotokol oor ’n terrein-tot-terrein VPN?

Beide opsies dra pakkette tussen terreine, so die besluit gaan nie oor watter protokol nuwer is nie, en die grootte van die tonnel beslis dit ook nie. Drie voorwaardes doen dit: hoeveel prefikse verander en hoe dikwels, of die ontwerp outomatiese oorskakeling tussen paaie nodig het, en hoeveel beheervlakmasjinerie die span om drie in die oggend kan bedryf. Beantwoord dit eerlik en die keuse maak gewoonlik homself. Die res van hierdie stuk is wat elke antwoord kos.

Drie voorwaardes beslis dit

Die eerste voorwaarde is verandering. ’n Handvol stabiele subnetwerke met duidelike eienaarskap kan jare lank met die hand onderhou word, en elke roete bly ’n reël wat iemand kan lees en nagaan. Dosyne prefikse wat beweeg soos projekte kom en gaan, is ’n ander probleem, want elke skuif moet elke toestel bereik wat nog die ou pad onthou.

Die tweede is foutgedrag. Wanneer ’n rugsteunpad aktief moet word sonder dat ’n mens dit agterkom, moet iets die fout opspoor en die roete onttrek. Statiese roetering kan dit net deur dop of voorwaardelike installasie doen, en net vir die foute wat jy vooraf bedink het.

Die derde is lus vir ’n tweede beheervlak. ’n Roeteringsprotokol voeg sessies, verifikasie, filters en keurbeleid by, en elkeen daarvan het monitering plus ’n veranderingsproses nodig. Dit is ’n permanente bedryfskoste, nie ’n eenmalige konfigurasietaak nie.

Die tabel onder die derde paragraaf is die kort weergawe, en die drie afdelings daarna verduidelik waarom elke ry staan waar dit staan. Lees die rye teen jou eie aantal terreine voordat jy kies, want ’n besluit wat die bedryfskoste ignoreer, is net ’n halwe besluit.

Wat statiese roetering werklik kos

’n Statiese roete moet aan beide kante van die tonnel korrek wees. Om ’n subnet by te voeg beteken om die afgeleë poort, die plaaslike poort en gewoonlik die terugpad te wysig, en om enige een daarvan te vergeet lewer ’n eenrigtingfout wat soos ’n toepassingsfout lyk. Die toepassingspan sien tydsverstrykings terwyl die netwerkspan ’n roete sien wat daar is en oënskynlik gesond is. Geen span is verkeerd nie, en daarom neem hierdie fout so lank om op te spoor.

’n Statiese inskrywing bly ook geïnstalleer nadat die pad daaronder verdwyn. Tensy die platform dop verskaf, bly die roete na ’n volgende sprong wys wat nie meer aanstuur nie, en verkeer verdwyn in plaas van oor te skakel. Daardie stilte is die koste wat jy aanvaar wanneer jy die eenvoudige opsie kies.

Skryf die dopmetode langs elke roete, noteer watter foute dit dek, en hou die lys by die tonnelkonfigurasie. Anders word die volgende onderbreking deur ’n gebruiker ontdek eerder as deur die netwerk, wat altyd die duurder ontdekking is.

Wat dinamiese roetering werklik kos

’n Protokol adverteer nuwe prefikse, onttrek onbereikbares en spreek voorkeur tussen paaie uit. Dit is werklik nuttig wanneer verskeie terreine of oorbodige tonnels anders by elke verandering gekoördineerde wysigings sou nodig hê. Dit is ook die rede waarom die protokol jou op die slegste oomblik kan verras. Elkeen van daardie aksies is ’n toestandsverandering wat jy nie self gemaak het nie.

Dit skep twee toestande wat kan verskil. Die tonnel kan op wees terwyl die roeteringsessie af is, en die sessie kan op wees terwyl sy advertensies die subnet weglaat wat die toepassing nodig het. Albei lyk soos ’n netwerk wat half werk, en nie een is van ’n tonnelstatusbladsy sigbaar nie.

Filters en beleid word dus deel van die ontwerp eerder as ’n nagedagte. ’n Protokol wat alles adverteer, sal uiteindelik iets verkeerds adverteer, en die verkeerde prefiks reis vinniger as die persoon wat dit kan regstel. Skryf die filters voordat die eerste sessie geaktiveer word, sodat die eerste advertensie al doelbewus is.

Beheer wat die roeteringsessie mag sê

Bepaal die toegelate prefikslys per eweknie en handhaaf dit by inkomend, want ’n uitgaande filter kan nie keer dat ’n eweknie vir jou ’n standaardroete stuur nie. Standaardroetes en samevattings is die duur foute hier: hulle kan stilweg onverwante paaie vervang met een geleerde inskrywing wat wettig lyk. Verwerp hulle uitdruklik, tensy die ontwerp dit werklik wil hê.

Skryf die eienaarterrein langs elke netwerk voordat die eerste sessie opkom, want daardie kartering is die bron van die filterlys en nie ’n dokumentasieversiering nie. Sonder dit moet die persoon wat ’n filter wysig raai watter terrein die prefiks behoort aan te kondig.

Herverdeling tussen twee protokolle is waar lusse begin, en waar dieselfde prefiks twee keer aankom met eienskappe wat nie skoon vergelyk nie. Hou herverdeling uit die ontwerp tot ’n spesifieke vereiste dit afdwing, en as dit moet bestaan, merk en filtreer die roetes by die grens.

Roetegebaseerde tonnelkoppelvlakke maak dinamiese roetering makliker om voor te stel, want die tonnel word ’n koppelvlak met roetes in plaas van ’n beleid wat kiesers pas. Dit verwyder nie die vraag oor ewekniebestek nie: die IPsec-kiesers moet steeds die verkeer toelaat wat jy van plan is om te roeteer.

Toets die foutpad, nie die gelukkige pad nie

Wat jy ook kies, bring een opverbinding af en bevestig dat verkeer beweeg, of dat dit misluk op die manier wat jy gedokumenteer het. ’n Ontwerp wat net met albei paaie gesond getoets is, is ’n ontwerp wat glad nie getoets is nie. Meet die opsporingstyd terwyl jy daar is, want die getal wat jy gemeet het, is die getal wat gebruikers sal ervaar.

Bevestig dan die terugpad onafhanklik, want asimmetriese roetering oor ’n VPN is algemeen en onsigbaar totdat ’n toestandbewuste toestel die antwoorde laat val. ’n Vloei wat in een rigting werk, bewys net die helfte van die pad.

Werkorde: tel die prefikse, besluit hoe foute opgespoor moet word, kyk wie die protokol kan bedryf, beheer wat geadverteer word, en toets dan een onderbreking van begin tot einde. Elke stap lewer ’n feit wat die volgende stap nodig het.