Router ng LAN at kliyente ng VPN: dalawang aparato, dalawang talahanayan ng ruta

Dalawang aparato ang nagpapasa ng packet at bawat isa ay may sariling talahanayan. Alam ng router ng LAN na ang malayong prefix ay pag-aari ng kliyente ng VPN, at alam ng kliyente ng VPN kung paano marating ang prefix na iyon sa pamamagitan ng sarili nitong tunnel. I-configure lamang ang unang talahanayan at ang packet ay dumarating sa isang makina na walang tugmang ruta, kaya lumalabas itong muli sa default. Iyon ang buong sira, at mula sa panig ng LAN mukha itong loop ng pagruruta, dahil halos ganoon nga.

Iguhit ang dalawang hop bago hawakan ang isang ruta

Kumuha ng halimbawang layout: mga host ng LAN sa 192.168.50.0/24, ang ordinaryong router sa 192.168.50.1, isang dedikadong kliyente sa 192.168.50.15, at isang malayong LAN sa 10.60.0.0/24 na maabot lamang sa pamamagitan ng tunnel na hawak ng kliyenteng iyon. Wala sa dalawang pribadong saklaw ang nagsasapaw sa isa, at ang tunnel ay may sariling plano ng address.

Mahalaga ang dalawang pribadong saklaw dahil sila ang nagtatakda kung aling aparato ang makakasagot. Makikita ng malayong panig ang packet na dumarating mula sa tunnel address ng kliyente, at ang sagot nito ay kailangang makahanap ng daan pabalik sa 192.168.50.0/24. Kung ang palabas na direksyon lamang ang naka-configure, maaaring gumana ang kahilingan habang nawawala ang sagot.

Hakbang 1: itutok ang router sa kliyente, hindi sa tunnel

Sa router ng LAN, magdagdag ng rutang patutunguhan na ang susunod na hop ay ang LAN address ng kliyente:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Sinasabi ng rekord na iyon na “ihatid ito sa makina na marunong mag-tunnel”. Wala itong sinasabi tungkol sa kung paano itinatayo ang tunnel, at hindi ito kapalit ng sariling ruta ng kliyente. Sa isang pinamamahalaang router, ang katumbas ay nasa pahina ng mga static na ruta ng aparato; sa isang Linux router, kabilang ito sa configuration ng interface na nagmamay-ari ng LAN, hindi sa isang shell na isasara mo.

Suriin ang sagot ng ikalawang utos. Kung iniuulat nito ang kliyente bilang gateway at ang LAN interface bilang device, tama ang unang hop at ang natitirang gawain ay nasa kabilang makina.

Hakbang 2: bigyan ang kliyente ng sariling ruta sa panig ng tunnel

Tumatanggap na ngayon ang kliyente ng packet para sa 10.60.0.0/24 at tinitingnan ang sariling talahanayan. Kung nag-install ang configuration ng tunnel nito ng ruta para sa prefix na iyon, nagpapatuloy ang packet na naka-encrypt. Kung hindi, tumutugma ang packet sa ordinaryong default at bumabalik sa 192.168.50.1, na muling nagpapadala nito sa kliyente.

Tingnan bago magdagdag ng anuman:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Ang nawawalang ruta ng prefix sa lahat ng talahanayan ang siyang natuklasan na hinahanap mo. Idagdag ito sa pamamagitan ng sariling configuration ng tunnel, upang ma-install itong muli ng susunod na muling pagkonekta; ang manu-manong ip route add ay nawawala kasama ng session at pinapabalik ang sira sa pinaka-hindi angkop na sandali. Ang susunod na hop ay ang tunnel interface o ang address na ibinibigay ng VPN bilang kapareha nito, depende sa kliyente, at ang address ng kapareha ay dapat magmula sa kasalukuyang profile at hindi sa lumang tala.

Ang loop, kapag nangyari, ay hindi walang hanggan sa praktika: bumababa ang TTL sa bawat pagdaan at namamatay ang packet na may mensaheng lumampas ang oras. Kaya maaaring magmungkahi ng siklo ang paulit-ulit na traceroute habang ang kliyenteng hindi nagpapasa ay tahimik na inihuhulog ang parehong packet.

Hakbang 3: payagan ang pagpapasa at piliin ang daan ng pagbabalik

Ang pagtanggap at pagpapasa ay magkaibang pahintulot. Ang net.ipv4.ip_forward=1 sa kliyente ay nagpapahintulot ng transit sa antas ng kernel, at kailangan pa ring payagan ito ng isang patakaran ng firewall sa pagitan ng LAN interface at ng tunnel. Ang patakarang nagpapahintulot ng pag-access sa pahina ng pamamahala ng kliyente mismo ay hindi magpapahintulot ng transit patungo sa malayong LAN, at ang pagkakaiba ay madaling makaligtaan kapag ang parehong host ay sumasagot ng ping nang lokal.

Ang malayong panig ay may problemang salamin. Dapat nitong malaman na ang 192.168.50.0/24 ay maabot sa pamamagitan ng naka-authenticate na kliyenteng ito. Sa OpenVPN karaniwang ibig sabihin nito ay isang ruta bawat kliyente na itinutulak ng configuration ng server, o isang file na partikular sa kliyente sa server na nagdedeklara ng LAN sa likod ng kliyente. Kung wala iyon, ang malayong LAN ay alinman sa inihuhulog ang sagot o ipinapadala ito sa sariling default gateway, na siyang internet.

Ang pagsasalin ng source ay ang alternatibo kapag hindi maipahayag ang prefix ng LAN. Ang isang saklaw na patakaran ng masquerade sa kliyente ay nagsusulat muli ng source sa tunnel address, at pagkatapos ay natural na bumabalik ang mga sagot. Itinatago rin nito kung aling host ng LAN ang gumawa ng kahilingan, at hindi nito pinapayagan ang malayong panig na magsimula ng mga koneksyon papasok. Piliin ang kompromisong iyon nang sinasadya sa halip na magdagdag ng blanket na masquerade at tuklasin ang epekto sa paglaon.

Hakbang 4: gawing permanente ang dalawang desisyon, pagkatapos ay subukan ang tunay na daan

Bawat ruta ay may may-ari, at ang may-ari ay ang configuration na muling nabubuo sa boot o sa muling pagkonekta. Sa router maaaring isang entry ng static na ruta; sa kliyente maaaring ang profile ng VPN, NetworkManager o systemd-networkd. I-verify sa pamamagitan ng muling pagkonekta ng tunnel at pag-restart ng kliyente, pagkatapos ay basahin muli ang talahanayan sa halip na magtiwala sa pag-edit.

Panatilihing buo ang default na ruta na nagdadala ng panlabas na koneksyon ng tunnel. Ang pagpapalit nito upang “pasimplehin” ang setup ay sinira ang naka-encrypt na daan bago pa ito magamit ng anumang panloob na trapiko, at ang sintomas ay isang tunnel na hindi na muling naitatatag pagkatapos ng pagbabago.

Subukan mula sa isang ordinaryong host ng LAN, hindi mula sa kliyente, dahil ang kahilingang nagmumula sa kliyente ay hindi kailanman gumagamit ng unang hop ng router. Kumuha ng serbisyong umiiral lamang sa malayong LAN at kumpirmahin ang katawan ng sagot, pagkatapos ay tingnan ang mga counter o log ng kliyente upang makita ang pagdaan. Ang panloob na traceroute na nagpapakita ng mga pribadong hop ay nagpapatunay ng pagpapasa, hindi ng encryption: ang panlabas na daan ay hiwalay na obserbasyon, at tanging ang mga counter ng interface ng tunnel mismo ang nagpapakita kung ano ang lumabas dito.