VPN-oorskakeling: wanneer die terugpad op die ou tonnel bly

Die rugsteuntonnel kom op, die primêre tonnel val weg, en die toepassing hou steeds aan om te verstek. Aan albei kante lyk die tonnelstatus gesond, en dit is juis wat die verwarring veroorsaak. ’n Oorskakeling wat versoeke na die rugsteun skuif maar die antwoorde op die ou pad laat, is nie ’n oorskakeling nie. Die prosedure hieronder toets die terugpad, nie net die handskud nie.

Teken eers die roetes aan albei kante op; ’n siening van een terrein alleen kan nie ’n asimmetriese pad wys nie. Dit is ook die stap wat die meeste onder tydsdruk oorgeslaan word.

Teken albei terreine se roetes voor die toets op

Vir elke beskermde voorvoegsel, skryf die primêre roete, die rugsteunroete en die voorkeur wat tussen hulle kies. Sluit die LAN-netwerkpoort in agter elke VPN-eindpunt, want die eindpunt is selde die laaste sprong.

Statiese maatstawwe, gevolgde roetes en dinamiese roetering druk geskiktheid elkeen anders uit. Weet watter een jou ontwerp gebruik, en wat nodig is vir die alternatief om aktief te word. Skryf die voorwaarde langs die roete, byvoorbeeld ’n laer maatstaf totdat die toets misluk.

Doen dit aan albei terreine. ’n Rugsteun wat aan die een kant verkies en aan die ander kant geïgnoreer word, lewer presies die asimmetrie wat jy probeer vermy.

Kyk na versoeke en antwoorde in elke fase

Gebruik ’n onskadelike toegelate toepassing en waarneem drie fases: normaal, primêre faling en herstel. Teken in elke fase op watter tonnel die versoek dra en watter die antwoord dra. ’n Bereikbare eweknie-adres bewys nie dat die beskermde toepassingspad werk nie. Teken dit aan albei terreine op sodat ’n eenrigtingvloei sigbaar word.

As versoeke skuif en antwoorde nie, kyk na die afgeleë terrein se roete na die kliëntvoorvoegsel en sy voorkeur vir die rugsteun. Dit is ’n roeteringsbesluit, nie ’n tonnelfaling nie.

Herstel die oorspronklike toestand ná die toets en bevestig dat die primêre weer verkies word. ’n Herstelde primêre wat nie verkies word nie, is ’n oorskakelingsontwerp wat nog nie klaar is nie.

Hanteer sessietoestand wanneer die netwerkpoort verander

Firewalls en NAT kan verbindingstoestand op een netwerkpoort hou, en ’n padverandering na ’n ander netwerkpoort dra dit nie oor nie. Sommige toepassings herverbind vanself; ander misluk totdat die sessie herstel word. As die rugsteun die publieke bron of die vertaalde private adres verander, kan afstandstoegangsreëls ook reageer. Dokumenteer enige verwagte sessieherbegin in plaas daarvan om onderbrekingsvrye oorskakeling te belowe.

Handhaaf stabiele adressering waar die toepassing dit vereis. ’n Oorskakelingsontwerp wat die bronadres vir elke sessie verander, is ’n ontwerpkeuse, en dit moet neergeskryf word. Daardie keuse bepaal hoeveel van die onderbreking gebruikers werklik opmerk.

Toets ’n toepassing wat ’n lang sessie hou, nie net ’n nuwe versoek nie.

Herstel die primêre en kyk vir fladder

Bevestig dat roeteaankondigings of voorkeure sonder ossillasie tot rus kom. ’n Fladderende primêre kan meer ontwrigtend wees as ’n duidelike onderbreking, want elke oorgang stel toestand terug.

Hou netwerkpoortadministrasie bereikbaar deur ’n herstelpad sodat die toets self jou nie uitsluit nie. Teken die fases, die waargenome paaie en die hersteltyd op; daardie rekord is wat die volgende oorskakeling voorspelbaar maak. Die strongSwan se aanstuurwenke is nuttig wanneer die eindpunte Linux-gashere is.