Segment ng bahay na VPN-only: patayin ang fallback, hindi lang ang SSID
Ang guest SSID sa VPN ay hindi nagiging VPN-only. Magpasya kung ano ang mangyayari kapag bumagsak ang tunnel, sakupin ang IPv6, at subukan ang outage bago ka magtiwala sa label.
Inilalagay mo ang guest SSID sa VPN at tinatawag ang segment na VPN-only. Pagkatapos bumagsak ang tunnel nang dalawang minuto at tahimik na bumabalik ang mga device sa ordinaryong WAN. Walang anuman sa pangalan ng SSID ang pumigil doon. Ang isang VPN-only na segment ay tinutukoy ng kung ano ang nangyayari kapag hindi available ang tunnel, hindi ng label ng network.
Ang label ay isang pangako; ang fallback policy ang pagpapatupad.
Mito: ang SSID ang hangganan
Ang SSID na walang sariling forwarding policy ay pangalan lamang. Ang hangganan ay hiwalay na interface, VLAN o subnet, na may sariling DHCP scope at sariling mga patakaran. Ang VLAN ay nagbibigay sa iyo ng forwarding na hangganan na hindi kayang ibigay ng pangalan ng Wi-Fi.
Bahagi rin ng disenyo ang client isolation. Maaaring kailangan ng dalawang device sa segment na mag-usap, o hindi, at ang pagpiling iyon ay dapat tahasan sa halip na minana mula sa guest profile.
Isulat ang interface at address range ng segment bago ka sumulat ng kahit isang patakaran. Ang linyang iyon ay pumipigil sa karamihan ng kalituhan sa hinaharap.
Mito: ang ruta ng tunnel ay sumasaklaw sa bawat protocol
Ilapat ang policy ng firmware sa segment na iyon upang ang trapiko nito patungong internet ay gumamit ng tunnel. I-configure ang remote forwarding at translation na kailangan ng tunnel. Panatilihin lamang ang access sa mga lokal na resource na talagang kailangan ng segment.
Suriin ang dalawang pamilya ng address. Kung ang IPv6 ay hindi dinadala sa tunnel, dapat itong hawakan ng policy, kung hindi ay makakahanap ang isang device na may suporta sa IPv6 ng direktang ruta na hindi mo sinasadya.
Ang kill switch na IPv4 lamang habang naka-enable ang IPv6 ay karaniwang paraan ng pagtagas. Subukan gamit ang client na may suporta sa IPv6, hindi lamang sa laptop na nasa kamay mo.
Mito: ang DNS at ang endpoint ng tunnel ay sumusunod sa tunnel
Ang DNS ng router ay maaaring mabuo nang lokal at sumunod sa sariling routing table ng router, hindi sa policy ng segment. Magpasya kung aling landas ang dapat gamitin ng resolver na iyon at ano ang gagawin nito kapag nabigo ang tunnel. Ang koneksyon ng sariling endpoint ng VPN ay isa pang pagbubukod: kailangan nito ang dokumentadong panlabas na ruta patungo sa peer. Ipadala ang koneksyong iyon sa tunnel at hindi ito makakabangon.
Panatilihing hiwalay ang administrasyon ng pagbawi sa internet access ng segment. Kung iki-lock ka rin ng isang nabigong peer sa labas ng router, ginawa mong pagbisita sa site ang isang outage ng tunnel. Panatilihin ang access na iyon sa management network, hindi sa VPN-only na segment.
Ano ang talagang gumagawa ritong VPN-only
I-block ang ordinaryong WAN forwarding para sa segment tuwing bumaba ang tunnel. Ang patakarang iyon, hindi ang SSID, ang gumagawa sa label na totoo. Subukan ito gamit ang hindi nakakapinsalang trapiko mula sa device sa segment.
Gumawa ng tatlong pagsusuri: normal na operasyon sa tunnel, ang pinapayagang pagsubok ng pagkabigo habang bumaba ang tunnel, at ang pagbawi kapag bumalik ito. Kumpirmahin na ang isa pang segment ng sambahayan ay pinapanatili ang sariling nilalayong ruta sa buong panahon. Idokumento ang anumang direktang pagbubukod, kung hindi ay itatago ng label ang mga landas na hindi mo na maaalala.
Ang maikling tala ng segment, ng piniling tunnel at ng mga pagbubukod ay nagbibigay sa iyo ng tiyak na mga pagsusuri pagkatapos baguhin ng firmware update ang pagkakasunod-sunod ng mga patakaran o ang pag-uugali ng resolver. Ang recipe ng client na WireGuard para sa pfSense ay kapaki-pakinabang na sanggunian para sa panig ng tunnel, hindi kapalit ng policy ng segment.