Migrarea unei subrețele pe un tunel VPN nou fără întrerupere

Ridicați tunelul nou, mutați o subrețea, și acea subrețea eșuează acum intermitent în timp ce tot restul este perfect în regulă. VPN-urile migrate pe jumătate eșuează exact așa, pentru că tunelul nu a fost niciodată partea grea. Calea include și ce rută câștigă, ce selectori se potrivesc, ce permit regulile de acces, cum se întorc răspunsurile și orice traducere pe care o aplica vechiul proiect. Mutați doar tunelul și nu ați mutat nimic din toate acestea.

Tunelul este jumătatea ușoară a căii

Eșecurile intermitente după o migrare parțială înseamnă de obicei că ambele căi sunt plauzibile. Unele fluxuri aleg tunelul nou, altele rămân pe cel vechi, iar un dispozitiv care ține minte starea vede atunci un răspuns sosind pe o cale pe care cererea nu a folosit-o niciodată. Două căi nu sunt automat mai sigure decât una; sunt două lucruri care pot să nu fie de acord. Urmăriți rapoartele de oscilație și nu contoarele tunelului, pentru că acele contoare vor arăta sănătoase tot timpul.

Prima întrebare utilă nu este care tunel este mai bun. Este care fluxuri aleg ce cale astăzi, și dacă cererea și răspunsul primesc același răspuns.

Construiți destinația înainte de a o prefera

Confirmați că partenerii sunt compatibili și că tunelul nou poartă intervalul de adrese pe care îl intenționați. Adăugați redirecționarea și permisiunile de serviciu de care are nevoie cât timp este încă calea nepreferată, astfel încât comutarea în sine să schimbe doar selecția și nimic altceva.

Întrebați site-ul îndepărtat cum va returna traficul. Dacă răspunsurile ies încă prin tunelul vechi, o rută locală nouă produce asimetrie sau eșuează pe un filtru care ține minte starea. Traducerea face parte din proiect din același motiv: o adresă sursă schimbată schimbă și calea de întoarcere.

Comutați îngust și știți drumul înapoi

Numiți subrețeaua exactă și mecanismul susținut de platformă care preferă noua sa rută sau selector. Definițiile bazate pe politici nu se comportă întotdeauna ca metricile de rutare, așa că citiți regulile politicilor suprapuse din implementarea dumneavoastră înainte de a presupune că potrivirea mai specifică câștigă.

Mutați o subrețea, nu un sit. Țineți accesul de administrare pe o cale pe care nu o atingeți, și scrieți revenirea înainte de a aplica ceva: ce rută sau politică revine, cine o face și cum rămân conectați în timp ce o fac.

Asimetrie și stare învechită

Paravanele și dispozitivele NAT țin minte interfața folosită de un flux. Când cererea și răspunsul iau tuneluri diferite, dispozitivul poate arunca răspunsul chiar dacă fiecare cale funcționează singură. Testați cu un flux pe care îl deschideți după schimbare, pentru că o sesiune stabilită poate continua să folosească vechea cale ore întregi.

Dacă adresa sursă observată s-a mutat, găsiți fiecare politică ce o numește pe cea veche. O migrare care schimbă sursa în tăcere încalcă reguli pe care nimeni nu le-a clasificat ca parte a proiectului VPN.

Dovediți ambele răspunsuri, apoi retrageți politica veche

Dintr-un host obișnuit din subrețeaua migrată, ajungeți la serviciul dorit și verificați sursa observată și interfața răspunsului. Apoi testați o rețea care trebuie să rămână pe tunelul vechi, pentru că o migrare se termină doar când ambele răspunsuri sunt corecte. Al doilea test este cel pe care oamenii îl sar, și el este cel care prinde un selector mai larg decât intenționați.

Retrageți politica învechită doar când nicio subrețea rămasă nu depinde de ea, și înregistrați ruta finală cu proprietarul ei în inventarul de selectori. Finalizarea nu este ca tunelul nou să raporteze că este sus; este ca fiecare rețea să urmeze calea prevăzută.