Susunod na hop sa ruta ng VPN: bakit dapat maabot ang gateway nang lokal

Ang rutang papasok sa isang network ng VPN ay may dalang dalawang address na madaling mapagkamalan: ang prefix ng destinasyon na sinusubukang abutin ng packet at ang susunod na hop na maglalapit dito nang isang hakbang. Sa isang host ng LAN, ang susunod na hop ay dapat na router na talagang maabot mo sa parehong link. Ang malayong address ng VPN ay hindi susunod na hop, gaano man kahusay itong tumugma sa destinasyong nasa isip mo.

Saklaw ng runbook na ito ang karaniwang kaso: isang laptop sa 192.168.20.0/24, isang gateway ng VPN na may LAN address na 192.168.20.5, at isang malayong network na 10.70.0.0/24 sa likod ng gateway na iyon. Ipinapalagay ng lahat ng utos sa ibaba na nasa laptop ka maliban kung sinabi ang iba.

Dalawang address, isang ruta

Ang inilaan na entry ay 10.70.0.0/24 via 192.168.20.5. Sinasabi ng prefix kung saan papunta ang packet; sinasabi ng address na via kung sino ang nagdadala nito roon. Tumatanggi ang kernel na mag-install ng rutang hindi nito maabot ang gateway sa pamamagitan ng interface na pinangalanan mo, at ang pagtanggi na iyon ang buong punto: ang susunod na hop na nangangailangan ng tunnel upang maabot ay hindi maaaring maging susunod na hop na nagtatayo ng tunnel.

Kaya ang unang pagsusuri ay hindi «gumagana ba ang gateway» kundi «nasa link bang ito ang gateway». Ang sariling subnet ng laptop, ang entry nito sa ARP o kapitbahay, at ang interface sa ruta ay dapat magtugma. Ang address na umiiral lamang sa loob ng 10.70.0.0/24 ay maaaring maging destinasyon ng pangalawang ruta, ngunit hindi kailanman ang via ng una.

Ano ang ipinapataw ng susunod na hop sa gateway

Ang pag-install ng ruta sa laptop ay nagpapasya lamang sa unang paghahatid. Pagkatapos, kailangan ng gateway ang sarili nitong landas: naka-enable ang forwarding, isang rutang tunnel para sa 10.70.0.0/24, at anumang patakaran sa pag-access na nagtatakda kung sino ang maaaring gumamit nito. Sa Linux iyon ay net.ipv4.ip_forward=1 kasama ang rutang tunnel; ang firewall sa harap nito ay nangangailangan ng tuntuning nagpapahintulot sa naipadalang daloy.

Ang direksyon ng pagbabalik ang bahaging nakakalimutan ng mga tao. Ang malayong panig ay dapat may rutang pabalik sa 192.168.20.0/24, o kailangang isalin ng disenyo ang pinagmulan ng laptop sa isang bagay na kilala ng malayong panig. Ang gumaganang ping mula sa gateway ay nagpapatunay na naaabot ng gateway ang malayong network; wala itong sinasabi tungkol sa kung ang mga packet ng laptop ay nakakaligtas sa paglalakbay pabalik.

I-verify ang paghahanap mula sa host na nagpapadala

Itanong sa kernel kung aling susunod na hop ang pipiliin nito, at basahin ang interface sa sagot:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Kung iniuulat ng paghahanap ang gateway at ang interface ng LAN, ang unang bahagi ay naka-configure ayon sa inilaan. Kung iniuulat nito ang device ng tunnel, may isang bagay na mas maaga sa talahanayan na mas partikular at nananalo. Kung hindi talaga ma-install ang ruta, sinasabi ng kernel na hindi maabot ang gateway, at ang mensaheng iyon ay mas kapaki-pakinabang kaysa sa anumang paghuli ng packet.

Pagkatapos, ulitin ang pagsubok mula sa tamang lugar. Ang kahilingang ginawa sa gateway ay gumagamit ng sariling source address ng gateway, na maaaring magtago ng kulang na rutang pabalik o patakarang nagpapahintulot lamang sa ilang pinagmulan. Ang manwal ng ip-route ay naghihiwalay ng destinasyon, gateway, at ng override na onlink, at sulit na maunawaan ang override bago ito gamitin.

Huwag gamitin ang onlink upang magpanggap ng maaabot

onlink ay nagsasabi sa kernel na laktawan ang pagsusuri ng maaabot ng isang gateway at magpadala pa rin doon. Hindi ito gumagawa ng landas, hindi nito nire-resolve ang ARP para sa address na wala, at hindi nito pinapasagot ang isang malayong router sa iyong segment ng Ethernet. Lehitimo ito para sa mga gateway na sumasagot ngunit wala sa konektadong subnet, at bitag ito kapag ginamit upang patahimikin ang isang error na hindi mo ipinaliwanag.

Kung ang ruta ay nag-i-install lamang sa onlink, ang susunod na tanong ay bakit wala ang gateway sa lugar na inaakala mo. Maling VLAN, pangalawang address sa maling interface, o typo sa huling octet — lahat ng ito ay nagdudulot nito, at bawat isa sa kanila ay sumisira rin sa landas pabalik kapag nagsimulang dumaloy ang trapiko.

Ang mga tunnel na point-to-point ay hindi Ethernet

Ang device ng tunnel ay hindi gumagawa ng ARP at kadalasan ay walang makabuluhang subnet ng mga kapitbahay. Ang mga ruta nito ay madalas na mukhang 10.70.0.0/24 dev tun0, na walang anumang via, dahil ang peer ang tanging iba pang dulo. Ang pagkopya ng via sa istilong LAN sa talahanayang iyon ay gumagawa ng rutang maaaring tanggihan ng kernel o, mas masama, isang rutang tumuturo sa address na hindi sinasagot ng peer.

Panatilihing hiwalay ang dalawang modelo sa runbook: ang rutang LAN ay may maaabot na gateway, ang rutang tunnel ay may interface at peer. Ang WireGuard, OpenVPN, at IPsec ay nagpapakita ng bahagyang magkakaibang hugis, kaya itala ang hugis na talagang ginamit mo sa halip na mag-generalize mula sa isang host.

Idagdag, kumpirmahin, i-roll back

Ang buong pagbabago ay tatlong utos at isang pagsusuri, at dapat itong isulat sa ganoong pagkakasunod-sunod:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Kumpirmahin ang landas, kumpirmahin ang isang destinasyon, pagkatapos ay ihanda ang linyang pangtanggal kung sakaling gawing hindi maabot ng pagbabago ang host sa paraang hindi mo inaasahan. Kung ang ruta ay kailangang mabuhay pagkatapos ng reboot, ilagay ito sa configuration ng network ng host at hindi sa isang profile ng shell, at subukan ang reboot bago ka umasa rito. Ang rutang umiiral lamang sa shell na nagdagdag nito ay isang rutang i-de-debug mo nang dalawang beses.