VPN-vikasieto: kun paluupolku jää vanhaan tunneliin

Varatunneli nousee, ensisijainen kaatuu ja sovellus yhä aikakatkaistaan. Molemmilla sivustoilla tunnelin tila näyttää terveeltä, ja juuri se hämmentää. Vikasieto, joka siirtää pyynnöt varalle mutta jättää vastaukset vanhalle polulle, ei ole vikasieto. Alla oleva ohje testaa paluupolun, ei vain kättelyä.

Kirjaa ensin reitit molemmissa päissä; yhden sivuston näkymä ei voi näyttää epäsymmetristä polkua. Se on myös vaihe, joka jätetään useimmin väliin aikapaineessa.

Kirjaa molempien sivustojen reitit ennen testiä

Kirjoita jokaiselle suojatulle etuliitteelle ensisijainen reitti, varareitti ja niiden välillä valitseva preferenssi. Sisällytä jokaisen VPN-päätepisteen takana oleva LAN-yhdyskäytävä, koska päätepiste on harvoin viimeinen hyppy.

Staattiset metriikat, seuratut reitit ja dynaaminen reititys ilmaisevat kelpoisuuden eri tavoin. Tiedä, mitä suunnitelmasi käyttää, ja mitä tarvitaan, jotta vaihtoehto tulee aktiiviseksi. Kirjoita ehto reitin viereen, esimerkiksi pienempi metriikka, kunnes testi epäonnistuu.

Tee tämä molemmilla sivustoilla. Vara, jota suositaan toisella puolella ja jätetään huomiotta toisella, tuottaa juuri sen epäsymmetrian, jota yrität välttää.

Seuraa pyyntöjä ja vastauksia kussakin vaiheessa

Käytä harmitonta sallittua sovellusta ja seuraa kolmea vaihetta: normaali, ensisijaisen polun vika ja palautus. Kirjaa kussakin vaiheessa, mikä tunneli kuljettaa pyynnön ja mikä vastauksen. Tavoitettavissa oleva vastapuolen osoite ei todista, että suojattu sovelluspolku toimii. Tallenna molemmilla sivustoilla, jotta yksisuuntainen virtaus näkyy.

Jos pyynnöt liikkuvat eivätkä vastaukset, tarkista etäsivuston reitti asiakkaan etuliitteeseen ja sen preferenssi varalle. Se on reitityspäätös, ei tunnelin vika.

Palauta alkuperäinen tila testin jälkeen ja varmista, että ensisijainen on jälleen suosituin. Palautettu ensisijainen, jota ei suosita, on vikasietosuunnittelu, joka ei ole valmis.

Käsittele istunnon tila, kun yhdyskäytävä vaihtuu

Palomuurit ja NAT voivat pitää yhteyden tilaa yhdellä yhdyskäytävällä, eikä polun vaihto toiselle yhdyskäytävälle siirrä sitä. Jotkin sovellukset yhdistävät itse uudelleen; toiset epäonnistuvat, kunnes istunto palautetaan. Jos vara muuttaa julkista lähdettä tai käännettyä yksityistä osoitetta, myös etäkäytön säännöt voivat reagoida. Dokumentoi kaikki odotettu istunnon uudelleenkäynnistys sen sijaan, että lupaisit keskeytyksettömän vikasiedon.

Pidä osoitteistus vakaana siellä, missä sovellus sitä vaatii. Vikasietosuunnittelu, joka muuttaa lähdeosoitetta joka istunnolle, on suunnitteluvalinta, ja se pitäisi kirjoittaa. Tämä valinta määrää, kuinka paljon katkosta käyttäjät todella huomaavat.

Testaa sovellusta, joka pitää pitkää istuntoa, älä vain uutta pyyntöä.

Palauta ensisijainen ja tarkista värähtely

Varmista, että reittikuvaukset tai preferenssit asettuvat ilman oskillaatiota. Värähtelevä ensisijainen voi olla häiritsevämpi kuin selkeä katkos, koska jokainen siirtymä nollaa tilan.

Pidä yhdyskäytävän hallinta tavoitettavissa palautuspolun kautta, jotta testi ei lukitse sinua ulos. Kirjaa vaiheet, havaitut polut ja palautumisaika; juuri se kirjaus tekee seuraavasta vikasiedosta ennustettavan. strongSwanin välitystä koskevat muistiinpanot ovat hyödyllisiä, kun päätepisteet ovat Linux-isäntiä.