Rute statice sau un protocol de rutare peste un VPN de la sediu la sediu?

Ambele opțiuni transportă pachete între sedii, așa că decizia nu este despre care protocol este mai nou, iar dimensiunea tunelului nici ea nu o rezolvă. O rezolvă trei condiții: câte prefixe se schimbă și cât de des, dacă proiectul are nevoie de comutare automată între căi și cât de multă mașinărie de plan de control poate opera echipa la trei dimineața. Răspundeți sincer la acestea și alegerea se face de obicei singură. Restul acestui text este cât costă fiecare răspuns.

Trei condiții o decid

Prima condiție este volatilitatea. Câteva subrețele stabile cu proprietate clară pot fi întreținute manual ani de zile, iar fiecare rută rămâne o linie pe care cineva o poate citi și verifica. Zeci de prefixe care se mută odată cu venirea și plecarea proiectelor sunt altă problemă, pentru că fiecare mutare trebuie să ajungă la fiecare dispozitiv care încă ține minte vechea cale.

A doua este comportamentul la defect. Când o cale de rezervă trebuie să devină activă fără ca un om să observe, ceva trebuie să detecteze defectul și să retragă ruta. Rutarea statică poate face asta doar prin urmărire sau instalare condiționată, și doar pentru defectele la care v-ați gândit dinainte.

A treia este apetitul pentru un al doilea plan de control. Un protocol de rutare adaugă sesiuni, autentificare, filtre și politică de selecție, iar fiecare dintre acestea cere monitorizare și un proces de schimbare. Este un cost operațional permanent, nu o sarcină de configurare unică.

Tabelul de sub al treilea paragraf este versiunea scurtă, iar cele trei secțiuni de după el explică de ce fiecare rând stă unde stă. Citiți rândurile față de propriul număr de sedii înainte de a alege, pentru că o decizie care ignoră costul operațional este doar jumătate de decizie.

Cât costă cu adevărat rutarea statică

O rută statică trebuie să fie corectă pe ambele părți ale tunelului. Adăugarea unei subrețele înseamnă editarea gateway-ului îndepărtat, a celui local și de obicei a căii de întoarcere, iar uitarea oricăreia dintre ele produce un defect unidirecțional care arată ca o eroare a aplicației. Echipa de aplicații vede expirări de timp, în timp ce echipa de rețea vede o rută care există și pare sănătoasă. Niciuna dintre echipe nu greșește și de aceea acest defect ia atât de mult să fie localizat.

O intrare statică rămâne instalată și după ce calea de sub ea dispare. Dacă platforma nu oferă urmărire, ruta continuă să indice un salt următor care nu mai trimite mai departe, iar traficul dispare în loc să comute. Acea tăcere este cheltuiala pe care o acceptați când alegeți opțiunea simplă.

Scrieți metoda de urmărire lângă fiecare rută, notați ce defecte acoperă și păstrați lista împreună cu configurația tunelului. Altfel următoarea întrerupere este descoperită de un utilizator, nu de rețea, ceea ce este întotdeauna descoperirea mai scumpă.

Cât costă cu adevărat rutarea dinamică

Un protocol anunță prefixe noi, retrage pe cele inaccesibile și exprimă preferință între căi. Este cu adevărat util când mai multe sedii sau tuneluri redundante ar cere altfel modificări coordonate la fiecare schimbare. Este și motivul pentru care protocolul vă poate surprinde în cel mai prost moment. Fiecare dintre acele acțiuni este o schimbare de stare pe care nu ați făcut-o personal.

Creează două stări care pot să nu fie de acord. Tunelul poate fi sus în timp ce sesiunea de rutare este jos, iar sesiunea poate fi sus în timp ce anunțurile ei omit subrețeaua de care are nevoie aplicația. Ambele arată ca o rețea care funcționează pe jumătate și niciuna nu este vizibilă de pe o pagină de stare a tunelului.

Filtrele și politica devin astfel parte din proiect, nu un gând de mai târziu. Un protocol care anunță tot va anunța în cele din urmă ceva greșit, iar prefixul greșit călătorește mai repede decât persoana care îl poate corecta. Scrieți filtrele înainte de activarea primei sesiuni, ca primul anunț să fie deja deliberat.

Controlați ce are voie să spună sesiunea de rutare

Stabiliți lista de prefixe permise pentru fiecare peer și impuneți-o la intrare, pentru că un filtru de ieșire nu poate împiedica un peer să vă trimită o rută implicită. Rutele implicite și agregările sunt greșelile scumpe aici: pot înlocui în liniște căi neînrudite cu o singură intrare învățată care pare legitimă. Respingeți-le explicit, dacă proiectul nu le vrea cu adevărat.

Scrieți sediul proprietar lângă fiecare rețea înainte de a urca prima sesiune, pentru că acea mapare este sursa listei de filtre, nu un ornament de documentație. Fără ea, cel care editează un filtru trebuie să ghicească ce sediu ar trebui să anunțe prefixul.

Redistribuirea între două protocoale este locul unde încep buclele și unde același prefix ajunge de două ori cu atribute care nu se compară curat. Țineți redistribuirea în afara proiectului până când o cerință specifică o impune, iar dacă trebuie să existe, marcați și filtrați rutele la graniță.

Interfețele de tunel bazate pe rute fac rutarea dinamică mai ușor de reprezentat, pentru că tunelul devine o interfață cu rute în loc de o politică ce potrivește selectori. Asta nu elimină întrebarea despre scopul peer-ului: selectorii IPsec trebuie în continuare să permită traficul pe care intenționați să îl rutați.

Testați calea defectului, nu calea fericită

Orice ați alege, coborâți un uplink și confirmați că traficul se mută sau că eșuează așa cum ați documentat. Un proiect testat doar cu ambele căi sănătoase este un proiect care nu a fost testat deloc. Măsurați detecția cât timp sunteți acolo, pentru că numărul pe care l-ați măsurat este numărul pe care utilizatorii îl vor trăi.

Apoi confirmați calea de întoarcere independent, pentru că rutarea asimetrică peste un VPN este obișnuită și invizibilă până când un dispozitiv cu stare aruncă răspunsurile. Un flux care funcționează într-o singură direcție dovedește doar jumătate din cale.

Ordinea lucrului: numărați prefixele, decideți cum trebuie detectate defectele, verificați cine poate opera protocolul, controlați ce se anunță și apoi testați o întrerupere de la un capăt la altul. Fiecare pas produce un fapt de care are nevoie pasul următor.