pfSense OpenVPN: pasiekti tinklą už kito maršrutizatoriaus

Jūsų nešiojamasis kompiuteris pasiekia pfSense LAN per VPN ir vis tiek nepasiekia paslaugos dar dviem šuoliais giliau, o skirtumas yra vienas maršruto sprendimas kiekvienam savininkui. Trys įrenginiai turi sutarti, kol paketas baigs savo kelionę pirmyn ir atgal: klientas, užkarda ir maršrutizatorius, kuris iš tikrųjų valdo paskirties tinklą. Praleiskite bet kurį iš jų ir simptomas atrodo identiškai.

Prieš keisdami taisyklę, sekite vieną paketą per šiuos tris sprendimus, nes kiekvienas savininkas turi skirtingą valdymą ir skirtingą gedimo režimą.

Vienas paketas, trys maršruto sprendimai

Klientas nusprendžia, ar paskirtis priklauso tuneliui, ir gali nuspręsti tik iš to, ką žino: stumiamo maršruto, vietinio maršruto ar numatytojo maršruto, kuris jau apima viską. pfSense nusprendžia, kur paketą siųsti toliau, o tinklui už kito maršrutizatoriaus tai reiškia statinį maršrutą per pasiekiamus vartus teisingoje sąsajoje. Žemiau esantis maršrutizatorius nusprendžia, ar žino kelią atgal į VPN baseiną, o jei nežino, atsakymas išmetamas arba siunčiamas į nenaudingą vietą. Kiekvienas sprendimas nepriklauso nuo kitų dviejų.

Bet kurio iš jų gedimas duoda tą pačią naudotojo ataskaitą. Todėl derinimo tvarka svarbesnė už įrankius.

Duokite klientui prefiksą, o ne spėjimą

pfSense SSL/TLS serveryje, kurio IPv4 tunelio tinklas didesnis nei /30, laukas IPv4 Local network(s) prisijungus paskirsto maršrutus klientams. Pridėkite ten žemesnį prefiksą, o ne pasikliaukite, kad klientas jį sugalvos. Tada po prisijungimo perskaitykite tikrąją kliento lentelę, nes profilis su route-nopull arba maršrutų filtras gali nepaisyti to, ką serveris atsiuntė. Serveris gali būti visiškai teisingas, kai klientas nieko neįdiegia.

Kiti serverio režimai ir topologijos turi skirtingas ribas, o politika pagal klientą arba ryšį gali pakeisti, ką gauna konkretus klientas. Tikrinkite tame kliente, kuris svarbus, o ne tame, kurį atsitiktinai išbandėte pirmą.

Nukreipkite pfSense į vidinį maršrutizatorių

Statiniam maršrutui pfSense reikia apibrėžtų ir pasiekiamų vartų, o tam vartams pasirinkta sąsaja turi būti ta, kuri iš tikrųjų jį pasiekia, kaip aprašo Netgate statinių maršrutų vadovas. Iliustraciniame išdėstyme tranzito jungtis yra 192.168.77.1 užkardoje ir 192.168.77.2 vidiniame maršrutizatoriuje, o paslaugų tinklas yra 172.16.30.0/25 už jo. Tada maršrutas įvardija prefiksą ir kitą šuolį, o ne paslaugos adresą. Naudoti adresą iš tolimo tinklo kaip vartus yra įprastas būdas sukurti maršrutą, kuris atrodo teisingai ir niekur nepersiunčia.

Sąsajai suteiktas pavadinimas neaprašo už jos esančių tinklų. Statinis maršrutas yra tas aprašymas.

Tolimoji pusė turi žinoti baseiną

Žemiau esančiam maršrutizatoriui reikia grąžinimo maršruto į baseiną, šiame pavyzdyje 10.55.0.0/24 per 192.168.77.1, nebent numatytasis maršrutas ar dinaminis protokolas jį jau teikia. Pačios paslaugos hosto vartai turi vesti link to maršrutizatoriaus, o tai paprastai tiesa, kai maršrutizatorius yra jo numatytieji vartai, ir netiesa, kai hostas buvo sukonfigūruotas rankiniu būdu. Politikos pagrindu veikiantis maršrutizavimas užkardoje taip pat gali nepaisyti lentelės konkrečiam srautui, todėl prieš darydami išvadą, kad maršrutas neteisingas, patikrinkite, ar taisyklė nepasirenka kitų vartų.

Šiam sprendimui vertimo nereikia, o matomas kliento šaltinio adresas leidžia žemesniam tinklui taikyti savo politiką.

Priėmimui atsekite vieną naują užklausą per tunelio įėjimą, vidinį užkardos išėjimą ir atsakymą iš paskirties. Jei vietoj to sąmoningai naudojamas vertimas, užrašykite, kokį šaltinį mato žemesnis tinklas ir kaip tikimasi, kad atsakymas grįš.

Išsaugokite trijų savininkų planą šalia leidžiamos programos, kad kitas administratorius galėtų atkurti kelią, o ne atrasti jį iš naujo.