LAN-klientoj ignoras la VPN de la enkursigilo ĝis politika enkursigado ekfunkcias

La enkursigilo atingas la interreton tra sia tunelo, dum tekokomputilo malantaŭe ankoraŭ raportas la adreson de la ISP. Aldoni akceptajn regulojn ne helpas, kaj tiu malsukceso estas instrua: filtrado respondas ĉu pakaĵo rajtas pasi, ne kien ĝi iras. La interfac-elektron jam faris enkursiga serĉo, kiu scias nenion pri via klienta listo. Riparu la serĉon, kaj la fajroŝirmilo ĉesas esti la suspektato.

Filtra regulo ne povas elekti interfacon

Pakaĵfluo sur Linuksa enkursigilo unue plenumas la enkursigan decidon kaj poste la antaŭenigan hokon. Kiam regulo kongruas kun la elira tunela aparato, la kerno jam decidis, ke la tunelo estas la eliro. Se la ĉefa tabelo ankoraŭ preferas la implican itineron tra WAN, la pakaĵo survojas al la ISP kaj la akcepta regulo, kiun vi ĵus skribis, neniam vidas ĝin. Tiu unuorda fakto klarigas, kial paĝo da novaj fajroŝirmilaj reguloj ŝanĝas nenion.

La suba ekzemplo uzas LAN-on 192.168.8.0/24 sur br-lan, tunelan aparaton tun0, kaj unu set-top-skatolon ĉe 192.168.8.23, kiu devus uzi la tunelon.

Legu la serĉon antaŭ ol redakti regulojn

Petu la kernon solvi itineron nome de tiu kliento. La respondo enhavas la eliran aparaton kaj la fontan adreson, kiun oni elektus, kaj tio estas ĉio, kion vi bezonas por konfirmi la diagnozon. Se la respondo nomas la WAN-aparaton, la pakaĵo neniam havis ŝancon atingi vian regulon.

ip -4 route get 198.51.100.7 from 192.168.8.23

Ripetu la mendon por kliento, kiu devus resti sur la ordinara vojo. Kiam ambaŭ respondoj nomas la saman aparaton, neniu politiko laŭ fonto ankoraŭ funkcias, kaj la korekto apartenas al enkursigado, ne al filtrado.

Ligu tabelon al la klientoj, kiujn vi volas kovri

Politika enkursigado enmetas regulan serĉon antaŭ la ĉefa tabelo. Konstruu tabelon, kies implicita itinero estas la tunelo, poste ligu tiun tabelon al selektilo: eniga interfaco, fonta adreso aŭ fajroŝirmila marko. Prioritatoj decidas la ordon, kaj la ĉefa tabelo sidas tre malalte en la listo ĉe 32766, do regulo kun malalta numero estas konsultata unue. Interfacaj selektiloj kovras ĉiun klienton sur la ponto; adresaj selektiloj kovras unu maŝinon.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Firmware-interfacoj kutime montras la samajn objektojn kiel paĝo pri politika enkursigado aŭ VPN-politiko. Aparata listo tie estas pli facile prizorgata ol mane skribitaj reguloj kaj kutime postvivas ĝisdatigojn, kiuj ŝanĝas la regulan sintakson.

Elektu la selektilon intence. Interfaca regulo estas mallonga kaj estontecerta, sed ĝi ankaŭ kaptas la administran trafikon de la enkursigilo mem, kiu alvenas sur tiu ponto. Fonta regulo estas preciza kaj bezonas redakton ĉiam, kiam la aparata listo ŝanĝiĝas. Skribu la elekton, ĉar la sekva persono, kiu demandos, kial unu aparato kondutas alie, bezonos ĝin.

Tenu lokajn celojn ekster la tunelo

Nova tabelo konas nur la itinerojn, kiujn vi metas en ĝin. La LAN-prefikso mankas, do trafiko de printilo kaj NAS sekvus la implican tunelan itineron kaj malaperus. Itinero throw finas la serĉon en ĉi tiu tabelo kaj redonas la decidon al la ĉefa tabelo.

ip -4 route add throw 192.168.8.0/24 table 200

Se vi preterlasas tiun itineron, lokaj kunhavoj rompiĝas, kaj la administra sesio de la enkursigilo mem povas malaperi, se la selektilo estas pli larĝa ol celite. Poste solvu la fontan demandon: tunelaj pakaĵoj, kiuj ankoraŭ portas LAN-adresojn, bezonas, ke la fora flanko konu revenan vojon, dum maskado sur la tunelo forigas tiun postulon kaj ankaŭ forigas la klientan identecon, kiun la fora flanko vidus.

Reguloj kaj itineroj aldonitaj dum funkciado malaperas post restarto aŭ firmvara ĝisdatigo. Aldonu ilin al la pravigilo de la enkursigilo, restartu unufoje, kaj retestu el la kliento: ĝian publikan adreson, duan klienton, kiu devus resti sur WAN, kaj la tunelajn nombrilojn dum nova konekto.