VPN pe mai multe căi: patru garanții pe care operatorul trebuie să le ofere

Adăugați o a doua legătură WAN și tunelurile se ridică, dar o copiere de fișier încă se blochează când o cale oscilează. Legăturile sunt sănătoase și procesele VPN rulează; ce lipsește este un contract între operator și tunel. Mai multe socketuri nu se comportă automat ca o singură conexiune, iar aplicația de deasupra nu vede diferența până nu se rupe livrarea. Fiecare parte a contractului corespunde unei defecțiuni pe care o puteți testa, și asta îl face util.

Scrieți acel contract înainte de a alege un produs. Are patru părți: fluxul pe care îl primește VPN-ul, modul în care operatorul recuperează datele lipsă, ce identitate a punctului final supraviețuiește unei schimbări de cale și cum se comportă ansamblul când o cale eșuează.

Simptomul: legăturile sunt active, sesiunea se rupe totuși

Un grafic de monitorizare care arată ambele legături active dovedește doar că fiecare cale poate transporta trafic. Nu dovedește că VPN-ul vede un singur flux ordonat, că un pachet pierdut pe o cale este recuperat pe alta sau că partenerul mai știe cu ce sesiune vorbește. Restul contractului acoperă ceea ce graficul nu poate arăta.

Când un transfer se blochează, aflați dacă operatorul a continuat să livreze pe calea supraviețuitoare. Dacă sesiunea moare în timp ce a doua legătură este inactivă, operatorul nu a folosit-o niciodată. Dacă sesiunea supraviețuiește dar datele sosesc fără ordine sau duplicate, operatorul mută pachete fără un contract la nivel de conexiune. Marcajele temporale de pe ambele părți lămuresc de obicei situația.

Această distincție decide remedierea. O problemă de rutare sau de politică necesită o schimbare a selecției căii; un strat de ordonare și recuperare lipsă necesită alt transport, nu un buffer mai mare.

Garanția unu: un flux de octeți la nivel de conexiune

Dacă VPN-ul are nevoie de un flux ordonat fiabil, operatorul trebuie să identifice intervale de octeți deasupra căii individuale. Fiecare conexiune TCP subiacentă numerotează doar propriile segmente, așa că un receptor nu poate reordona între căi folosind doar acele numere.

Multipath TCP este exemplul standardizat. Prezintă un flux de octeți fiabil în timp ce coordonează mai multe subfluxuri TCP, cu mapare a secvenței și confirmare la nivel de date. Aplicația citește un flux, nu subfluxul care a livrat din întâmplare o bucată prima.

Pe Linux, MPTCP este opt-in per socket prin IPPROTO_MPTCP. Când negocierea nu poate folosi comportamentul multipath, revenirea documentată este TCP obișnuit, ceea ce înseamnă că aplicația poate continua pe o singură cale fără a o folosi vreodată pe a doua. Verificați ce comportament a negociat efectiv socketul implementat, în loc să presupuneți că setarea kernelului s-a aplicat.

Garanția doi: ordonare, duplicare și recuperare

Căile cu întârzieri și rate de pierdere diferite obligă operatorul să tamponeze, să reordoneze și să retransmită. Contractul trebuie să spună cât tampon este permis, ce contrapresiune vede aplicația și ce cale transportă o retransmisie.

O cale care rămâne conectată dar nu mai livrează este mai dificilă decât o închidere curată. Operatorul trebuie să o detecteze, să mute datele în așteptare și să evite așteptarea veșnică a unui segment care nu va sosi niciodată. O simplă verificare că ambele legături sunt active nu acoperă această stare.

Duplicarea are nevoie de propria regulă. Trimiterea aceleiași încărcări pe ambele căi poate îmbunătăți latența, dar receptorul trebuie să suprime copia înainte de a ajunge la VPN. Anti-replay-ul IPsec este opțional per asociere de securitate și verifică numerele de secvență; un strat de duplicare care reordonează sau redă pachete poate să-l declanșeze sau să ascundă problema până când tunelul cade.

Garanția trei: identitatea punctului final și alăturarea căilor

Partenerul are nevoie de o modalitate stabilă de a recunoaște sesiunea când apare o cale nouă. Dacă fiecare cale este autentificată ca tunel separat, VPN-ul poate vedea două sesiuni în loc de una. Dacă operatorul unește căile sub o singură sesiune, trebuie să definească modul în care este autentificată calea nouă și ce se întâmplă cu cea veche.

Notați ce adrese și identificatori rămân stabili: punctul final al tunelului, identificatorul de sesiune al operatorului și orice proxy intermediar. Un proxy adaugă o altă frontieră de disponibilitate și încredere chiar dacă nu vede niciodată încărcătura protejată.

Aici se află și politica. O cale care se alătură dintr-o rețea neașteptată poate fi validă tehnic și totuși încălca modelul de încredere dorit. Decideți dacă noile căi sunt acceptate automat, necesită autentificare sau sunt refuzate.

Garanția patru: comportament limitat în caz de defecțiune

Testați o defecțiune completă a căii, nu doar o cale lentă. Calea supraviețuitoare ar trebui să transporte sesiunea fără creștere nelimitată a memoriei, iar recuperarea nu ar trebui să depindă de un temporizator mai lung decât poate tolera aplicația. Când calea defectă revine, operatorul trebuie să decidă dacă reechilibrează sau lasă fluxul unde este.

Setați limite pentru tamponare, retransmisie și numărul de căi, apoi verificați-le sub pierdere, reordonare, duplicare și dezechilibru de întârziere. Lățimea de bandă agregată este cel mai puțin interesant număr aici; continuitatea livrării și limitele de memorie sunt contractul.

Țineți starea de recuperare a operatorului separată de starea criptografică a VPN-ului. Un strat de fiabilitate propriu care înlocuiește autentificarea sau criptarea consacrate nu este o scurtătură, iar reutilizarea numerelor de secvență între straturi face protecția anti-replay și diagnosticarea nesigure.

Acceptați operatorul cu un plan de testare

Scrieți cele patru garanții ca verificări de trecut sau eșuat: un flux ordonat, recuperare definită, identitate de sesiune stabilă, comportament de defecțiune limitat. Rulați fiecare verificare cu o cale degradată și apoi cu o cale eliminată.

Un singur transfer de fișier reușit printr-o schimbare de cale nu dovedește funcționare continuă. Repetați transferul în timp ce comutați calea preferată și inspectați atât viziunea operatorului, cât și contoarele proprii ale VPN-ului. Dacă cele două nu sunt de acord asupra căii care a transportat datele, contractul nu este încă observabil.

Păstrați matricea aprobată împreună cu implementarea. Le spune următorului inginer ce comportament a fost promis, ce combinații de căi au fost testate și ce mod de defecțiune rămâne neacceptat, fără încă o rundă de presupuneri după luminile de stare ale legăturilor.