Tri soarten OpenVPN-failover op pfSense, tri meganismen
Reserve-WAN, alternatyf remote of in oare aktive tunnel: elke flater freget in oare pfSense-ynstelling, monitoaring en tastânbeslút. Neam earst dyn.
„OpenVPN failover“ op pfSense omfiemet op syn minst tri net besibbe ûntwerpen, en elk freget in oar meganisme. In tunnel libben hâlde oer in reserve-ynternetferbining, opnij ferbine mei in oare tsjinner en LAN-ferkear yn in oare besteande tunnel liede binne gjin farianten fan ien funksje. Kies de flater dêr'tst dy tsjin ferdigenest foardatst in poartegroep boust. In groep dy't ien fan harren reparearret docht neat foar de oare beide.
Neam de flater foardatst in groep boust
Skriuw de sin dy'tst ûnder in steuring wier hawwe wolst. „De tunnel ferbynt opnij oer de reserve-WAN“ en „de filiaal berikt noch hieltyd de applikaasje fia de oare tunnel“ binne ferskate sinnen. Allinne de earste giet oer it ferfier.
Keppelje dy dan oan in meganisme. Ferlies fan de lokale WAN is in probleem fan ynterfacekar, in deade fiere einpunt is in probleem fan 'e ferbininglist, en in ûnbrûkber paad binnen in besteande tunnel is in probleem fan rûteleasing en belied.
Lokale WAN: ferpleats it ferfier
Foar in pfSense OpenVPN-klant kiest de stipe multi-WAN-regeling in geskikte poartegroep as de ynterface dêr't de klant him oan bynt. Dat lit de bûtenste ferbining oer de reserveskyk fuortgean as de primêre mist. Op himsels feroaret it net hoe't it binnenste ferkear rûteleas is.
De tsjinnerkant fan itselde ûntwerp is apart. In OpenVPN-tsjinner dy't oer ferskate iepenbiere adressen berikber wêze moat, hat foar elk fan dy yngongen in harker en in yngongsbelied nedich, net allinne in klant dy't oer twa skaken skilje kin. Ien wurkjende iepenbiere yngong is gjin bewiis dat de twadde ynsteld is.
In beliedsrûteleasregel foar trochstjoerde LAN-pakketten is net de ynstelling dy't in lokaal oanmakke VPN-ferfierferbining ferpleatst. Dat binne twa ferskate syktochten, en it feroarjen fan 'e iene feroaret de oare net.
Fier einpunt: in oare tsjinner
In alternatyf remote is in funksje fan 'e ferbininglist. De klant besiket de folgjende yngong as de hjoeddeiske net antwurdet, wat nuttich is as in beskaat gasthjirder del is en net as dyn eigen opgeande skaak dat is. De twa flaters sjogge der itselde út fan in brûkersburo en freegje ferskate reparaasjes.
Elke kandidaat moat in echte ferfanger wêze: kompatibele ferifikaasje, kompatibel klantbelied en tagong ta deselde privee boarnen. In twadde gasthjirdernamme dy't nei deselde stikene ynfrastruktuer oplost is gjin reserve. In tsjinner sûnder de fereaske rûte is dat ek net, hoe sûn oft syn hânjaan der ek útsjocht.
Dit meganisme lit ek gjin twa tunnels tagelyk trochstjoere. It ferfangt de iene ferbining troch de oare, opienfolgjend, en it gat der tusken is sichtber foar alles wat rûn.
Tunnelpaad: kies in oare útgong
As twa tunnels al steane en it ferkear de sûnere brûke moat, is it meganisme in tawiisd VPN-ynterface mei syn eigen poarte, plus in útdruklike beliedsregel dy't it goede ferkear dêrhinne stjoert. In poartegroep oer dy tawiisde ynterfaces kin prioriteit en monitoaring útdrukke.
Dat ûntwerp giet oer kar, net oer werstel. Nije ferbiningen nei de twadde tunnel ferpleatse seit neat oer sesjes dy't al op 'e earste fêstige binne, en neat oer oft de fiere kant it nije boarneadres akseptearret. It as werstelmechanisme behannelje is de wize om ferwachtings te heech te setten.
As de eask is dat besteande sesjes oerlibje, sis dat dan eksplisyt. De measte ymplemintaasjes migrearje gjin libjend flux tusken tunnels, en ûntwerpe as soene se dat wol dwaan jout in failover dy't op in diagram goed liket en yn 'e praktyk elke iepen ferbining falle lit.
Monitors, NAT en de fail-closed-regel
In monitor moat eat teste dat de tunnel leverje moat. In doel dat fan 'e tunnelpartner antwurdet mar net fan it applikaasjenetwurk dêrefter, sil sûn rapportearje wylst brûkers neat sjogge. In ûnberikber diagnostysk doel sil dea rapportearje wylst it paad goed is. Kies it adres mei opset en befêstigje dat it allinne fia de bedoelde tunnel berikber is.
Kontrolearje de útgeande NAT foar beide útgongen. In wurkjende oersetting op 'e primêre beskriuwt net it boarneadres fan 'e reserve, en it fiere privee netwurk hat in weromrûte nedich dy't by de boarne past dy'tst presintearrest. In oersetting dy't op it iene paad goed is, kin op it oare stil ferkeard wêze.
Beslis dan wat der bart mei it ferkear dat nea de WAN brûke mei. pfSense hat definiearre gedrach foar regels wêrfan't de keazen poarte del is, en in lettere brede trochlittingsregel of in standertrûte kin dyn bedoeling ferneatigje. Skriuw de blokkearre útkomst as eask op en ferifiearje dy troch it paad del te heljen.
Test ferlies en werstel apart, mei ferkear datst generearje meist, en let tagelyk op trije dingen: de WAN dy't de bûtenste ferbining draacht, de tunnel dy't it applikaasjefersyk draacht, en it paad dat it antwurd nimt. In pear griene poarte-yndikatoaren is net ien fan dy trije. Netgate syn multi-WAN-gids beskriuwt de ferfierbining en de exportearre klantalternativen dêr't dit op berêst.