Kaksi IPsec-yhdyskäytävää ilman yhteistä IP:tä: mitä failover oikeasti tekee

Tapa yhdyskäytävä A kesken palaverin ja katso, miten tunneli palaa B:n kautta minuuttia myöhemmin; yhteys toimii, videopuhelu ehkä ei. Se on kylmän failoverin rehellinen muoto kahden itsenäisen osoitteen IPsec-yhdyskäytävän välillä. Asiakas valitsee päätepisteen uudelleen ja rakentaa uuden suhteen, mikä palauttaa tavoitettavuuden siirtämättä vanhan istunnon salausavausta. Jakson läpikäynti tekee selväksi, mitkä lupaukset suunnittelu voi pitää.

Aseta näyttämö: kaksi osoitetta, ei kelluvaa IP:tä

Yhdyskäytävä A vastaa yhdessä saavutettavassa osoitteessa ja yhdyskäytävä B toisessa. Asiakkaalla on hyväksytty tapa valita B, kun A on poissa, eikä ole yhteistä ulkoista osoitetta, jota molemmat yhdyskäytävät vaatisivat. Tässä suunnittelussa virtuaalinen IP tarkoittaa juuri sitä yhteistä sisääntulopistettä, ei etäkäyttöasiakkaalle annettua sisäistä osoitetta.

Tämä määritelmä on tärkeä, koska kaksi ajatusta menevät tiketeissä sekaisin eikä toisen korjaus ole toisen korjaus. Raportti, jonka mukaan yhteinen sisäänkäynti ei seurannut yhdyskäytävää, kuvaa yhtä suunnittelua. Raportti, jonka mukaan kannettava menetti sisäisen osoitteensa, kuvaa asiakkaan vuokraa. Eri omistajat, eri lokit, eri korjaukset.

Käy vika läpi: havaitse ja valitse sitten uudelleen

Ensin jokin huomaa, että A lakkasi vastaamasta. Se voi olla kuolleen vastapuolen tunnistus tunnelikerroksessa, reititysprotokolla, joka vetää polun pois, tai sovelluksen aikakatkaisu, joka lopulta pakottaa uudelleenyhdistämisen. Jokaisella on eri aikaskaala, ja hitain määrää yleensä, kuinka kauan käyttäjät odottavat.

Sitten asiakas valitsee B:n millä tahansa käyttöönoton tukemalla mekanismilla: toinen määritetty etäpiste, terveeksi osoitteeksi ratkaistu DNS-nimi tai reititys, joka suosii nyt toista polkua. Valinta on käytäntöaskel, ja sen on oltava olemassa ennen vikaa, muuten se tapahtuu sattumalta.

Mitä B voi periä ja mitä ei

B voi jakaa A:n kanssa kokoonpanomallin, varmentajan ja todennuskäytännön. Se ei voi periä eläviä suojaustukiyhtymiä. Istuntoavaimet, suojausparametrien indeksit ja järjestystila kuuluvat suhteeseen, jonka A ja asiakas loivat, eikä B:llä ole niistä yhtäkään.

Tämän tilan siirtäminen yhdyskäytävien välillä on todellinen insinööriongelma, minkä vuoksi strongSwanin korkean käytettävyyden dokumentaatio käsittelee sitä klusterisuunnitteluna eikä kokoonpanolippuna. Tietty klusteriresepti ei ole yleinen vastaus pilviverkkoon, ja sen kopioiminen ilman tukevaa infrastruktuuria ostaa monimutkaisuutta jatkuvuuden sijaan.

Uuden suhteen luominen

Kun B on valittu, asiakas tekee uuden IKE-vaihdon: uudet nonce-arvot, uudet Diffie-Hellman-arvot, uudet tunnisteet syntyville tukiyhtymille. Todennus tapahtuu uudelleen B:llä. Jos suunnittelu nojaa koneen tunnistetietoihin, uudelleenyhdistäminen voi tapahtua valvomatta; jos se vaatii inhimillisen tekijän, jonkun on oltava paikalla, jotta failover valmistuu.

Määritä tämä käyttökokemus ennen katkoa, älä sen aikana. Sano selvästi, mitä asiakas tekee, kuinka kauan se yrittää ja mitä se näyttää luovuttaessaan, koska ero minuutin uudelleenyhdistämisen ja tukipuhelun välillä on yleensä dokumentaatio ja testattu profiili.

Saman sisäisen osoitteen säilyttäminen auttaa sovelluksia, jotka odottavat vakaata paikallista identiteettiä, eikä se säilytä niiden istuntoja. NAT-sidokset vanhenevat, TCP-yhteydet nollataan ja mikä tahansa omalla aikakatkaisullaan päättää itsenäisesti, yrittääkö uudelleen.

Kaksi tunnelia rinnakkain on eri suunnittelu

Molempien tunnelien ajaminen yhtä aikaa on kelvollinen malli, kun molemmat yhdyskäytävät ja reitityssuunnittelu tukevat sitä. Silloin reitin valinta valitsee aktiivisen polun, ja paluupolun on oltava yhtä mieltä, muuten liikenne lähtee yhden yhdyskäytävän kautta ja palaa toisen kautta ilman tilaa, joka yhdistäisi sen.

Päällekkäiset tunnelikäytännöt eivät itsessään luo järjestelmällistä failoveria. Ne luovat kaksi ehdokasta, ja jonkin on päätettävä niiden välillä deterministisesti, oli se sitten reittimetriikka, käytännön prioriteetti tai asiakkaan nimenomainen mieltymys.

Minkä muodon valitsetkin, kirjoita sopimus: miten vika havaitaan, miten vaihtoehto valitaan, mitä todennusta vaihtoehto vaatii ja kuinka kauan uudelleenyhdistämisen odotetaan kestävän. Yhteinen IP voi yksinkertaistaa löytämistä, mutta se ei ole jatkuvan tilan synonyymi, ja käytettävyys on joka tapauksessa suunnittelua.