Hvernig á að senda aðeins eitt einkaneð í gegnum VPN

Eitt einkaneð í gegnum gönguna og allt annað eftir venjulegri leið þinni er lítil beiðni með marga vegu til að fara úrskeiðis. Útkoman ræðst ekki af gátreitnum merktum split tunneling heldur hvar ákvörðunin er framfylgt: í eigin leiðatöflu biðlarans, í leið sem netþjónninn ýtir eða í stefnu sem endarnir tveir semja um. Veldu ranga lagið og þú færð annaðhvort fulla göngu sem þú vildir aldrei eða leið inn í göngu sem hin hliðin neitar að samþykkja. Ég nota próf með þremur skilyrðum áður en ég opna hvaða stillingar sem er og vel svo eina af aðferðunum hér fyrir neðan.

Þrjú skilyrði sem ráða hönnuninni

Í fyrsta lagi þarftu nákvæma forskeytið og grímuna frá eiganda netsins. Netið 10.x er ekki forskeyti; 10.20.0.0/16 er það. Staðfestu að það skarist ekki við heimanetið þitt, Docker-brú eða annað VPN sem þú keyrir, því skörun gerir leiðina tvíræða og kjarninn velur færsluna sem þú ætlaðir ekki.

Í öðru lagi, hver svarar afturfarartrafiknum. Að beina pakka inn í gönguna kemur honum bara til VPN-netþjónsins. Ef neðri netið er bak við annan beini sem hefur enga leið til baka í biðlarasafnið þitt verður netþjónninn að dulbúa trafikið, eða sá beinir verður að læra safnið þitt. Engin leið á biðlarahlið bætir upp vantaða afturleið.

Í þriðja lagi, framfylgdarpunkturinn. Sumir biðlarar setja upp leið og stýrikerfið gerir restina. Aðrir semja um stefnu, og stefna sem gáttin samþykkir ekki framleiðir enga göngu: pökkum er hent án sýnilegrar villu. Finndu út hvorum tveggja þú átt áður en þú skrifar nokkuð.

WireGuard: AllowedIPs er leiðataflan

Á biðlaranum telur AllowedIPs upp áfangastaðina sem mega fara inn í gönguna, og wg-quick breytir hverri færslu í venjulega leið. Biðlarahluti þessa verks er því ein lína.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Berðu nú saman færslu netþjónsins fyrir sama biðlara. Hún lýsir því sem netþjónninn sendir biðlaranum, sem er venjulega gönguheimilisfang biðlarans, ekki hið einkaaða neðra net.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Að skipta þessum tveimur er algengasta mistökin sem ég sé. Að setja 10.20.0.0/16 undir peer-kafla netþjónsins fullyrðir að allt neðra netið sé bak við þann biðlara, og það er krafa staðar-til-staðar, ekki leyfi. Pakkar sem passa ekki við AllowedIPs neins peer eru látnir falla hljóðlega, svo röng færsla lítur nákvæmlega út eins og eldveggsvandamál.

Ef þú stjórnar leiðunum sjálfur skaltu setja Table = off undir [Interface] og bæta við leiðinni sem þú vilt. Þá er engu bætt við sjálfkrafa, svo leiðin tilheyrir því sem ræsir viðmótið.

OpenVPN: ýttu leiðinni og tryggðu svo að hún lendi

Á venjulegum netþjóni er breytingin ein tilskipun í stillingum netþjónsins, við hlið biðlarasafnsins.

push "route 10.20.0.0 255.255.0.0"

Biðlarinn bætir henni við þegar hann tengist. Bilunarhamurinn kemur fram þegar sama sniðið ýtir líka redirect-gateway, eða þegar einhver hefur þegar bætt við route-nopull: hið fyrra gerir lotuna að fullri göngu og hið síðara hendir hverri ýttri leið, þar á meðal þinni.

Biðlari sem þarf þrönga hegðun gagnvart netþjóni með fullri göngu ætti aðeins að hunsa hlutana sem hann vill ekki. Í OpenVPN 2.4 og nýrri er pull-filter til einmitt fyrir það.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Haltu heimilisfangaættum aðskildum: ýtt IPv4-leið gerir ekkert fyrir innri þjónustu sem leysist í IPv6, og sú þjónusta bregst í gegnum gönguna á meðan allt annað virðist í lagi.

Þegar hið einkaaða neðra net er ekki á VPN-netþjóninum heldur bak við annan biðlara verður að láta netþjóninn vita. Bættu við skrá fyrir hvern biðlara í gegnum client-config-dir sem inniheldur iroute 10.20.0.0 255.255.0.0, auk samsvarandi route svo aðrir biðlarar læri leiðina. Án iroute hefur netþjónninn enga ástæðu til að senda það forskeyti niður þá tilteknu göngu.

IPsec: umferðarvalararnir verða að vera sammála

Með IPsec er engin leið til að ýta. Endarnir tveir semja um hvaða heimilisföng eru inni í göngunni, og umferð utan samþykktu valaranna er hvorki dulkóðuð né send í gegnum hana. Á strongSwan-biðlara eru valararnir skýrir.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ef gáttin er stillt með 0.0.0.0/0 á báðum hliðum dregur IKEv2-þrenging venjulega barn-SA niður í skurðpunkt tillagnanna tveggja, sem er æskileg útkoma. Sumar gáttir hafna hins vegar tillögu sem passar ekki við stilltu valarana þeirra, og annálin sýnir þá misheppnað barn-SA frekar en kvörtun um leiðsögn. Þegar það gerist tilheyrir breytingin gáttinni, því leið á biðlara getur ekki búið til göngu fyrir valara sem hin hliðin mun ekki samþykkja.

Á Windows felur innbyggði biðlarinn sömu ákvörðun bak við tvær stillingar. Skipta verður göngunni á og forskeytið verður að skrá á sniðið.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Skráning forskeytisins er það sem gerir það að standast endurtengingu, sem leið sem bætt er við handvirkt gerir ekki.

Haltu endapunktinum og DNS utan ákvörðunarinnar

VPN-endapunkturinn verður að vera aðgengilegur án göngunnar, annars hrynur gangan í sjálfa sig. Þegar aðeins 10.20.0.0/16 er beint er það sjálfvirkt, þar sem endapunkturinn er opinbert heimilisfang. Á sniði með fullri göngu er það ekki, og biðlarinn þarf skýra hýsilieið að endapunktinum áður en gangan rís.

DNS er önnur ákvörðun sem leiðarýting tekur ekki fyrir þig. Innri nöfn leysast venjulega í gegnum leysir sem aðeins hið einkaaða net kemst að. Ef netþjónninn ýtir DNS-netþjóni fer hvert nafn í gegnum hann; ef ekki mistakast innri nöfn eða leysast opinberlega í eitthvað sem þú ætlaðir ekki. Skipt DNS heldur einni leitarsvæði á innri leysinum, en það fer eftir stuðningi biðlarans, svo meðhöndlaðu það sem sjálfstætt verk en ekki aukaverkun leiðsagnar.

Sannprófaðu, endurræstu svo og sannprófaðu aftur

Þrjár prófanir ná yfir leiðsagnarspurninguna. Spurðu kjarnann hvert fjarlægt heimilisfang myndi fara, sæktu eitthvað innan úr neðra netinu og staðfestu svo að venjuleg opinber beiðni fari enn út um venjulegu tenginguna þína.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Fyrsta línan nefnir viðmót. Ef hún nefnir líkamlega viðmótið þitt lenti leiðin aldrei. Á Windows svarar Find-NetRoute -RemoteIPAddress 10.20.5.7 sömu spurningu, og síðasta prófið ætti enn að sýna venjulegt heimilisfang þitt en ekki VPN-netþjónsins.

Endurræstu svo. Leiðir sem bætt var við handvirkt hverfa, en leiðir frá sniðinu, frá ýttum stillingum eða frá AllowedIPs koma aftur. Ef þröngur aðgangur virkar fyrir endurræsinguna og bregst eftir hana liggur gallinn í því hvernig gangan ræsist, ekki í leiðinni sjálfri.

Áður en þú kallar þetta búið skaltu staðfesta fjóra hluti: forskeytið kom frá eiganda netsins og skarast ekki við neitt staðbundið, afturleiðin er til eða dulbúningsregla kemur í hennar stað, aðferðin sem þú stilltir er sú sem framfylgir leiðsögn á pallinum þínum, og sömu próf standast eftir hreina endurræsingu. Athugasemdir strongSwan um framsendingu eru þess virði að lesa ef afturleiðin er sá hluti sem heldur áfram að bregðast.