pfSense kaip VPN serveris ir klientas: du keliai, vienas maršrutizatorius

Vienas įrenginys gali vienu metu žiūrėti dviem kryptimis: klajojantys naudotojai jungiasi į vidų, o ta pati dėžė jungiasi į išorę prie išėjimo teikėjo, kad pasirinktas srautas išeitų per kitą tinklą. Įjungti abi tarnybas užtrunka minutes; kad jos sugyventų, reikia projekto, nes antrasis vaidmuo perrašo maršrutų lentelę, kuria remiasi pirmasis. Trys sąlygos lemia, ar ši sandara veikia, būtent ar įeinančioji tarnyba išlaiko savo grįžimo kelią, ar išeinantis tunelis dar pasiekia savo partnerį ir ar srautas, kurį ketinote persiųsti, parenkamas išėjimui. Suklyskite vienoje ir gausite du tunelius, kurie abu praneša apie ryšį, o tarp jų nieko naudingo nepereina. Toliau pateiktos patikros nustato kiekvieną sąlygą ta tvarka, kuria gedimai paprastai pasirodo.

Įvardykite du vaidmenis prieš liesdami bet kokį nustatymą

Užsirašykite keturis faktus apie kiekvieną egzempliorių: jo tolimąjį partnerį, autentifikavimo medžiagą, platinamą adresų telkinį ir už jo esančius tinklus. Du egzemplioriai yra atskiri objektai įrenginyje ir turėtų likti atskiri jūsų užrašuose. Beveik kiekvienas vėliau klaidinantis simptomas kyla iš jų reikšmių sumaišymo, o du egzemplioriai, besidalijantys vienu užrašų rinkiniu, yra kelias, kuriuo neteisingas telkinys atsiduria neteisingame lauke.

Įeinančiajai tarnybai reikia tunelio tinklo, kuris nesutaptų nei su išeinančio tunelio adresais, nei su jokiu privačiu tinklu, kurį įrenginys maršrutizuoja. Sutapimas yra vienintelė klaida, kuri vienu metu sukelia simptomus abiejuose vaidmenyse, ir ją sugauti popieriuje daug pigiau. Prieš konfigūruodami bet kurią tarnybą, vienoje vietoje palyginkite abu telkinius ir kiekvieną maršrutizuojamą privatų tinklą.

Bendra aparatinė įranga nereiškia bendrų prisijungimo duomenų, o kliento sertifikatas iš nuotolinės prieigos telkinio neturėtų būti naudojamas prieš išėjimo teikėją. Atskira medžiaga taip pat paverčia atšaukimą vietiniu sprendimu, o ne viso parko įvykiu.

Laikykite serverio atsakymus WAN kelyje

Atsakymai, kuriuos įrenginys generuoja pats, yra pirmoji neapdairaus numatytojo maršruto auka. Kai atvyksta klajojančio naudotojo inkapsuliuotas paketas, atsakymas yra vietoje atsiradęs srautas ir turi išeiti per sąsają, kuria tas naudotojas atėjo. Jei išeinantis klientas įdiegė numatytąjį maršrutą, kuris jį pagauna, atsakymas patenka į neteisingą tunelį, o sesija sustoja, kol tarnyba vis dar atrodo sveika.

Nėra vieno žymės langelio, kuris tai išspręstų, nes sprendimas yra apie tai, kokį srautą išeinantis klientas gali pagauti. Arba netraukite jokių maršrutų ir nukreipkite tik tai, ką pasirenkate, arba traukite maršrutus ir pridėkite išimtis, kurios palaiko pačios įrenginio tarnybas. Užsirašykite pasirinkimą šalia egzemplioriaus, kitaip kitas žmogus ims manyti priešingai.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Maršrutų lentelę skaitykite pagal ilgiausią atitikimą, o ne pagal tvarką, kuria ką nors konfigūravote. Klausimas, kuris įrašas laimi išėjimo partnerio adresui ir kuris įrašas laimi įeinančiosios tarnybos atsakymui, ir šie du atsakymai gali skirtis.

Neleiskite išeinančiam tuneliui suvalgyti savo paties galinio taško

Išeinantis klientas turi pasiekti savo partnerio viešąjį adresą, kad apskritai sukurtų tunelį. Jei tas adresas pats maršrutizuojamas į tunelį, klientas vejasi savo paties uodegą: transportas niekada nepakyla, arba pakyla ir nukrenta tą akimirką, kai įdiegiamas maršrutas. Žurnalas atrodo kaip autentifikavimo laiko pabaiga, o ne maršrutizavimo gedimas, todėl maršrutas nusipelno pirmosios patikros.

Patikrinkite maršrutą prieš prisijungimo duomenis ir dar kartą, kai tunelis jau pakilęs, nes įrašas gali būti teisingas paleidimo metu ir neteisingas po minutės. Partnerio adresas turi rodyti įprastą WAN kelią, niekada į tunelio įrenginį. Kai transportas stabilizuojasi, įdomus klausimas persikelia į persiųstą srautą, ir tai yra kitas sprendimas.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Pasirinkite, kurie naudotojai gauna išėjimą

Šaltinio politika priklauso įėjimui, kuriame srautas patenka į įrenginį, todėl pasirinkite nuotolinės prieigos telkinį arba siauresnes tapatybes jame. Išsaugokite privačias paskirties vietas ir valdymo išimtis, kurių niekada negalima siųsti į išėjimą, ir tas taisykles padėkite prieš plačiąją. Tada išėjimo keliui reikia savo vertimo arba maršrutizuotos grąžinimo tvarkos, o daugumoje projektų tai reiškia išeinantį NAT išėjimo sąsajoje, apimantį telkinį. Vertimas nepasirenka išėjimo; jis tik perrašo tai, kas jau išėjo, todėl NAT taisyklė nesusijusiame WAN nieko nekeičia pasirinkime.

Patvirtinkite, kad tolimasis galas leidžia persiųstą srautą iš šios sandaros, nes vieni teikėjai leidžia, kiti ne. Skirtumas matomas kaip tunelis, kuris prisijungia ir nieko neneša, o tai lengva perskaityti kaip vietinį gedimą. Išbandykite tris srautus atskirai, nes jie nepavyksta nepriklausomai, o du iš trijų yra pusiau pastatytas projektas.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Pirmoji komanda yra klajojančio naudotojo išorinis ryšys, ir ji veikia, kai klientas praneša, kad inicijavimo seka baigta. Antroji, paleista iš to prisijungusio nešiojamojo kompiuterio, turėtų pranešti išėjimo teikėjo adresą, o ne jūsų WAN adresą. Trečioji vykdoma įrenginyje, susieta su telkinio adresu, ir tikrina šaltinio politiką persiųstam srautui visiškai neįtraukdama nuotolinio naudotojo. Jei ji atsako iš WAN, politika nesutapo, ir joks NAT redagavimas neištaiso pasirinkimo problemos.

Nuspręskite, kas nutinka, kai išėjimas sugenda

Užrašykite gedimo elgseną prieš jam įvykstant: kai išeinantis tunelis krinta, ar naudotojai grįžta prie įprasto WAN, ar būna užblokuoti, kol išėjimas grįš? Abu atsakymai yra apginami, ir įrenginys nepasirinks už jus. Pašalintas maršrutas arba politika, nurodanti į negyvus vartus, automatiškai nesukuria visiško blokavimo rezultato. Jei norite blokavimo, politika turi tai pasakyti aiškiai, ir tai reikia išbandyti atimant išėjimą, o ne apie tai mąstant. Jei norite grįžimo, paskelbkite tai naudotojams, nes srautas, tyliai pasirenkantis įprastą kelią, yra būtent tas srautas, kurį kas nors manė esant uždengtą.

Išjunkite kliento egzempliorių, pažiūrėkite, ką prisijungęs naudotojas dar pasiekia, tada vėl jį paleiskite. Užklausa, kurios laikas baigiasi, yra visiško blokavimo rezultatas, kurio prašėte; ta, kuri atsako WAN adresu, yra grįžimas, kurio nedokumentavote. Pakartokite patikrą IPv6 ir DNS atveju, nes politika, parašyta IPv4, nieko nesako apie AAAA srautą, o resolveris, kurį stumia bet kuris tunelis, atsako iš ten, kur užklausa iš tikrųjų išeina.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

„Netgate“ maršrutizuoto OpenVPN receptas parodo, kaip šaltinio politika, sąsajos priskyrimas ir išeinantis vertimas dera kartu, o jo apimtis tarp vietų yra dalis, kurios nereikia kopijuoti visos. Ko jis nepasakys, tai kurią iš trijų aukščiau esančių sąlygų jūsų projektas jau sulaužė.