VPN prebacivanje: kada povratni put ostane na starom tunelu

Rezervni tunel se diže, primarni pada, a aplikacija i dalje ističe vrijeme. Na oba lokaliteta status tunela izgleda zdravo, i to je ono što zbunjuje. Prebacivanje koje premješta zahtjeve na rezervu, ali ostavlja odgovore na starom putu, nije prebacivanje. Uputstvo ispod testira povratni put, a ne samo rukovanje.

Prvo zabilježite rute na oba kraja; pogled s jednog lokaliteta ne može pokazati asimetričan put. To je i korak koji se najčešće preskače pod vremenskim pritiskom.

Zabilježite rute oba lokaliteta prije testa

Za svaki zaštićeni prefiks zapišite primarnu rutu, rezervnu rutu i preferenciju koja bira između njih. Uključite LAN gateway iza svake VPN krajnje točke, jer krajnja točka rijetko je zadnji skok.

Statičke metrike, praćene rute i dinamičko rutiranje izražavaju podobnost na različite načine. Znajte koje vaš dizajn koristi i šta je potrebno da alternativa postane aktivna. Zapišite uvjet pored rute, na primjer nižu metriku dok test ne padne.

Učinite to na oba lokaliteta. Rezerva koja je preferirana na jednoj strani, a ignorirana na drugoj, stvara upravo asimetriju koju pokušavate izbjeći.

Pratite zahtjeve i odgovore u svakoj fazi

Koristite bezopasnu dopuštenu aplikaciju i promatrajte tri faze: normalnu, otkaz primarnog puta i obnovu. U svakoj fazi zabilježite koji tunel nosi zahtjev, a koji odgovor. Dostupna adresa partnera ne dokazuje da zaštićeni put aplikacije radi. Snimite na oba lokaliteta kako bi jednosmjerni tok bio vidljiv.

Ako se zahtjevi pomaknu, a odgovori ne, provjerite rutu udaljenog lokaliteta prema prefiksu klijenta i njegovu preferenciju prema rezervi. To je odluka o rutiranju, a ne otkaz tunela.

Vratite izvorno stanje nakon testa i potvrdite da je primarni put ponovno preferiran. Obnovljeni primarni put koji nije preferiran jest dizajn prebacivanja koji nije dovršen.

Upravljajte stanjem sesije kada se gateway promijeni

Vatrozidi i NAT mogu držati stanje veze na jednom gatewayu, a promjena puta na drugi gateway to ne prenosi. Neke se aplikacije same ponovno povezuju; druge ne rade dok se sesija ne uspostavi. Ako rezerva mijenja javni izvor ili prevedenu privatnu adresu, pravila daljinskog pristupa također mogu reagirati. Dokumentirajte svako očekivano ponovno pokretanje sesije umjesto da obećavate prebacivanje bez prekida.

Održavajte stabilno adresiranje gdje to aplikacija zahtijeva. Dizajn prebacivanja koji mijenja izvornu adresu za svaku sesiju jest dizajnerski izbor i treba ga zapisati. Taj izbor određuje koliko prekida korisnici zapravo primijete.

Testirajte aplikaciju koja drži dugu sesiju, a ne samo novi zahtjev.

Vratite primarni put i provjerite treperenje

Potvrdite da se najave ruta ili preferencije stabiliziraju bez osciliranja. Primarni put koji treperi može biti razorniji od jasnog prekida, jer svaki prijelaz resetira stanje.

Držite administraciju gatewaya dostupnom kroz put za oporavak kako vas sam test ne bi zaključao. Zabilježite faze, promatrane puteve i vrijeme oporavka; taj zapis čini sljedeće prebacivanje predvidljivim. Bilješke strongSwan o prosljeđivanju korisne su kada su krajnje točke Linux hostovi.