Staatilised marsruudid või marsruutimisprotokoll üle saidi-saiti VPN-i?

Mõlemad valikud veavad pakette saitide vahel, seega otsus ei ole selles, milline protokoll on uuem, ja tunnelil ei ole ka suurust, mis selle otsustaks. Otsustavad kolm tingimust: kui palju prefikseid muutub ja kui sageli, kas projekt vajab radade vahel automaatset ümberlülitust, ning kui palju juhtimistasandi masinavärki suudab meeskond kell kolm öösel käitada. Vastake neile ausalt ja valik teeb end tavaliselt ise. Ülejäänud tekst on iga vastuse hind.

Kolm tingimust otsustavad

Esimene tingimus on muutlikkus. Käputäis stabiilseid alavõrke selge omanikuga saab aastaid käsitsi hooldada ja iga marsruut jääb reaks, mida keegi saab lugeda ja kontrollida. Kümned prefiksid, mis liiguvad projektide tuleku ja minekuga, on teine probleem, sest iga liikumine peab jõudma igasse seadmesse, mis veel vana rada mäletab.

Teine on rikke käitumine. Kui varurada peab muutuma aktiivseks ilma, et inimene seda märkaks, peab miski rikke tuvastama ja marsruudi tagasi võtma. Staatiline marsruutimine suudab seda ainult jälgimise või tingimusliku paigalduse kaudu ja ainult nende rikete puhul, mida te ette mõtlesite.

Kolmas on isu teise juhtimistasandi järele. Marsruutimisprotokoll lisab sessioonid, autentimise, filtrid ja valikupoliitika ning igaüks neist vajab monitooringut ja muudatusprotsessi. See on püsiv käitamiskulu, mitte ühekordne seadistusülesanne.

Kolmanda lõigu all olev tabel on lühiversioon ja selle järel olevad kolm osa selgitavad, miks iga rida asub seal, kus ta asub. Lugege ridu oma saidi arvu vastu enne valimist, sest käitamiskulu eirav otsus on ainult pool otsust.

Mida staatiline marsruutimine tegelikult maksab

Staatiline marsruut peab olema õige tunneli mõlemal poolel. Alavõrgu lisamine tähendab kaugvärava, kohaliku värava ja tavaliselt ka tagasitee muutmist ning ühegi neist unustamine tekitab ühesuunalise rikke, mis näeb välja nagu rakenduse viga. Rakenduste meeskond näeb ajalõppe, samal ajal kui võrgumeeskond näeb marsruuti, mis on olemas ja näiliselt terve. Kumbki meeskond ei eksi ja seetõttu võtab selle rikke paigutamine nii kaua aega.

Staatiline kirje jääb paigaldatuks ka pärast seda, kui selle all olev rada kaob. Kui platvorm ei paku jälgimist, osutab marsruut edasi järgmisele hüppele, mis enam ei edasta, ja liiklus kaob selle asemel, et ümber lülituda. See vaikus on kulu, mille te lihtsa valiku korral vastu võtate.

Kirjutage jälgimismeetod iga marsruudi kõrvale, märkige, milliseid rikkeid see katab, ja hoidke nimekirja tunneli seadistuse juures. Muidu avastab järgmise katkestuse kasutaja, mitte võrk, ja see on alati kallim avastus.

Mida dünaamiline marsruutimine tegelikult maksab

Protokoll kuulutab välja uusi prefikseid, võtab tagasi kättesaamatud ja väljendab eelistust radade vahel. Sellest on tõesti kasu, kui mitmel saidil või liiasel tunnelil oleks muidu vaja iga muutuse juures koordineeritud muudatusi. See on ka põhjus, miks protokoll võib teid halvimal hetkel üllatada. Igaüks neist toimingutest on olekumuutus, mida te ise ei teinud.

See loob kaks olekut, mis võivad lahkneda. Tunnel võib olla üleval, samal ajal kui marsruutimissessioon on maas, ja sessioon võib olla üleval, samal ajal kui selle kuulutused jätavad välja alavõrgu, mida rakendus vajab. Mõlemad näevad välja nagu poolenisti töötav võrk ja kumbagi ei ole tunneli olekulehelt näha.

Seetõttu saavad filtritest ja poliitikast projekti osa, mitte hilisem mõte. Protokoll, mis kuulutab kõike, kuulutab lõpuks midagi valesti ja vale prefiks liigub kiiremini kui inimene, kes suudab selle parandada. Kirjutage filtrid enne esimese sessiooni lubamist, et esimene kuulutus oleks juba kavatsuslik.

Kontrollige, mida marsruutimissessioon tohib öelda

Otsustage lubatud prefiksite nimekiri iga partneri kohta ja rakendage seda sisenemisel, sest väljuv filter ei suuda takistada partneril teile vaikemarsruuti saatmast. Vaikemarsruudid ja koondid on siin kallid vead: need võivad vaikselt asendada seostamata rajad ühe õpitud kirjega, mis näeb seaduslik välja. Keelduge neist selgesõnaliselt, kui projekt neid tõesti ei taha.

Kirjutage omaniksait iga võrgu kõrvale enne, kui esimene sessioon üles tuleb, sest see vastendus on filtrite nimekirja allikas, mitte dokumentatsiooni ehe. Ilma selleta peab filtrit muutev inimene oletama, milline sait peaks prefiksit kuulutama.

Ümberjagamine kahe protokolli vahel on koht, kus algavad silmused, ja kus sama prefiks saabub kaks korda atribuutidega, mida ei saa puhtalt võrrelda. Hoidke ümberjagamine projektist väljas, kuni konkreetne nõue seda sunnib, ja kui see peab olemas olema, märkige ja filtreerige marsruudid piiril.

Marsruudipõhised tunneliliidesed teevad dünaamilise marsruutimise esitamise lihtsamaks, sest tunnelist saab marsruutidega liides, mitte valijaid sobitav poliitika. See ei kõrvalda partneri ulatuse küsimust: IPsec-valijad peavad endiselt lubama liiklust, mida kavatsete marsruutida.

Testige rikke rada, mitte õnnelikku rada

Mida iganes te valite, võtke üks ühendus maha ja kinnitage, et liiklus liigub või et see ebaõnnestub nii, nagu te dokumenteerisite. Projekt, mida on testitud ainult mõlema raja tervena, on projekt, mida ei ole üldse testitud. Mõõtke tuvastusaega, kui te juba kohal olete, sest mõõdetud arv on arv, mida kasutajad kogevad.

Seejärel kinnitage tagasitee iseseisvalt, sest asümmeetriline marsruutimine üle VPN-i on tavaline ja nähtamatu, kuni olekut säilitav seade vastused maha viskab. Ühes suunas töötav voog tõestab ainult poole teest.

Töö järjekord: loendage prefiksid, otsustage, kuidas rikkeid tuvastada, kontrollige, kes suudab protokolli käitada, kontrollige, mida kuulutatakse, ja seejärel testige üks katkestus otsast otsani. Iga samm annab fakti, mida järgmine samm vajab.