Näin rakennat VPN:n varayhteyskäytännön reitittimelle ilman vuotoja

Varasiiirtymä toimi täsmälleen niin kuin se oli määritetty, ja juuri se oli ongelma. Kun ensisijainen tunneli katkesi, reititin siirsi oletusreitin kaapelimodeemiin, kannettavat jatkoivat selaamista eikä kukaan soittanut. Kaksi päivää myöhemmin joku huomasi, että talousosaston jaettu kansio oli ollut kuusi tuntia saavutettavissa avoimen internetin kautta. VPN:n varayhteyskäytäntö reitittimellä ei ole reitityskikka; se on päätös siitä, mitä liikenteen pitää tehdä, kun ensisijainen reitti on poissa, ja sen päätöksen täytyy olla olemassa ennen kuin reitti katoaa.

Päätä lopputulos ennen kuin valitset ilmaisimen

Pöydällä on yleensä kolme lopputulosta: ohjata kärsineet asiakkaat varatunnelin kautta, antaa heidän käyttää tavallista WAN-yhteyttä tai estää heidät kokonaan. Kirjoita ylös, mikä koskee mitäkin VLANia, SSID:tä tai laiteluokkaa. Yksi litteä “vaihda WAN-yhteyteen” -sääntö on syy siihen, miksi yllä mainittu talouskansio päätyi julkiselle reitille.

Nämä kolme eivät ole keskenään vaihdettavia. WAN-varayhteys pitää tukipisteen vastaamassa puhelimiin samalla kun se paljastaa sisäiset nimet paikalliselle resolverille. Varatunneli säilyttää käytännön mutta voi päätyä lähtöosoitteeseen, jota toinen pää ei hyväksy. Estäminen on oikein palkka-VLANille ja väärin vierasverkolle, joka ei koskaan käyttänyt tunnelia.

Sovita ilmaisin siihen vikaan, jota todella pelkäät

Kättelyn tila, liitännän tila ja käyttökelpoinen välitys ovat kolme eri signaalia, ja käyttäjälle merkitsee vain viimeinen. WireGuard-vertaiskohde voi näyttää tuoreen kättelyn, vaikka palveluntarjoajan ylävirta heittää paketit mustaan aukkoon. OpenVPN asiakasohjelma voi jäädä “yhdistetty”-tilaan, kun sen työntämä reitti lakkasi ratkeamasta.

pfSensessä käytännön järjestely on dpingerin ruokkima yhdyskäytäväryhmä, joka testaa valvontaosoitetta ja merkitsee yhdyskäytävän alas, kun häviö tai viive ylittää sen kynnykset. Kohdista valvonta johonkin tunnelin ulkopuoliseen, kuten kauko-LANin isäntään tai julkiseen osoitteeseen, johon pääset sen kautta. Sen kohdistaminen tunnelin omaan vertaisosoitteeseen mittaa sitä osaa, jonka tiedät jo olevan elossa.

Rakenna ryhmä niin, että varayhteys pysyy viimeisenä keinona

Käytä tasoja yhden litteän jäsenluettelon sijaan. Ensisijainen tasolla 1, varatunneli tasolla 2, WAN tasolla 3 vain niille VLANeille, joiden käytäntö sen sallii. pfSensessä tämä on kohdassa System > Routing > Gateway Groups: lisää molemmat yhdyskäytävät, anna niille eri tasot, aseta Trigger Level arvoon member down plus packet loss, tallenna ja käytä sitten ryhmää liitännän oletuksena tai niiden palomuurisääntöjen Gateway-kentässä, jotka sitä tarvitsevat.

OpenVPN-asiakasinstanssille pfSensen versiossa 2.5 ja uudemmissa instanssin Default Gateway -asetus päättää, korvaako tunneli lainkaan järjestelmän oletusreittiä. Sääntökohtainen käytäntöreititys käyttäytyy odotetusti vain silloin, kun oletettu reitti on todella asennettu. Tarkista muutoksen jälkeen Status > Gateways sen sijaan, että luottaisit tunnelin tilakuvakkeeseen.

Kaksi asetusta aiheuttavat suurimman osan väreilystä. Toinen on testausväli, joka on lyhyempi kuin palveluntarjoajan oma uudelleenkonvergenssi. Toinen on ryhmä, jossa ensisijainen ja vara jakavat tason, joten molemmat pysyvät kelvollisina koko ajan. Lisää hystereesiä häviö- ja viivekynnysten kautta ennen kuin käyttäjäsi tuntevat siirtymät puolestasi.

Sulje polut, joita tunneli ei koskaan omistanut

Ensin DNS-vuodot. Resolver vastaa edelleen WANissa ja välittää sieltä ulos, joten nimet ratkeavat edelleen operaattorin kautta, kun liikenne on kiinnitetty tunneliin. Rajoita resolverin lähtevät liitännät, työnnä sisäinen resolver asiakkaille ja estä portti 53 kaikelta muulta vain-VPN-VLANeilla.

IPv6 tarvitsee oman päätöksensä. Kaksipinoinen LAN voi menettää tunnelin ja säilyttää toimivan maailmanlaajuisen IPv6-oletusreitin, joten selaimet suosivat IPv6:ta ja poistuvat WANin kautta, kun IPv4 näyttää täysin suljetulta. Joko reititä IPv6 tunneliin tai lopeta maailmanlaajuisen etuliitteen mainostaminen, kun tunneli on alhaalla. Puolikas käytäntö on huonompi kuin ei mitään, koska se näyttää toimivan.

Sitten paluureitti. Jos varalähtö käyttää eri lähdeosoitetta, toisen pään on tiedettävä, miten liikenne lähetetään sinne takaisin, ja jokainen vanhaan osoitteeseen sidottu tila on jo kuollut. Istunnot, jotka olivat auki ensisijaisen katketessa, eivät siirry; ne pysähtyvät, kunnes ne vanhenevat, ja sovellus päättää, mitä sille tehdään.

Testaa katkeaminen, väreily ja paluutie

Vedä ensisijainen irti harmittoman liikenteen aikana ja lue sitten neljä asiaa: Status > Gateways ryhmän jäsenten tiloille, pfctl -ss vanhaan yhdyskäytävään yhä kiinnitetyille tiloille, traceroute asiakkaalta lähtöreitille ja resolver-kysely, josta näet, mikä palvelin vastasi.

Väreile nyt. Nosta ensisijainen kolmeksikymmeneksi sekunniksi, laske kolmeksikymmeneksi, kahdesti. Jos liikenne seuraa jokaista siirtymää, kynnykset ovat liian tiukat tai tasot ovat väärin. Korjaa se omalla aikataulullasi, koska muuten palveluntarjoaja tekee sen omallaan.

Varmista lopuksi, että voit yhä hallita reititintä. Pidä kaistanulkoinen polku, kuten konsolikaapeli, hallinta-VLAN tai matkapuhelinmodeemi. Varayhteystesti, joka lukitsee sinut ulos, on testi, jota et voi viimeistellä, eikä tavoitettamaton reititin voi palata itsestään.

Ennen kuin julistat käytännön valmiiksi, sinun pitäisi pystyä vastaamaan neljään kysymykseen avaamatta päätettä: mitkä VLANit saavat käyttää WANia tunnelin ollessa alhaalla, mitä ilmaisin tarkkailee ja kuinka kauan se odottaa, mitkä nimipalvelimet ja IPv6-reitit liikkuvat reitin mukana, ja miten pääset takaisin sisään, jos myös vara pettää. Jos jokin vastaus on “mitä oletus nyt olikaan”, käytäntö kuuluu yhä reitittimelle eikä sinulle.