Failover ng VPN: kapag ang pabalik na landas ay nanatili sa lumang tunnel

Umaangat ang backup na tunnel, bumabagsak ang pangunahin, at nag-time out pa rin ang application. Sa dalawang site ay mukhang malusog ang kalagayan ng tunnel, at iyon ang nakakalito. Ang failover na naglilipat ng mga kahilingan sa backup pero iniiwan ang mga tugon sa lumang landas ay hindi failover. Sinusubukan ng gabay sa ibaba ang pabalik na landas, hindi lang ang handshake.

Itala muna ang mga ruta sa dalawang dulo; ang tanawin mula sa isang site ay hindi makakapagpakita ng asymmetrical na landas. Ito rin ang hakbang na pinakamadalas laktawan sa ilalim ng pressure ng oras.

Itala ang mga ruta ng dalawang site bago ang pagsubok

Para sa bawat protektadong prefix, isulat ang pangunahing ruta, ang backup na ruta at ang kagustuhang pumipili sa pagitan nila. Isama ang LAN gateway sa likod ng bawat VPN endpoint, dahil ang endpoint ay bihirang maging huling hop.

Ang mga static na metric, sinusubaybayang ruta at dynamic na routing ay nagpapahayag ng pagiging karapat-dapat sa magkaibang paraan. Alamin kung alin ang ginagamit ng iyong disenyo, at ano ang kailangan para maging aktibo ang alternatibo. Isulat ang kundisyon sa tabi ng ruta, halimbawa mas mababang metric hanggang mabigo ang probe.

Gawin ito sa dalawang site. Ang backup na ginustong sa isang panig at binabalewala sa kabila ay gumagawa ng eksaktong asimetriyang sinusubukan mong iwasan.

Obserbahan ang mga kahilingan at tugon sa bawat yugto

Gumamit ng hindi nakakapinsalang pinapayagang application at obserbahan ang tatlong yugto: normal, pagpalya ng pangunahing landas at pagpapanumbalik. Sa bawat yugto, itala kung aling tunnel ang nagdadala ng kahilingan at alin ang tugon. Ang maabot na peer address ay hindi nagpapatunay na gumagana ang protektadong landas ng application. Itala sa dalawang site para makita ang isang-direksyong daloy.

Kung gumagalaw ang mga kahilingan at hindi ang mga tugon, suriin ang ruta ng malayong site patungo sa prefix ng kliyente at ang kagustuhan nito para sa backup. Iyon ay desisyon sa routing, hindi pagpalya ng tunnel.

Ibalik ang orihinal na kalagayan pagkatapos ng pagsubok at kumpirmahin na pinipili muli ang pangunahin. Ang naibalik na pangunahin na hindi pinipili ay disenyo ng failover na hindi pa tapos.

Pamahalaan ang kalagayan ng session kapag nagbago ang gateway

Maaaring hawakan ng mga firewall at NAT ang kalagayan ng koneksyon sa isang gateway, at ang pagbabago ng landas patungo sa ibang gateway ay hindi ito dinadala. Ang ilang application ay kusang kumokonekta muli; ang iba ay nabibigo hanggang maibalik ang session. Kung babaguhin ng backup ang pampublikong pinagmulan o ang isinaling pribadong address, maaaring tumugon din ang mga tuntunin sa malayuang pag-access. Idokumento ang anumang inaasahang muling pag-restart ng session sa halip na mangako ng failover na walang pagkaantala.

Panatilihing matatag ang pag-address kung saan kinakailangan ito ng application. Ang disenyo ng failover na nagbabago ng source address sa bawat session ay desisyong disenyo, at dapat itong isulat. Ang desisyong iyon ang tumutukoy kung gaano karaming pagkaantala ang talagang napapansin ng mga user.

Subukan ang application na humahawak ng mahabang session, hindi lang bagong kahilingan.

Ibalik ang pangunahin at suriin ang pag-flap

Kumpirmahin na ang mga anunsyo ng ruta o kagustuhan ay nagiging matatag nang walang oscillation. Ang nag-flaflap na pangunahin ay maaaring mas nakakagambala kaysa sa malinaw na pagpalya, dahil bawat transisyon ay nire-reset ang kalagayan.

Panatilihing maabot ang administrasyon ng gateway sa pamamagitan ng landas ng pagbawi para hindi ka mailabas ng pagsubok mismo. Itala ang mga yugto, ang mga naobserbahang landas at ang oras ng pagbawi; ang talang iyon ang gumagawa ng susunod na failover na mahuhulaan. Ang mga tala ng strongSwan tungkol sa pagpapasa ay kapaki-pakinabang kapag ang mga endpoint ay Linux host.