Cum să alegeți gateway-uri VPN între locații care funcționează împreună

Două gateway-uri de locație de la furnizori diferiți vor forma un tunel dacă implementările lor cad de acord asupra parametrilor care se negociază. Mărcile identice nu sunt o cerință, iar mărcile potrivite nu sunt nici ele o garanție. Întrebarea compatibilității ține de funcții și versiuni; întrebarea capacității ține de munca pe care dispozitivul trebuie să o facă în software. Tratați-le ca două verificări, exact în această ordine.

Parcurgeți lista și opriți-vă la primul punct care nu are răspuns.

Începeți cu funcțiile protocolului, nu cu marca

Pentru protocolul pe care intenționați să îl rulați, enumerați ce are nevoie proiectul: metoda de autentificare, propunerile convenite de criptare și integritate, interfața sau construcția pentru traficul protejat, modul de rutare și dacă vreuna dintre părți stă în spatele NAT. Fiecare dintre ele este o funcție pe care implementarea trebuie să o susțină, nu o casetă de bifare pe pagina unui produs.

Cerințele AWS pentru gateway-ul de client sunt un model util chiar dacă nu vă conectați la AWS, pentru că enunță contractul ca un set de obligații de protocol și de rutare. Un fișier exemplu al furnizorului pentru un anumit model este o dovadă decentă că cineva a testat acea combinație. O etichetă generică ce afirmă suport IPsec nu dovedește nici versiunea, nici modelul de politică. Citiți notele de lansare, nu rezumatul de marketing.

Verificați versiunea, nu eticheta de pe fișa tehnică

Interoperabilitatea IKEv2 se decide prin parametrii negociați, așa că întrebarea este ce propuneri oferă și acceptă firmware-ul actual. Un dispozitiv care susține protocolul în general poate refuza totuși combinația concretă pe care insistă celălalt capăt. Confirmați șirul versiunii și lista de propuneri pe ambele părți.

O notă că o funcție a apărut într-un tren de firmware ulterior este suficient de obișnuită pentru a merita propriul punct în lista de verificare.

Tratați capacitatea ca pe o întrebare separată

Criptarea costă muncă, iar cât anume depinde de implementare tot atât de mult ca de algoritm. Unele căi de accelerare se aplică doar anumitor algoritmi sau anumitor căi de forwarding, așa că un dispozitiv poate fi rapid într-o configurație și lent în alta. Debitul obișnuit al unei WAN nu este debitul unui tunel criptat. Dimensionați dispozitivul după traficul pe care îl veți proteja efectiv.

Și dimensiunea pachetului contează, pentru că încapsularea și orice suprasarcină suplimentară reduc încărcătura utilă pe care o duce fiecare pachet.

Decideți politica de rutare în mod explicit

Între locații nu înseamnă că doar traficul selectat poate folosi tunelul și nici că totul trebuie să îl folosească. Un proiect poate transporta prefixe private anume sau poate rută o rută implicită prin gateway. Alegeți una și scrieți-o, pentru că ambele capete trebuie să cadă de acord asupra a ce se anunță și ce se acceptă. O nepotrivire aici produce un tunel care este ridicat și o rețea care este pe jumătate accesibilă.

Proiectele cu rutare dinamică adaugă încă o cerință: suport pentru protocolul de rutare la ambele capete.

Ce să comparați înainte de a cumpăra

Comparați frecvența actualizărilor, dovezile de interoperabilitate, recuperarea configurației și comportamentul de comutare dorit alături de viteza maximă de transfer. Întrebați ce se întâmplă când dispozitivul repornește cu o configurație învechită. Întrebați dacă furnizorul publică o listă de interoperabilitate pentru partenerul exact pe care intenționați să îl folosiți. Întrebați cui îi aparține schimbarea când o actualizare de firmware modifică o propunere implicită.

O garanție hardware nu este un răspuns la niciuna dintre ele.

Apoi testați perechea înainte de a vă angaja față de o flotă. Un tunel, propunerile reale, modul de rutare real și un transfer asemănător sarcinii de lucru vă vor spune mai mult decât orice tabel de specificații.