Gasta Wi-Fi daŭre uzas la ĉefan vojon: donu al ĝi propran eliron

Vi kreis gastan reton, aldonis itineron por ĝi, kaj la gastoj ankoraŭ eliras tra via normala interreta konekto. La tunelo funkcias, la ĉefa LAN funkcias, kaj la gastaj aparatoj raportas adreson en la intervalo, kiun vi asignis, do nenio aspektas difektita. Kio kutime mankas, estas ne itinero sed selektilo: la enkursigilo decidas la vojon antaŭ ol konsideri, sur kiu interfaco la paketo alvenis, kaj se io ne eksplicite kongruas kun la gasta trafiko, tiu trafiko heredas la defaŭlton. La solvo estas segmento, politika regulo kaj responda vojo, en tiu ordo.

La simptomo: gastoj ankoraŭ eliras tra la WAN

La indiko estas la elira adreso. Gasta aparato, kiu atingas la interreton tra la tunelo, raportos la adreson de la tunela provizanto, dum unu, kiu heredis la defaŭlton, raportos vian normalan konekton. Komparu gastan aparaton kaj aparaton de la ĉefa LAN unu apud la alia, ĉar la interesa kazo estas, kiam ili diferencas de tio, kion vi agordis kaj kongruas unu kun la alia.

La dua indiko estas la manko de ajna trafiko sur la tunela interfaco dum gastoj retumas. Se la nombriloj ne moviĝas, la politiko neniam estis aplikita, kaj ĝustigi la tunelon mem ne povas helpi.

Paŝo 1: reala segmento, ne nur nomo

SSID-nomo ne kreas izoladon. Kontrolu, ke la gasta reto finiĝas sur sia propra interfaco, VLAN aŭ ponto, kaj ke la adresaro diferencas de la fidata LAN. Sur multaj konsumantaj alirpunktoj, la gasta SSID estas pontita en la saman segmenton kiel ĉio alia, kio malebligas la reston de ĉi tiu laboro ĝis tio korektiĝos.

Poste konfirmu la gastan intervalon kaj ĝian DHCP-servilon, kaj tenu la solvajn agordojn ligitaj al tiu segmento anstataŭ al la tuta enkursigilo. Gasta subreto, kiu ekzistas nur kiel komento en fajroŝirma regulo, ne estas segmento, kaj la enkursigilo havos neniun interfacon por kongruigi.

Ne pontu gastojn en la ĉefan LAN por faciligi la agordon de la VPN. Tio interŝanĝas la izoladon, kiun vi volis, kontraŭ vojiga fuĝo, kaj ĝi estas la kutima kialo, kial gasta reto finiĝas kun aliro al la presilo kaj la NAS.

Paŝo 2: elektu la tunelon laŭ fonto

Vojigaj tabeloj estas elektitaj laŭ celo, do regulo, kiu diras «sendu 0.0.0.0/0 al la tunelo», validas por ĉiuj. Politika vojigo aldonas duan dimension: elektu la tabelon laŭ fonta adreso. Sur Linux-bazita enkursigilo, tio estas plia regulo plus dediĉita tabelo, kaj la ordo gravas ĉar la unua kongrua regulo venkas:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Tiu lasta komando respondas la demandon rekte: kiun interfacon ĉi tiu fonto uzos por ĉi tiu celo. Rulu ĝin antaŭ kaj post la ŝanĝo kaj vi scios, ĉu la politiko efikis sen tuŝi retumilon.

Plej multaj enkursigilaj firmvaroj esprimas la saman aferon kiel interfacan regulon aŭ fontan pordegan elekton. Kiun ajn sintakson via platformo uzas, la principo estas identa: kongruu la eniran interfacon aŭ fontan prefikson, poste anstataŭigu la itineron nur por tiu kongruo. Regulo kongruigita laŭ celo ne povas distingi gaston de hejma aparato.

Paŝo 3: la responda vojo kaj tradukado

Paketo, kiu eliras tra la tunelo, devas reveni. Aŭ la tunela samtavolano konas vojon reen al la gasta prefikso, aŭ la enkursigilo tradukas la gastan fonton en la tunelan adreson. Elektu unu kaj skribu ĝin, ĉar la malsukcesaj reĝimoj aspektas malsame: mankanta revena itinero donas konekton, kiu establiĝas kaj neniam respondas, dum mankanta tradukado ofte produktas nenion entute.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Se vi elektas tradukadon, memoru, ke la samtavolano nun vidas unu adreson por ĉiu gasto, do ajna politiko laŭ kliento ĉe la fora fino malaperas. Se vi anstataŭe konservas adresojn, ambaŭ finoj bezonas la gastan prefikson en sia vojigado kaj politiko, kio estas pli da laboro kaj pli antaŭvidebla.

IPv6 bezonas sian propran regulon. Politiko skribita por IPv4 ne kovras la alian familion, kaj gasta aparato kun funkcianta IPv6 ĝoje uzos ĝin dum via zorge vojigita IPv4-vojo sidas senokupa. Aŭ vojigu ambaŭ familiojn aŭ malŝaltu IPv6 sur la gasta segmento, sed ne supozu, ke la kombinita regulo, kiun vi skribis, kovras tion, kion la aparato efektive faras. Testu per kliento, kiu havas ambaŭ familiojn ebligitaj, ĉar tio estas la kazo, kiun la dezajno devas postvivi. Tekkomputilo, kiu preferas IPv6, aspektas ĝuste en nur-IPv4-testo kaj likas en la reala.

Testu izoladon, ne nur retumadon

Retumado pruvas, ke la eliro ŝanĝiĝis. Ĝi ne pruvas, ke la segmento estas izolita, kaj izolado estas la kialo, kial la gasta reto ekzistas. De gasta aparato, provu atingi la administran interfacon de la enkursigilo, fidatan LAN-gastiganton kaj servon, kiu devus esti malakceptita; ĉiuj tri devus malsukcesi, kaj la malsukceso devus esti politika decido anstataŭ tempolimo, kiun neniu povas klarigi.

Poste testu ĉef-LAN-aparaton kaj konfirmu, ke ĝia eliro ne ŝanĝiĝis. Tio estas la regreso, kiun ĉi tiu dezajno plej ofte kaŭzas: larĝa regulo destinita al gastoj, aplikita al ĉiu interfaco ĉar la kongruo estis skribita laŭ la celo.

Fine, decidu, kio okazas kiam la tunelo malsupreniĝas. Gastoj aŭ ricevas neniun interreton aŭ falas al vojo, kiun vi aprobas, kaj lasi tion nedecidita signifas silentan retroiron al la normala konekto, kio estas ĝuste la liko, kiun la gasta politiko celis malhelpi. La recepto por vojigado de interreta trafiko trapasas la saman vojoelektadon por pfSense-bazita enkursigilo.

Enkursigila DNS estas la kazo, kiu surprizas homojn laste. Se gastoj uzas la enkursigilon kiel sian solvilon, la propraj demandoj de la enkursigilo sekvas la itineron de la enkursigilo anstataŭ la gastan regulon, do serĉoj povas eliri tra la normala konekto dum la aplikaĵa trafiko ne. Tenu la segmenton, la solvilon kaj la malsukcesan politikon en unu noto, kaj la sekva persono povos kontroli ĉiujn tri sen rederivi la dezajnon.