Un VPN în cloud are nevoie de BGP: de ce celelalte protocoale de rutare eșuează

Asocierea de securitate IPsec este activă, contoarele tunelului se mișcă, iar traficul către prefixul din cloud dispare. Operatorul încearcă apoi să activeze OSPF pe routerul clientului, așteptându-se ca vecinul să se formeze, și nu se întâmplă nimic. Tunelul nu a fost niciodată piesa lipsă: un VPN în cloud gestionat expune un contract de rutare definit, iar pe platformele mari acel contract este BGP. Până când există o sesiune și un prefix este acceptat, tunelul este doar o cale criptată fără destinații în spate.

Tunelul este activ și ruta lipsește

Finalizarea fazei 1 și a fazei 2 dovedește că părțile sunt de acord asupra protecției, nu că vreuna știe unde să trimită traficul. Sunt mașini de stare separate cu moduri de eșec separate.

Puneți trei întrebări în ordine: a fost anunțat prefixul, a fost acceptat de vecin și a fost instalat pentru forwarding? Un prefix anunțat și filtrat este o problemă de politică. Un prefix care nu a fost niciodată anunțat este o problemă de sesiune sau de configurare. Un prefix acceptat dar neinstalat este o problemă de selecție a rutei, iar fiecare răspuns indică o parte diferită a configurației.

Ce vă oferă de fapt furnizorul

Un gateway VPN gestionat nu este un router fără restricții. Furnizorul vă oferă un gateway cu adrese de vecin acceptate, o setare de sistem autonom, limite de prefixe și un comportament de eșec definit. Acea suprafață este produsul.

Google Cloud documentează rutarea dinamică BGP pentru HA VPN, cu Cloud Router care învață rutele vecinilor și furnizează rute dinamice personalizate eligibile către VPC. AWS Site-to-Site VPN documentează o alegere între rutarea statică și cea dinamică și descrie verificările de vitalitate BGP ca utile pentru preluarea tunelului, sprijinind totodată verificările de stare pentru dispozitivele fără BGP. Comportamentul unei platforme nu trebuie dedus din numele produsului celeilalte.

Consecința practică este că alegeți mai întâi modul gestionat și abia apoi citiți parametrii acceptați. Un proiect care presupune un tip de adiacență pe care serviciul nu îl oferă nu este o problemă de configurare de rezolvat pe routerul clientului.

Protecția tunelului și accesibilitatea sunt sarcini separate

IPsec protejează traficul selectat pentru tunel. BGP furnizează informația de accesibilitate care face un prefix eligibil. Un tunel funcțional nu dovedește că prefixul așteptat a fost anunțat, acceptat sau instalat.

Imaginați-vă o sucursală care anunță 10.42.0.0/16 prin două căi de tunel eligibile. Eliminați o cale utilizabilă și alegerea rutei se poate schimba fără ca cineva să editeze ruta fiecărei sarcini de lucru. Detectarea, selecția rutei și recuperarea aplicației nu sunt instantanee și nu sunt identice între implementări, așa că testul de preluare trebuie să observe întreaga secvență, nu primul pachet care trece.

Când un prefix din cloud este inaccesibil, verificați starea sesiunii și rutele învățate înainte de a atinge criptografia. O SA activă fără rută în spate este cea mai comună formă a acestui simptom.

Unde se rup presupunerile despre OSPF

OSPF, IS-IS sau alt protocol în interiorul unui tunel IPsec este perfect posibil pe un echipament autogestionat, unde dețineți ambele capete și proiectul de forwarding. Acest fapt nu spune nimic despre un serviciu gestionat care oferă doar BGP ca mod de rutare dinamică.

Dacă un proiect propus are nevoie de o adiacență pe care serviciul nu o acceptă, schimbați arhitectura în mod deliberat. Opțiunile includ un echipament autogestionat în VPC, rutare statică acolo unde serviciul o acceptă sau un alt produs de conectivitate. Configurarea protocolului doar pe routerul clientului nu poate adăuga un vecin de partea cloudului care nu există și nu va face prefixul să apară.

Nu transportați răspunsul unui furnizor către gateway-ul altuia. Aceleași cuvinte, cum ar fi rutare dinamică sau preluare a tunelului, pot descrie mecanisme și limite diferite.

Citiți cerința serviciului, apoi proiectați

Înainte de prima linie de configurare, notați adresele vecinilor, numerele sistemelor autonome, prefixele pe care le veți anunța și accepta, limitele de rute și comportamentul așteptat când un tunel eșuează. Acele cinci elemente sunt contractul față de care proiectați.

Apoi verificați în aceeași ordine: sesiune stabilită, prefix primit, rută prezentă în tabela de rute a VPC și un flux real către o adresă de serviciu. Repetați după o preluare forțată, pentru că o sesiune care se restabilește poate reveni cu un alt set de rute. Dacă proiectul depinde de convergență sub o secundă, măsurați-o în loc să o presupuneți.

Păstrați contractul serviciului împreună cu înregistrarea modificării. Când cineva întreabă mai târziu de ce tunelul nu poate rula OSPF, răspunsul este o limită de produs, nu o limitare de protocol, iar înregistrarea ar trebui să spună asta.