Paano magpadala ng isang pribadong subnet lamang sa VPN

Ang isang pribadong subnet sa tunnel at lahat ng iba pa sa dati mong landas ay maliit na kahilingan na may napakaraming paraan para mapagkamalan. Ang nagtatakda ng resulta ay hindi ang checkbox na tinatawag na split tunneling, kundi kung saan ipinapatupad ang desisyon: sa sariling routing table ng kliyente, sa rutang itinutulak ng server, o sa patakarang pinagkasunduan ng dalawang dulo. Pumili ka ng maling layer at makakakuha ka ng buong tunnel na hindi mo kailanman hinangad, o ruta patungo sa tunnel na ayaw tanggapin ng kabilang panig. Gumagamit ako ng pagsubok na may tatlong kondisyon bago magbukas ng anumang configuration, pagkatapos ay pipiliin ang isa sa mga mekanismong nasa ibaba.

Tatlong kondisyong nagtatakda ng disenyo

Una, kailangan mo ang eksaktong prefix at mask mula sa may-ari ng network. Ang 10.x network ay hindi prefix; ang 10.20.0.0/16 ang prefix. Tiyakin na hindi ito nagsasapawan sa iyong home LAN, sa Docker bridge o sa iba pang VPN na pinapatakbo mo, dahil ang sapawan ay nagpapalabo sa ruta at pinipili ng kernel ang entry na hindi mo sinadya.

Ikalawa, sino ang sumasagot sa pabalik na trapiko. Ang pagruruta ng packet papasok sa tunnel ay naghahatid lamang nito sa VPN server. Kung ang subnet ay nasa likod ng ibang router na walang rutang pabalik sa iyong client pool, kailangang i-masquerade ng server ang trapiko, o kailangang matutunan ng router na iyon ang iyong pool. Walang ruta sa panig ng kliyente ang nag-aayos ng kulang na pabalik na landas.

Ikatlo, ang punto ng pagpapatupad. May mga kliyenteng nag-i-install ng ruta at ang operating system ang gumagawa ng iba. May ibang nakikipagkasundo sa patakaran, at ang patakarang hindi tinatanggap ng gateway ay walang nabubuong tunnel: itinatapon ang mga packet nang walang malinaw na error. Alamin kung alin sa dalawa ang iyong kaso bago magsulat ng kahit ano.

WireGuard: AllowedIPs ang routing table

Sa kliyente, inililista ng AllowedIPs ang mga destinasyong pinapasok sa tunnel, at ginagawang ordinaryong ruta ng wg-quick ang bawat entry. Kaya ang kalahati ng kliyente sa gawaing ito ay isang linya.

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

Ngayon ihambing ang entry ng server para sa parehong kliyente. Inilalarawan nito ang ipapadala ng server sa kliyente, na karaniwang ang tunnel address ng kliyente, hindi ang pribadong subnet.

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

Ang pagpapalit ng dalawang ito ang pinakamadalas kong makita. Ang paglalagay ng 10.20.0.0/16 sa ilalim ng peer section ng server ay nagsasabing ang buong subnet ay nasa likod ng kliyenteng iyon, at iyon ay pag-aangkin mula sa site patungo sa site, hindi pahintulot. Ang mga packet na hindi tumutugma sa AllowedIPs ng alinmang peer ay tahimik na itinatapon, kaya ang maling entry ay mukhang eksaktong problema sa firewall.

Kung ikaw mismo ang namamahala ng mga ruta, itakda ang Table = off sa ilalim ng [Interface] at idagdag ang rutang gusto mo. Wala nang awtomatikong naidaragdag noon, kaya ang ruta ay nabibilang sa kung ano ang nag-aangat ng interface.

OpenVPN: itulak ang ruta, pagkatapos tiyakin na dumarating ito

Sa ordinaryong server, ang pagbabago ay isang direktiba sa configuration ng server, katabi ng client pool.

push "route 10.20.0.0 255.255.0.0"

Idinadagdag ito ng kliyente kapag kumokonekta. Lumilitaw ang failure mode kapag ang parehong profile ay nagtutulak din ng redirect-gateway, o kapag may nagdagdag na ng route-nopull: ang una ay ginagawang buong tunnel ang session, at ang pangalawa ay itinatapon ang bawat itinulak na ruta, kasama ang iyo.

Ang kliyenteng kailangan ng makitid na pag-uugali laban sa server na may buong tunnel ay dapat huwag pansinin lamang ang mga bahaging ayaw niya. Sa OpenVPN 2.4 at mas bago, may pull-filter para eksaktong dito.

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

Panatilihing hiwalay ang mga pamilya ng address: ang itinulak na rutang IPv4 ay walang ginagawa para sa panloob na serbisyong nare-resolve sa IPv6, at ang serbisyong iyon ay nabigo sa tunnel habang maayos ang tingin sa iba.

Kapag ang pribadong subnet ay wala sa VPN server kundi nasa likod ng ibang kliyente, kailangang ipaalam sa server. Magdagdag ng file bawat kliyente sa pamamagitan ng client-config-dir na naglalaman ng iroute 10.20.0.0 255.255.0.0, kasama ang tugmang route upang matutunan ng ibang kliyente ang landas. Kung walang iroute, walang dahilan ang server na ipadala ang prefix na iyon sa partikular na tunnel na iyon.

IPsec: kailangang magkasundo ang mga selector ng trapiko

Sa IPsec wala kang rutang itutulak. Nagkasundo ang dalawang dulo kung aling mga address ang nasa loob ng tunnel, at ang trapikong labas sa napagkasunduang selector ay hindi ini-encrypt at hindi dumadaan doon. Sa kliyenteng strongSwan, hayag ang mga selector.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Kung ang gateway ay naka-configure gamit ang 0.0.0.0/0 sa magkabilang panig, ang pagpapakitid ng IKEv2 ay karaniwang nagpapababa ng child SA sa interseksyon ng dalawang proposal, na siyang gustong resulta. May mga gateway na sa halip ay tinatanggihan ang proposal na hindi tumutugma sa kanilang naka-configure na selector, at ang log ay nagpapakita ng bigong child SA sa halip na reklamo sa routing. Kapag nangyari iyon, ang pagbabago ay para sa gateway, dahil ang ruta sa kliyente ay hindi makakagawa ng tunnel para sa selector na hindi tatanggapin ng kabilang panig.

Sa Windows, itinatago ng built-in na kliyente ang parehong desisyon sa likod ng dalawang setting. Dapat nakabukas ang tunnel splitting, at dapat nakarehistro ang prefix sa profile.

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

Ang pagrerehistro ng prefix ang dahilan kung bakit nakakaligtas ito sa muling pagkonekta, na hindi nagagawa ng rutang idinagdag sa kamay.

Ilayo ang endpoint at DNS sa desisyon

Ang VPN endpoint ay dapat manatiling maabot nang walang tunnel, kung hindi ay gumuho ang tunnel sa sarili nito. Kapag tanging 10.20.0.0/16 ang niruruta, awtomatiko iyon dahil pampublikong address ang endpoint. Sa profile na may buong tunnel, hindi ganito, at kailangan ng kliyente ng hayag na host route patungo sa endpoint bago umangat ang tunnel.

Ang DNS ay ikalawang desisyon na hindi ginagawa ng pagtutulak ng ruta para sa iyo. Ang mga panloob na pangalan ay karaniwang nare-resolve sa resolver na maaabot lamang ng pribadong network. Kung nagtutulak ang server ng DNS server, lahat ng pangalan ay dumadaan doon; kung hindi, ang mga panloob na pangalan ay nabigo o nare-resolve nang pampubliko sa isang bagay na hindi mo sinadya. Ang split DNS ay nagpapanatili ng isang search domain sa panloob na resolver, ngunit nakadepende iyon sa suporta ng kliyente, kaya ituring itong sariling gawain at hindi epekto ng routing.

I-verify, pagkatapos i-reboot at i-verify muli

Tatlong pagsusuri ang sumasaklaw sa tanong ng routing. Itanong sa kernel kung saan pupunta ang malayong address, kumuha ng isang bagay mula sa loob ng subnet, pagkatapos ay tiyakin na ang ordinaryong pampublikong kahilingan ay lumalabas pa rin sa iyong normal na koneksyon.

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

Pinangalanan ng unang linya ang isang interface. Kung pinangalanan nito ang iyong pisikal na interface, hindi kailanman nakarating ang ruta. Sa Windows, sinasagot ng Find-NetRoute -RemoteIPAddress 10.20.5.7 ang parehong tanong, at ang huling pagsusuri ay dapat pa ring magpakita ng iyong karaniwang address at hindi ng VPN server.

Pagkatapos ay i-reboot. Nawawala ang mga rutang idinagdag sa kamay, habang bumabalik ang mga ruta mula sa profile, sa itinulak na configuration o sa AllowedIPs. Kung gumagana ang makitid na access bago ang restart at nabigo pagkatapos, ang kasalanan ay nasa paraan ng pagsisimula ng tunnel, hindi sa ruta mismo.

Bago mo sabihing tapos na, tiyakin ang apat na bagay: ang prefix ay nagmula sa may-ari ng network at hindi nagsasapawan sa anumang lokal, umiiral ang pabalik na landas o may panuntunan ng masquerade na pumapalit dito, ang mekanismong na-configure mo ang siyang nagpapatupad ng routing sa iyong platform, at ang parehong pagsusuri ay pumasa pagkatapos ng malinis na restart. Ang mga tala ng strongSwan sa pagpapasa ay sulit basahin kung ang pabalik na landas ang bahaging patuloy na nabigo.