Statikus útvonalak vagy útválasztási protokoll egy telephelyek közötti VPN felett?

Mindkét lehetőség csomagokat visz a telephelyek között, tehát a döntés nem arról szól, melyik protokoll újabb, és az alagút mérete sem dönti el. Három feltétel dönti el: hány előtag változik és milyen gyakran, kell-e automatikus átállás az útvonalak között, és mennyi vezérsík-machinériát tud üzemeltetni a csapat hajnali háromkor. Válaszoljon ezekre őszintén, és a választás általában magától megszületik. A cikk többi része az, hogy mennyibe kerül az egyes válaszok.

Három feltétel dönti el

Az első feltétel a változékonyság. Néhány stabil alhálózat világos tulajdonlással évekig kézzel karbantartható, és minden útvonal marad egy sor, amit valaki el tud olvasni és ellenőrizni. A projektek jöttével-menésével mozgó több tucat előtag más probléma, mert minden mozgásnak el kell jutnia minden eszközhöz, amely még emlékszik a régi útra.

A második a hiba viselkedése. Amikor egy tartalék útnak emberi észrevétel nélkül kell aktívvá válnia, valaminek fel kell ismernie a hibát, és vissza kell vonnia az útvonalat. A statikus útválasztás ezt csak követéssel vagy feltételes telepítéssel tudja megtenni, és csak azokra a hibákra, amelyeket előre átgondolt.

A harmadik a második vezérsík iránti étvágy. Az útválasztási protokoll munkameneteket, hitelesítést, szűrőket és kiválasztási szabályzatot ad hozzá, és ezek mindegyike megfigyelést és változási folyamatot igényel. Ez állandó üzemeltetési költség, nem egyszeri konfigurációs feladat.

A harmadik bekezdés alatti táblázat a rövid változat, és az utána következő három szakasz elmagyarázza, miért ott áll minden sor, ahol áll. Választás előtt olvassa össze a sorokat a saját telephelyeinek számával, mert az üzemeltetési költséget figyelmen kívül hagyó döntés csak fél döntés.

Mennyibe kerül valójában a statikus útválasztás

A statikus útvonalnak az alagút mindkét oldalán helyesnek kell lennie. Egy alhálózat hozzáadása a távoli átjáró, a helyi átjáró és általában a visszaút szerkesztését jelenti, és ha bármelyiket elfelejti, egyirányú hiba keletkezik, amely alkalmazáshibának látszik. Az alkalmazáscsapat időtúllépéseket lát, miközben a hálózati csapat egy létező és látszólag egészséges útvonalat lát. Egyik csapat sem téved, és ezért tart ilyen sokáig ezt a hibát behatárolni.

A statikus bejegyzés az alatta lévő útvonal eltűnése után is telepítve marad. Ha a platform nem nyújt követést, az útvonal továbbra is olyan következő ugrásra mutat, amely már nem továbbít, és a forgalom eltűnik ahelyett, hogy átállna. Ez a csend az a költség, amelyet az egyszerű lehetőség választásakor elfogad.

Írja a követési módszert minden útvonal mellé, jegyezze fel, mely hibákat fedi le, és tartsa a listát az alagút konfigurációja mellett. Különben a következő kiesést egy felhasználó fedezi fel, nem a hálózat, és ez mindig a drágább felfedezés.

Mennyibe kerül valójában a dinamikus útválasztás

Egy protokoll új előtagokat hirdet, visszavonja az elérhetetleneket, és preferenciát fejez ki az útvonalak között. Ez valóban hasznos, amikor több telephely vagy redundáns alagút különben minden változásnál összehangolt szerkesztéseket igényelne. Ez az oka annak is, hogy a protokoll a legrosszabb pillanatban tud meglepni. E műveletek mindegyike olyan állapotváltozás, amelyet nem ön tett meg.

Két állapotot hoz létre, amelyek ellentmondhatnak egymásnak. Az alagút fent lehet, miközben az útválasztási munkamenet lent van, és a munkamenet fent lehet, miközben hirdetései kihagyják az alkalmazás számára szükséges alhálózatot. Mindkettő félig működő hálózatnak látszik, és egyik sem látható egy alagút-állapotoldalról.

A szűrők és a szabályzat ezért a tervezés részévé válnak, nem utólagos gondolattá. Egy protokoll, amely mindent hirdet, előbb-utóbb valami hibásat fog hirdetni, és a rossz előtag gyorsabban utazik, mint az ember, aki kijavíthatja. Írja meg a szűrőket az első munkamenet engedélyezése előtt, hogy az első hirdetés már szándékos legyen.

Szabályozza, mit mondhat az útválasztási munkamenet

Határozza meg a peerenként engedélyezett előtaglistát, és kényszerítse ki a belépésnél, mert egy kimenő szűrő nem akadályozhatja meg, hogy egy peer alapértelmezett útvonalat küldjön Önnek. Az alapértelmezett útvonalak és az összevont útvonalak itt a drága hibák: csendben helyettesíthetnek nem kapcsolódó útvonalakat egyetlen tanult bejegyzéssel, amely legitimnek látszik. Utasítsa el őket kifejezetten, hacsak a tervezés valóban nem akarja őket.

Írja a tulajdonos telephelyet minden hálózat mellé, mielőtt az első munkamenet feljön, mert ez a leképezés a szűrőlista forrása, és nem dokumentációs díszítés. Nélküle a szűrőt szerkesztő személynek találgatnia kell, melyik telephelynek kellene hirdetnie az előtagot.

A két protokoll közötti újraelosztás az a hely, ahol a hurkok elkezdődnek, és ahol ugyanaz az előtag kétszer érkezik olyan attribútumokkal, amelyek nem hasonlíthatók össze tisztán. Tartsa az újraelosztást a tervezésen kívül, amíg egy konkrét követelmény rá nem kényszerít, és ha lennie kell, jelölje meg és szűrje az útvonalakat a határon.

Az útvonalalapú alagút-interfészek könnyebbé teszik a dinamikus útválasztás ábrázolását, mert az alagút útvonalakkal rendelkező interfésszé válik a szelektorokat egyeztető szabályzat helyett. Ez nem szünteti meg a peer hatókörének kérdését: az IPsec szelektoroknak továbbra is engedélyezniük kell a forgalmat, amelyet irányítani kíván.

A hibás utat tesztelje, ne a boldog utat

Bármit is választ, vegyen le egy felső kapcsolatot, és erősítse meg, hogy a forgalom elmozdul, vagy hogy úgy hibázik, ahogy dokumentálta. Az a terv, amelyet csak mindkét út egészséges állapotában teszteltek, egyáltalán nem tesztelt terv. Mérje meg az észlelési időt, amíg ott van, mert a mért szám az a szám, amelyet a felhasználók megtapasztalnak.

Ezután önállóan erősítse meg a visszautat, mert a VPN feletti aszimmetrikus útválasztás gyakori és láthatatlan, amíg egy állapottartó eszköz el nem dobja a válaszokat. Az egy irányban működő folyam csak az út felét bizonyítja.

A munka sorrendje: számolja meg az előtagokat, döntse el, hogyan kell felismerni a hibákat, ellenőrizze, ki tudja üzemeltetni a protokollt, szabályozza, mit hirdetnek, majd teszteljen egy kiesést végponttól végpontig. Minden lépés olyan tényt ad, amelyre a következőnek szüksége van.