Twee IPsec-gateways, geen gedeelde IP: wat failover werklik doen

Skakel gateway A dood tydens ’n vergadering en kyk hoe die tonnel ’n minuut later deur B terugkom; die verbinding werk, die videoproep dalk nie. Dit is die eerlike vorm van koue failover tussen twee IPsec-gateways met onafhanklike adresse. Die kliënt kies ’n eindpunt weer en bou ’n nuwe verhouding, wat bereikbaarheid herstel sonder om die ou sessie se kriptografiese toestand oor te dra. Om die volgorde te loop, maak dit duidelik watter beloftes die ontwerp kan hou.

Stel die toneel: twee adresse, geen swewende IP

Gateway A antwoord op een bereikbare adres en gateway B op ’n ander. Die kliënt het ’n goedgekeurde manier om B te kies wanneer A weg is, en daar is geen gedeelde buite-adres wat albei gateways opeis nie. In hierdie ontwerp beteken ’n virtuele IP daardie gedeelde toegangspunt, nie die binne-adres wat aan ’n afstandtoegang-kliënt toegewys is nie.

Daardie definisie maak saak, want die twee idees word in kaartjies deurmekaar gemaak, en die oplossing vir die een is nie die oplossing vir die ander nie. ’n Verslag dat die gedeelde toegang nie die gateway gevolg het nie, beskryf een ontwerp. ’n Verslag dat die skootrekenaar sy binne-adres verloor het, beskryf die kliënt se huur. Verskillende eienaars, verskillende logs, verskillende herstelwerk.

Loop die faling: bespeur, dan herkies

Eers merk iets op dat A opgehou antwoord het. Dit kan dooie-port-detectie op die tonnellaag wees, ’n roeteringsprotokol wat ’n pad onttrek, of ’n toepassing-timeout wat uiteindelik ’n herverbinding forseer. Elkeen het ’n ander tydskaal, en die stadigste een bepaal gewoonlik hoe lank gebruikers wag.

Dan kies die kliënt B deur watter meganisme die ontplooiing ook al ondersteun: ’n tweede gekonfigureerde remote, ’n DNS-naam wat na ’n gesonde adres opgelos word, of roetering wat nou ’n ander pad verkies. Keuse is ’n beleidstap, en dit moet voor die faling bestaan, anders gebeur dit per ongeluk.

Wat B kan en nie kan erf nie

B kan ’n konfigurasiesjabloon, ’n sertifikaatowerheid en ’n verifikasiebeleid met A deel. Dit kan nie die lewende sekuriteitsassosiasies erf nie. Sessiesleutels, sekuriteitsparameter-indekse en volgordetoestand behoort aan die verhouding wat A en die kliënt geskep het, en B het nie een daarvan nie.

Om daardie toestand tussen gateways te skuif, is ’n werklike ingenieursprobleem, en daarom behandel die strongSwan-hoëbeskikbaarheidsdokumentasie dit as ’n clusterontwerp eerder as ’n konfigurasievlag. ’n Spesifieke clusterresep is nie ’n algemene antwoord vir ’n wolknetwerk nie, en om dit sonder die ondersteunende infrastruktuur te kopieer, koop kompleksiteit in plaas van kontinuïteit.

Om ’n vars verhouding te vestig

Met B gekies, doen die kliënt ’n nuwe IKE-uitruiling: nuwe nonces, nuwe Diffie-Hellman-waardes, nuwe identifiseerders vir die resulterende assosiasies. Verifikasie gebeur weer by B. As die ontwerp op masjienbewyse staatmaak, kan die herverbinding onbewaak wees; as dit ’n menslike faktor vereis, moet iemand teenwoordig wees vir die failover om te voltooi.

Definieer daardie gebruikerservaring voor die onderbreking, nie tydens dit nie. Sê duidelik wat die kliënt sal doen, hoe lank dit sal probeer en wat dit sal wys wanneer dit opgee, want die verskil tussen ’n minuut se herverbinding en ’n ondersteuningsoproep is gewoonlik dokumentasie en ’n getoetste profiel.

Om dieselfde binne-adres te behou, help toepassings wat ’n stabiele plaaslike identiteit verwag, en dit behou nie hul sessies nie. NAT-bindings verval, TCP-verbindings word herstel en enigiets met sy eie timeout besluit onafhanklik of dit weer probeer.

Twee tonnels parallel is ’n ander ontwerp

Om albei tonnels gelyk te laat loop, is ’n geldige patroon wanneer albei gateways en die roeteringsontwerp dit ondersteun. Roeteseleksie kies dan die aktiewe pad, en die terugpad moet ooreenstem, anders verlaat verkeer deur een gateway en kom deur die ander terug sonder toestand om dit te pas.

Oorvleuelende tonnelbeleide skep nie op sigself ordelike failover nie. Hulle skep twee kandidate, en iets moet deterministies tussen hulle besluit, of dit nou ’n roeteringsmaatstaf, ’n beleidsprioriteit of ’n eksplisiete voorkeur in die kliënt is.

Watter vorm jy ook al kies, skryf die kontrak neer: hoe die faling bespeur word, hoe die alternatief gekies word, watter verifikasie die alternatief vereis en hoe lank die herverbinding na verwagting sal neem. ’n Gedeelde IP kan ontdekking vereenvoudig, maar dit is nie ’n sinoniem vir deurlopende toestand nie, en beskikbaarheid is in elk geval ’n ontwerp.