Kaip sukonfigūruoti VPN perjungimo politiką maršrutizatoriuje be nuotėkių

Perjungimas veikė tiksliai taip, kaip buvo sukonfigūruotas, ir tai ir buvo problema. Kai pirminis tunelis nukrito, maršrutizatorius perkėlė numatytąjį maršrutą į kabelinį modemą, nešiojami kompiuteriai toliau naršė, ir niekas nepaskambino. Po dviejų dienų kažkas pastebėjo, kad finansų bendras aplankas šešias valandas buvo pasiekiamas atviru interneto keliu. VPN perjungimo politika maršrutizatoriuje nėra maršrutizavimo triukas; tai sprendimas, ką turi daryti srautas, kai pageidaujamo kelio nebėra, ir tas sprendimas turi egzistuoti prieš keliui dingstant.

Nuspręskite rezultatą prieš pasirinkdami detektorių

Paprastai ant stalo yra trys rezultatai: siųsti paveiktus klientus per atsarginį tunelį, leisti jiems naudoti įprastą WAN arba juos visiškai blokuoti. Užsirašykite, kuris taikomas kuriam VLAN, SSID ar įrenginių klasei. Viena plokščia “perjungti į WAN” taisyklė yra priežastis, kodėl aukščiau minėtas finansų aplankas atsidūrė viešame kelyje.

Šie trys nėra keičiami. WAN atsarginė kopija palaiko pagalbos tarnybą telefonu, bet atskleidžia vidinius pavadinimus vietiniam sprendėjui. Atsarginis tunelis išsaugo politiką, bet gali nusileisti išėjimo adresu, kurio kita pusė nepriima. Blokavimas teisingas darbo užmokesčio VLAN ir neteisingas svečių tinklui, kuris niekada nenaudojo tunelio.

Pritaikykite detektorių gedimui, kurio tikrai bijote

Rankos paspaudimo būsena, sąsajos būsena ir naudojamas persiuntimas yra trys skirtingi signalai, ir vartotojui svarbus tik paskutinis. WireGuard partneris gali rodyti neseniai įvykusį rankos paspaudimą, kol tiekėjo viršutinė srovė meta paketus į juodą duobę. OpenVPN klientas gali likti “prisijungęs” po to, kai jo stumtas maršrutas nustojo spręstis.

pfSense praktinė sandara yra dpinger maitinama šliuzų grupė, kuri tikrina stebėjimo adresą ir pažymi šliuzą kaip išjungtą, kai nuostoliai ar delsa viršija jo slenksčius. Nukreipkite tą stebėjimą į kažką už tunelio, pavyzdžiui, prieglobos kompiuterį tolimame LAN arba viešą adresą, kurį pasiekiate per jį. Nukreipimas į paties tunelio partnerio adresą matuoja tą dalį, kurią jau žinote esant gyvą.

Sukurkite grupę taip, kad atsarginė kopija liktų paskutinė priemonė

Naudokite lygius, o ne vieną plokščią narių sąrašą. Pirminis 1 lygyje, atsarginis tunelis 2 lygyje, WAN 3 lygyje tik tiems VLAN, kurių politika tai leidžia. pfSense tai yra po System > Routing > Gateway Groups: pridėkite abu šliuzus, suteikite jiems skirtingus lygius, nustatykite Trigger Level į member down plus packet loss, išsaugokite ir tada pritaikykite grupę kaip sąsajos numatytąją arba tų ugniasienės taisyklių, kurioms to reikia, Gateway lauke.

OpenVPN kliento egzemplioriui pfSense 2.5 ir naujesnėse versijose egzemplioriaus Default Gateway nustatymas lemia, ar tunelis apskritai pakeičia sistemos numatytąjį maršrutą. Politikos maršrutizavimas pagal taisyklę elgiasi taip, kaip tikitiesi, tik kai maršrutas, kurį darote prielaidą esant, iš tikrųjų įdiegtas. Po pakeitimo patikrinkite Status > Gateways, o ne pasitikėkite tunelio būsenos piktograma.

Du nustatymai sukelia didžiausią plazdėjimą. Vienas yra zondo intervalas, trumpesnis už paties tiekėjo pertvarką. Kitas yra grupė, kurioje pirminis ir atsarginis dalijasi lygiu, todėl abu visą laiką lieka tinkami. Pridėkite histerezę per nuostolių ir delsos slenksčius, kol jūsų vartotojai pajus perėjimus už jus.

Uždarykite kelius, kurių tunelis niekada neturėjo

Pirmiausia DNS nuotėkiai. Sprendėjas toliau atsakinėja WAN tinkle ir persiunčia iš jo, todėl vardai toliau sprendžiami per ISP, kol srautas prisegtas prie tunelio. Apribokite sprendėjo išeinančias sąsajas, stumkite vidinį sprendėją klientams ir blokuokite 53 prievadą viskam kitam tik-VPN VLAN.

IPv6 reikia savo sprendimo. Dvigubo kamino LAN gali prarasti tunelį ir išlaikyti veikiantį pasaulinį IPv6 numatytąjį maršrutą, todėl naršyklės teikia pirmenybę IPv6 ir išeina per WAN, o IPv4 atrodo visiškai uždarytas. Arba maršrutizuokite IPv6 į tunelį, arba nustokite skelbti pasaulinį prefiksą, kol tunelis išjungtas. Pusė politikos yra blogiau nei nieko, nes atrodo, kad ji veikia.

Tada grįžimo kelias. Jei atsarginis išėjimas naudoja kitą šaltinio adresą, kita pusė turi žinoti, kaip siųsti srautą atgal, ir kiekviena būsena, susieta su senu adresu, jau mirusi. Sesijos, atidarytos kai pirminis nukrito, nemigruoja; jos stovi, kol baigiasi jų laikas, o programa nusprendžia, ką daryti.

Išbandykite kritimą, plazdėjimą ir kelią atgal

Ištraukite pirminį, kol veikia nekenksmingas srautas, tada perskaitykite keturis dalykus: Status > Gateways grupės narių būsenoms, pfctl -ss būsenoms, vis dar prisegtoms prie seno šliuzo, traceroute iš kliento išėjimo keliui ir sprendėjo užklausą, kad pamatytumėte, kuris serveris atsakė.

Dabar suplazdėkite. Pakelkite pirminį trisdešimčiai sekundžių, nuleiskite trisdešimčiai, du kartus. Jei srautas seka kiekvieną perėjimą, slenksčiai per griežti arba lygiai neteisingi. Pataisykite tai pagal savo grafiką, nes kitaip tiekėjas padarys tai pagal savo.

Galiausiai patvirtinkite, kad vis dar galite administruoti maršrutizatorių. Laikykite ne juostos kelią, pavyzdžiui, konsolės kabelį, valdymo VLAN arba korinį modemą. Perjungimo testas, kuris jus užrakina, yra testas, kurio negalite baigti, o nepasiekiamas maršrutizatorius negali grįžti pats.

Prieš skelbdami politiką baigta, turėtumėte galėti atsakyti į keturis klausimus neatidarę terminalo: kurie VLAN gali naudoti WAN, kol tunelis išjungtas, ką stebi detektorius ir kiek laukia, kurie vardų serveriai ir IPv6 maršrutai juda su keliu, ir kaip grįšite, jei atsarginė kopija taip pat nepavyksta. Jei kuris nors atsakymas yra “kas buvo numatyta”, politika vis dar priklauso maršrutizatoriui, o ne jums.