Drie soorte OpenVPN-failover op pfSense, drie meganismes

„OpenVPN-failover” op pfSense dek ten minste drie onverwante ontwerpe, en elkeen vereis 'n ander meganisme. Om 'n tonnel lewendig te hou oor 'n rugsteun-internetverbinding, om weer aan 'n ander bediener te koppel en om LAN-verkeer in 'n ander bestaande tonnel in te stuur is nie variante van een funksie nie. Kies die fout waarteen jy jou verdedig voordat jy 'n poortgroep bou. 'n Groep wat een daarvan regmaak, doen niks vir die ander twee nie.

Noem die fout voordat jy 'n groep bou

Skryf die sin wat jy tydens 'n onderbreking waar wil hê. „Die tonnel koppel weer oor die rugsteun-WAN” en „die tak bereik steeds die toepassing deur die ander tonnel” is verskillende sinne. Net die eerste gaan oor die vervoer.

Pas dit dan by 'n meganisme. Verlies van die plaaslike WAN is 'n koppelvlakkeuse-probleem, 'n dooie afgeleë eindpunt is 'n verbindingslys-probleem, en 'n onbruikbare pad binne 'n bestaande tonnel is 'n roetering- en beleidsprobleem.

Plaaslike WAN: skuif die vervoer

Vir 'n pfSense OpenVPN-kliënt kies die ondersteunde multi-WAN-reëling 'n gepaste poortgroep as die koppelvlak waaraan die kliënt bind. Dit is wat die buitenste verbinding oor die rugsteunskakel laat vertrek wanneer die primêre faal. Op sigself verander dit nie hoe die binneste verkeer geroeteer word nie.

Die bedienerkant van dieselfde ontwerp is apart. 'n OpenVPN-bediener wat oor verskeie openbare adresse bereikbaar moet wees, het 'n luisteraar en 'n inkomende beleid vir elkeen van daardie inskrywings nodig, nie net 'n kliënt wat oor twee skakels kan skakel nie. Een werkende openbare inskrywing is nie bewys dat die tweede opgestel is nie.

'n Beleidsroetering-reël vir deurgestuurde LAN-pakkette is nie die instelling wat 'n plaaslik geskepte VPN-vervoerverbinding skuif nie. Dit is twee verskillende soektogte, en om die een te verander verander nie die ander nie.

Afgeleë eindpunt: 'n ander bediener

'n Alternatiewe remote is 'n funksie van die verbindingslys. Die kliënt probeer die volgende inskrywing wanneer die huidige nie antwoord nie, wat nuttig is wanneer 'n spesifieke gasheer plat is en nie wanneer jou eie opstroomskakel dit is nie. Die twee foute lyk dieselfde van 'n gebruiker se lessenaar en verg verskillende regstellings.

Elke kandidaat moet 'n werklike plaasvervanger wees: versoenbare verifiëring, versoenbare kliëntbeleid en toegang tot dieselfde private hulpbronne. 'n Tweede gasheernaam wat na dieselfde stukkende infrastruktuur oplos, is nie 'n rugsteun nie. 'n Bediener sonder die vereiste roete is ook nie, hoe gesond sy handdruk ook al lyk.

Hierdie meganisme laat ook nie twee tonnels gelyktydig deurstuur nie. Dit vervang die een verbinding ná die ander, en die gaping tussen hulle is sigbaar vir alles wat geloop het.

Tonnelpad: kies 'n ander uitgang

Wanneer twee tonnels al staan en die verkeer moet die gesonder een gebruik, is die meganisme 'n toegewysde VPN-koppelvlak met sy eie poort, plus 'n uitdruklike beleidsreël wat die regte verkeer daarheen stuur. 'n Poortgroep oor daardie toegewysde koppelvlakke kan prioriteit en monitering uitdruk.

Daardie ontwerp gaan oor keuse, nie oor herstel nie. Om nuwe verbindings na die tweede tonnel te skuif sê niks oor sessies wat al op die eerste gevestig is nie, en niks oor of die oorkant die nuwe bronadres sal aanvaar nie. Om dit as 'n herstelmechanisme te behandel, is hoe verwagtings te hoog gestel word.

As die vereiste is dat bestaande sessies oorleef, sê dit uitdruklik. Die meeste implementasies migreer nie 'n lewende vloei tussen tonnels nie, en om te ontwerp asof hulle dit doen, lewer 'n failover wat korrek op 'n diagram lyk en in die praktyk elke oop verbinding laat val.

Monitors, NAT en die fail-closed-reël

'n Monitor moet iets toets wat die tonnel veronderstel is om te lewer. 'n Teiken wat van die tonnelmaat antwoord maar nie van die toepassingsnetwerk daar agter nie, sal gesond rapporteer terwyl gebruikers niks sien nie. 'n Onbereikbare diagnostiese teiken sal dood rapporteer terwyl die pad reg is. Kies die adres doelbewus en bevestig dat dit net deur die beoogde tonnel bereikbaar is.

Kontroleer die uitgaande NAT vir beide uitgange. 'n Werkende vertaling op die primêre beskryf nie die rugsteun se bronadres nie, en die afgeleë private netwerk het 'n terugroete nodig wat by die bron pas wat jy aanbied. 'n Vertaling wat op een pad korrek is, kan op die ander stil verkeerd wees.

Besluit dan wat met die verkeer gebeur wat nooit die WAN mag gebruik nie. pfSense het gedefinieerde gedrag vir reëls waarvan die gekose poort plat is, en 'n latere breë deurlaatreël of 'n verstekroete kan jou bedoeling verydel. Skryf die geblokkeerde uitkoms as 'n vereiste neer en verifieer dit deur die pad af te haal.

Toets verlies en herstel afsonderlik, met verkeer wat jy mag genereer, en let terselfdertyd op drie dinge: die WAN wat die buitenste verbinding dra, die tonnel wat die toepassingsversoek dra, en die pad wat die antwoord volg. 'n Paar groen poortaanwysers is nie een van daardie drie nie. Netgate se multi-WAN-gids beskryf die vervoerbinding en die uitgevoerde kliëntalternatiewe waarop dit berus.