pfSense OpenVPN: doseganje omrežja za drugim usmerjevalnikom

Vaš prenosnik doseže LAN pfSense prek VPN in vseeno ne doseže storitve dva skoka globlje, razlika pa je ena odločitev o usmerjanju na lastnika. Tri naprave se morajo uskladiti, preden paket zaključi pot tja in nazaj: odjemalec, požarni zid in usmerjevalnik, ki resnično ima ciljno omrežje. Če zgrešite katero koli od njih, je simptom videti enak.

Preden spremenite pravilo, sledite enemu paketu skozi te tri odločitve, ker ima vsak lastnik drugačen nadzor in drugačen način odpovedi.

En paket, tri odločitve o usmerjanju

Odjemalec odloči, ali cilj spada v tunel, in se lahko odloči le na podlagi tega, kar ve: potisnjena pot, lokalna pot ali privzeta pot, ki že pokriva vse. pfSense odloči, kam poslati paket naprej, kar za omrežje za drugim usmerjevalnikom pomeni statično pot skozi dosegljiv prehod na pravilnem vmesniku. Spodnji usmerjevalnik odloči, ali pozna pot nazaj v bazen VPN, in če je ne pozna, se odgovor zavrže ali pošlje na neuporabno mesto. Vsaka odločitev je neodvisna od drugih dveh.

Odpoved katere koli od njih da isto poročilo uporabnika. Zato je vrstni red odpravljanja napak pomembnejši od orodij.

Odjemalcu dajte predpono, ne ugibanja

Na strežniku pfSense SSL/TLS z omrežjem tunela IPv4, večjim od /30, polje IPv4 Local network(s) ob povezavi razdeljuje poti odjemalcem. Tam dodajte spodnjo predpono, namesto da bi se zanašali, da si jo bo odjemalec izmislil. Nato po povezavi preberite dejansko tabelo odjemalca, ker lahko profil z route-nopull ali filter poti prezre, kar je poslal strežnik. Strežnik je lahko povsem pravilen, medtem ko odjemalec ne namesti ničesar.

Drugi načini strežnika in topologije imajo drugačne omejitve, politika za posameznega odjemalca ali povezavo pa lahko spremeni, kaj prejme določen odjemalec. Preverite na odjemalcu, ki je pomemben, ne na tistem, ki ste ga slučajno preizkusili prvega.

Usmerite pfSense na notranji usmerjevalnik

Statična pot v pfSense potrebuje določen in dosegljiv prehod, vmesnik, izbran za ta prehod, pa mora biti tisti, ki do njega resnično pride, kot opisuje Netgateov vodnik po statičnih poteh. V ilustrativni postavitvi je tranzitna povezava 192.168.77.1 na požarnem zidu in 192.168.77.2 na notranjem usmerjevalniku, storitveno omrežje pa je 172.16.30.0/25 za njim. Pot nato imenuje predpono in naslednji skok, ne naslova storitve. Uporaba naslova iz oddaljenega omrežja kot prehoda je pogost način za izgradnjo poti, ki je videti pravilna in nikamor ne posreduje.

Dajanje imena vmesniku ne opisuje omrežij za njim. Statična pot je ta opis.

Oddaljena stran mora poznati bazen

Spodnji usmerjevalnik potrebuje povratno pot za bazen, v tem primeru 10.55.0.0/24 prek 192.168.77.1, razen če jo privzeta pot ali dinamični protokol že zagotavlja. Prehod samega gostitelja storitve mora voditi proti temu usmerjevalniku, kar običajno velja, ko je usmerjevalnik njegov privzeti prehod, in ne velja, ko je bil gostitelj nastavljen ročno. Usmerjanje po pravilniku na požarnem zidu lahko tudi preseže tabelo za določen promet, zato preverite, ali pravilo izbere drug prehod, preden sklepate, da je pot napačna.

Ta zasnova ne potrebuje prevajanja, ohranjanje vidnega izvornega naslova odjemalca pa omogoča spodnjemu omrežju, da uporabi svojo politiko.

Za sprejem sledite eni novi zahtevi skozi vhod v tunel, notranji izhod požarnega zidu in odgovor s cilja. Če se namesto tega namerno uporablja prevajanje, zabeležite, kateri vir vidi spodnje omrežje in kako naj bi se odgovor vrnil.

Shranite načrt treh lastnikov ob dovoljeni aplikaciji, da bo naslednji skrbnik lahko obnovil pot, namesto da bi jo znova odkrival.