Kolme OpenVPN-failoverin lajia pfSensessä, kolme mekanismia

„OpenVPN-failover“ pfSensessä kattaa ainakin kolme toisistaan riippumatonta mallia, ja jokainen niistä tarvitsee eri mekanismin. Tunnelien pitäminen elossa varayhteyslinkin yli, uudelleenyhdistäminen toiseen palvelimeen ja LAN-liikenteen ohjaaminen toiseen olemassa olevaan tunneliin eivät ole yhden ominaisuuden muunnelmia. Valitse vika, jota vastaan puolustaudut, ennen kuin rakennat gateway-ryhmän. Ryhmä, joka korjaa yhden niistä, ei tee mitään kahdelle muulle.

Nimeä vika ennen kuin rakennat ryhmän

Kirjoita lause, jonka haluat olevan totta katkon aikana. „Tunneli yhdistyy uudelleen varayhteys-WANin yli“ ja „toimipiste tavoittaa sovelluksen edelleen toisen tunnelin kautta“ ovat eri lauseita. Vain ensimmäinen koskee siirtoa.

Sovita se sitten mekanismiin. Paikallisen WANin menetys on rajapinnan valinnan ongelma, kuollut remote-päätepiste on yhteysluettelon ongelma ja käyttökelvoton polku olemassa olevan tunnelin sisällä on reitityksen ja politiikan ongelma.

Paikallinen WAN: siirrä siirto

pfSense-OpenVPN-asiakkaalle tuettu monen WANin järjestely valitsee sopivan gateway-ryhmän rajapinnaksi, johon asiakas sitoutuu. Juuri se päästää ulomman yhteyden lähtemään varayhteyden kautta, kun ensisijainen pettää. Se ei sinänsä muuta sitä, miten sisempi liikenne reititetään.

Saman mallin palvelinpuoli on erillinen. OpenVPN-palvelin, jonka pitäisi olla tavoitettavissa useista julkisista osoitteista, tarvitsee kuuntelijan ja saapuvan politiikan jokaista näistä merkinnöistä varten, ei vain asiakasta, joka osaa soittaa kahden linkin yli. Yksi toimiva julkinen merkintä ei ole todiste siitä, että toinen on määritetty.

Välitettyjen LAN-pakettien politiikkareitityssääntö ei ole se asetus, joka siirtää paikallisesti luodun VPN-siirtoyhteyden. Ne ovat kaksi eri hakua, eikä toisen muuttaminen muuta toista.

Remote-päätepiste: toinen palvelin

Vaihtoehtoinen remote on yhteysluettelon ominaisuus. Asiakas kokeilee seuraavaa merkintää, kun nykyinen ei vastaa, mikä on hyödyllistä silloin, kun tietty isäntä on alhaalla eikä silloin, kun oma uplink on. Kaksi vikaa näyttävät samoilta käyttäjän työpöydältä ja vaativat eri korjaukset.

Jokaisen ehdokkaan on oltava todellinen korvaaja: yhteensopiva todennus, yhteensopiva asiakaspolitiikka ja pääsy samoihin yksityisiin resursseihin. Toinen isäntänimi, joka ratkeaa samaan rikkoutuneeseen infrastruktuuriin, ei ole varayhteys. Palvelin ilman vaadittua reittiä ei ole sitä myöskään, kuinka terveeltä sen kättely näyttää.

Tämä mekanismi ei myöskään saa kahta tunnelia välittämään yhtä aikaa. Se korvaa yhteyden toisella peräkkäin, ja niiden välinen aukko näkyy kaikelle, mikä oli käynnissä.

Tunnelin polku: valitse toinen ulostulo

Kun kaksi tunnelia on jo pystyssä ja liikenteen pitäisi käyttää terveempää, mekanismi on määritetty VPN-rajapinta omalla gatewayllä sekä nimenomainen politiikkasääntö, joka lähettää oikean liikenteen sinne. Näiden määritettyjen rajapintojen yli voi ilmaista prioriteetin ja valvonnan gateway-ryhmällä.

Se malli koskee valintaa, ei palautumista. Uusien yhteyksien siirtäminen toiseen tunneliin ei kerro mitään jo ensimmäiselle muodostetuista istunnoista eikä siitä, hyväksyykö vastapuoli uuden lähdeosoitteen. Sen käsitteleminen palautumismekanismina on tapa asettaa odotukset liian korkealle.

Jos vaatimus on, että olemassa olevat istunnot säilyvät, sano se selvästi. Useimmat toteutukset eivät siirrä elävää virtausta tunnelien välillä, ja suunnitteleminen ikään kuin ne tekisivät tuottaa failoverin, joka näyttää kaaviossa oikealta ja pudottaa käytännössä jokaisen avoimen yhteyden.

Monitorit, NAT ja fail-closed-sääntö

Monitorin pitäisi testata jotain, mitä tunneli on tarkoitettu toimittamaan. Kohde, joka vastaa tunnelin vertaiselta mutta ei sen takana olevalta sovellusverkolta, raportoi terveeksi, kun käyttäjät eivät näe mitään. Tavoittamaton diagnostiikkakohde raportoi kuolleeksi, kun polku on kunnossa. Valitse osoite harkiten ja vahvista, että se on tavoitettavissa vain aiotun tunnelin kautta.

Tarkista lähtevä NAT molemmille ulostuloille. Ensisijaisella toimiva käännös ei kuvaa varayhteyden lähdeosoitetta, ja kaukana oleva yksityinen verkko tarvitsee paluureitin, joka vastaa sitä lähdettä, jonka esität. Yhdellä polulla oikea käännös voi olla toisella hiljaa väärä.

Päätä sitten, mitä tapahtuu liikenteelle, joka ei saa koskaan käyttää WANia. pfSensessä on määritelty käyttäytyminen säännöille, joiden valittu gateway on alhaalla, ja myöhempi laaja sallintasääntö tai oletusreitti voi kumota aikomuksesi. Kirjoita estetty lopputulos vaatimukseksi ja vahvista se ottamalla polku alas.

Testaa menetys ja palautuminen erikseen liikenteellä, jonka saat tuottaa, ja seuraa kolmea asiaa yhtä aikaa: WANia, joka kantaa ulomman yhteyden, tunnelia, joka kantaa sovelluspyynnön, ja polkua, jonka vastaus ottaa. Pari vihreää gateway-ilmaisinta ei ole yksi noista kolmesta. Netgaten monen WANin opas kuvaa siirtositeen ja viedyt asiakasvaihtoehdot, joihin tämä nojaa.