Eitt tæki í gegnum VPN á beini þarf þrjár reglur, ekki rofa

Það er enginn rofi fyrir hvert tæki í VPN á beini; rofinn sem þú ert að leita að er flýtileið sem skrifar reglur um stefnumótandi leiðsögn fyrir þína hönd. Um leið og ein fartölva, eitt portabil, einn vistfangalisti eða einn LAN-hluti þarf að nota göngin á meðan allt annað heldur sig á WAN, ertu að byggja stefnumótandi leið en ekki að virkja eiginleika. Verkið hefur þrjá hreyfanlega hluta og hver þeirra bregst á sinn hátt: merkt tafla án leiðar lítur út eins og þögn, merki sett í rangri keðju lítur út eins og ekkert hafi gerst, og NAT-regla sem vantar lítur út eins og göng sem tengjast og flytja ekkert. Tveir hlutar til viðbótar glatast af því að þeir birtast aldrei í mangle-reglunni, og þeir eru DNS og IPv6.

Goðsögnin: göngin eru stilling í biðlaranum

VPN-biðlari á beini gerir eitt gróft atriði vel: hann setur 0.0.0.0/0 í aðal leiðatöfluna og beinir henni að göngunum. WireGuard leiðir það af AllowedIPs, OpenVPN af redirect-gateway sem er ýtt frá þjóninum, og bæði breyta leiðinni fyrir hvert tæki sem er bak við beinið. Að þrengja AllowedIPs eða bæta við route-nopull breytir því sem biðlarinn setur upp. Það breytir ekki hverjum uppsetningin á við, því biðlarinn sér aldrei tæki. Hann sér bara pakka.

Val eftir uppruna eða áfangastað er leiðarákvörðun, svo það tilheyrir stefnulagi beinisins: mangle-regla auk annarrar töflu á RouterOS, MARK auk ip rule á OpenWrt eða DD-WRT, eða eldveggsregla sem hefur göngin sem gátt á pfSense. Uppskrift Netgate fyrir WireGuard-biðlara er sú sem á að lesa áður en giskað er, því á þeim vettvangi verða gátt reglunnar, úthlutun tengisins og útleiðar-NAT-færslan að stemma áður en einn biðlari notar göngin.

Seinni helmingur goðsagnarinnar er seinni beinirinn. Að kaupa annan kassa, eða færa tækið yfir á gesta-SSID, virkar oft og ástæðan er ekki vélbúnaðurinn: það setur tækið í sitt eigið undirnet, sem gefur þér upprunavalið sem fastbúnaðurinn skilur þegar. Ef þú getur skilgreint þann hluta á beininu sem þú átt, leysir aukakassinn vandamál sem þú hafðir ekki.

Fyrsti hlutinn: göng sem eru ekki sjálfgefin leið

Á RouterOS skaltu bæta biðlaranum við án sjálfgefinna leiðar og gefa göngunum sína eigin töflu. Fyrsta leiðin er merkt sjálfgefin; önnur er bilunarhelmingurinn.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Óaðgengilega leiðin er ástæðan fyrir því að merkt tafla vinnur á undantekningarlista í aðaltöflunni. Þegar göngin falla fá merktir pakkar tafarlaust óaðgengilegt í stað þess að hverfa hljóðlega aftur á WAN, svo bilunin birtist í villuboðum forritsins en ekki á staðsetningarsíðu sem þú skoðar klukkustund síðar.

RouterOS 7 skiptir því sem 6.x hélt saman: þú skilgreinir töfluna með /routing table add name=vpn fib og vísar svo í hana með nafni á leiðinni og í mangle-reglunni. 6.x-bútur sem skrifar routing-mark án þess að skilgreina töfluna hleðst hreint og passar við ekki neitt. Hin klassíska er tvö hálf 0.0.0.0/1, eða tvö sjálfgefin á sama vegalengd í einni töflu: kjarninn velur eitt og hegðunin getur breyst eftir endurræsingu.

Annar hlutinn: merktu áður en leiðin er flett

Valið ræður því hvaða pakkar fara inn í þá töflu. RouterOS byrjar venjulega með vistfangalista fyrir stefnu á áfangastað, eða upprunavistfang fyrir stefnu eftir tæki:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux-fastbúnaður gerir það sama með netfilter-merkingu og reglu sem stýrir merktum pökkum inn í töflu sem þú fylltir:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Keðjan er ekki stílaval. Þegar pakki nær FORWARD hefur leiðarflettingin þegar átt sér stað, svo MARK eða DROP þar getur aðeins endurskrifað eða hent. Merkið verður að lenda í PREROUTING fyrir framsenda umferð og í OUTPUT fyrir umferð sem beinirinn býr til, en þar lifir DNS, NTP og uppfærslupróf beinisins. Sú útleið er venjulega ástæðan fyrir að fullgönguð uppsetning svarar samt frá ISP-þjóninum í lekaprófi.

Stefna eftir tæki þarf samsvörun sem hreyfist ekki. Taktu vistfangið frá í DHCP, eða paraðu tengi við sérhluta; vistfang sem síðar flyst á annað tæki beitir göngunum hljóðlega á rangann biðlara. Brú fyrir hvert SSID með eigið undirnet er endingarbetri útgáfan af sömu hugmynd og gefur IPv6-reglunum líka stað að vera.

Þriðji hlutinn: NAT, DNS og LAN-undantekningin

Umferð sem fer út um göngin þarf upprunavistfang sem hinir endinn svara. Takmarkaðu umbreytinguna við tengi ganganna: out-interface=VPN_NAME á RouterOS, -o tun0 á Linux, samsvarandi útleiðar-NAT-færsla á pfSense. Masquerade-regla án þeirrar takmörkunar endurskrifar umferð sem þú ætlaðir að láta í friði, og einkennið er að tækið sem er ekki í göngunum tapar opinberu vistfangi sínu.

LAN-undantekningin veldur fleiri þráðum í þjónustu en göngin sjálf. Ef merka taflan heldur aðeins sjálfgefinni leið passar prentari eða NAS-áfangastaður frá völdu tækinu við þá sjálfgefnu og hverfur inn í göngin. Bættu LAN-leiðinni í sömu töflu, eða útilokaðu staðarnetið í valinu; bæði virka og undantekningin er auðveldari að halda réttri þegar þú bætir VLANs síðar.

DNS fer aðra leið. Fyrirspurnir sem beinirinn framsendir eru frá beininum og fylgja OUTPUT, ekki framsenda merkinu, svo fullgönguð fartölva getur samt leyst nöfn í gegnum ISP. Beindu biðlurum að þjóni sem er aðgengilegur um göngin, eða merktu port-53 umferð beinisins sjálfs og athugaðu svo leysta vistfangið í stað þess að gera ráð fyrir að svarið hafi ferðast með vefbeiðninni.

Þegar reglan passar en forritið notar samt WAN

Áfangastalistar eldast illa. Nafn leysist í vistfang sem er ekki á listanum, svo beiðnin fer á WAN á meðan hvert próf sem þú gerðir á skráða vistfanginu virkaði. Endurnýjaðu listann frá sama þjóni og biðlarinn notar, og veldu upprunamiðað val þegar þú vilt í raun alla umferð frá einu tæki.

IPv6 er hljóða leiðin fram hjá. Tækið hefur aðra vistfangafjölskyldu með sinni eigin sjálfgefnu leið og sínum eigin reglum, og að passa aðeins við IPv4-vistfangið er hálf stefna. Beittu sama valinu á ip6tables eða nftables-ígildið, eða slökktu á IPv6 á þeim hluta viljandi í stað þess að gera það fyrir slysni.

Stofnuð tenging skiptir líka máli. Conntrack-færsla sem var búin til fyrir breytinguna heldur áfram að fylgja gömlu leiðinni þar til hún rennur út, svo vafri sem var opinn meðan á breytingunni stóð lítur nákvæmlega út eins og regla sem var aldrei beitt. Opnaðu nýja tengingu, eða hreinsaðu stöðuna, áður en þú dæmir stefnuna.

Staðfestu með tveimur tækjum og endurræsingu

Prófaðu tækið sem á að vera í göngunum og tækið sem á ekki að vera það, og berðu saman annan hoppið í stað hraðatölu. Traceroute frá hvoru sýnir annaðhvort gátt ganganna eða gátt ISP á öðrum hopp; ef bæði líta eins út er merkið eða taflan ekki að gera það sem reglan segir. Notaðu nýjar tengingar fyrir prófið.

Endurræstu svo. Ræsiröðin er þar sem virk stefna verður brotin, því biðlarinn verður að vera í gangi áður en óaðgengilega leiðin er sett upp, og vistað skyndiafrit sem endurheimtir gamla reglusettið mun yfirskrifa töfluna þína. Athugaðu að hver regla sé í vistaðri stillingu og að merkt sjálfgefin sé til staðar eftir ræsingu, ekki bara eftir að þú skrifaðir hana.

Ef eitthvað bregst skaltu fjarlægja merkið fyrst og sjá hvort venjuleg umferð kemur til baka, svo töfluna. Sú röð segir þér hvort þú eltir leiðarvandamál eða eldveggsvandamál, og hún skilur heimilið eftir með vinnandi prentara á meðan þú klárar verkið.