Rutahin ang isang LAN subnet sa OpenVPN at panatilihin ang default na ruta
Panatilihin ang default ng LAN habang dumadaan ang isang subnet sa tunnel. Ihambing ang talahanayan ng patakaran sa mga pagbabago sa pangunahing talahanayan, pagkatapos pumili ng NAT o ruta sa panig ng server.
Ang mga device na nag-route para sa LAN at sabay na dumayal sa VPN ay napupunta sa parehong pagtatalo sa sarili nila: gustong angkinin ng tunnel ang default na ruta, at kailangan itong bawiin ng LAN. Kapag kumonekta ang OpenVPN, maaari itong maglagay ng default sa tunnel o ng pares ng kalahating-default, na tama para sa laptop at mali para sa gateway na inaasahan ng mga kapitbahay na sumagot mula sa LAN address nito. Ang sagot ay hindi ang laktawan ang VPN. Ang sagot ay bigyan ang dalawang desisyon ng magkaibang talahanayan.
Isang default na ruta, dalawang may-ari
Ang forwarded na trapik at ang trapik na nagmumula nang lokal ay hindi kailangang dumaan sa parehong landas. Kailangan ng mga kliyente ng LAN ang tunnel para lamang sa mga destinasyong pipiliin mo, habang ang sariling mga sesyon ng pamamahala ng host at ang mga sagot nito sa mga kliyenteng iyon ay nangangailangan ng default ng LAN. Ang paghahalo ng dalawa sa pangunahing talahanayan ay nagpipilit ng isang sagot sa dalawang magkaibang tanong.
May switch ang OpenVPN para mismo dito. route-noexec pinipigilan ang kliyente na mahawakan ang pangunahing talahanayan, at ang mga halagang gagamitin sana nito ay iniluluwas sa isang script route-up bilang route_vpn_gateway, dev at ang mga address ng interface. Pagkatapos, ikaw ang magpapasya kung aling talahanayan ang makakakuha ng aling ruta, sa code na mababasa mo mamaya.
Talahanayan ng patakaran kumpara sa muling pagsulat ng pangunahing
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
Ang hiwalay na talahanayan ang tanging opsyon na lumalaki lampas sa isang subnet. Bigyan ito ng pangalan nang isang beses, pagkatapos ay tukuyin ito sa pangalan upang walang kailangang tumandaan ng numero:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnAng mga address dito ay placeholder. Palitan ang LAN prefix, ang gateway ng tunnel at ang pangalan ng device mula sa sarili mong deployment bago magpatakbo ng anuman.
Kailangang tumugma rin ang patakaran sa host
Ang patakarang tumutugma lamang sa LAN prefix ay sumasakop sa mga forwarded na packet. Hindi nito sinasakop ang trapik na nililikha mismo ng gateway, ni ang mga sagot na ipinapadala nito pabalik sa mga kliyente ng LAN, na nagdadala ng LAN address ng gateway bilang pinagmulan. Ang mga paghahanap na iyon ay bumabagsak sa main at maaari pa ring lumabas sa tunnel.
Magdagdag ng pangalawang patakaran para sa sariling LAN address ng gateway, o palawakin ang unang patakaran sa isang set na kinabibilangan ng dalawa. Mahalaga ang pagkakasunod-sunod: ilagay muna ang mas tiyak na patakaran, at tiyakin ang resulta sa isang paghahanap na tahasang pinangalanan ang pinagmulan.
ip route get 203.0.113.9 from 192.168.50.1Kung iyon ay nag-uulat ng device ng tunnel para sa destinasyong dapat manatiling lokal, mali ang set ng patakaran anuman ang laman ng talahanayan.
NAT o ruta sa kabilang panig
Alam ng VPN server ang subnet ng tunnel at wala nang iba. Ang mga packet na dumarating na may LAN source address ay walang daan pabalik maliban kung may magbigay ng isa, at may eksaktong dalawang paraan upang ibigay iyon. Ang pagdagdag ng ruta para sa LAN prefix sa server ay nagpapanatiling nakikita ang orihinal na pinagmulan mula dulo hanggang dulo, na kadalasang hinihiling ng isang na-audit na disenyo. Ang masking sa gateway ay nagsusulat muli ng pinagmulan sa address ng tunnel at hindi nangangailangan ng pakikipagtulungan ng server.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEPiliin ang NAT kapag hindi mo kontrolado ang server at hindi ka makapagdagdag ng ruta doon. Piliin ang ruta sa panig ng server kapag mahalaga ang mga log, kontrol sa pag-access o simetriya ng daan pabalik, dahil binubura ng masking ang orihinal na address mula sa lahat ng itinatala ng kabilang panig.
Sa alinmang paraan, dapat nakabukas ang forwarding, at ang mahigpit na reverse-path filtering ay maaaring magtapon ng sagot kapag hindi pipiliin ng main ang tunnel para sa pinagmulang iyon. Suriin ang epektibong halaga bago sisihin ang tunnel.
Gawing nakakaligtas ang paghahati sa muling pagkonekta
Ang mga patakaran at rutang idinagdag sa kamay ay nawawala kapag muling ginawa ang interface, at ang lumang entry sa talahanayan ay maaaring mabuhay nang mas matagal kaysa sa sesyong nagbigay-katwiran dito. Ilagay ang patakaran ng talahanayan, ang ruta ng tunnel at ang entry ng masking sa script route-up ng kliyente, at linisin ang talahanayan sa itaas ng script upang hindi mabuhay ang lumang gateway sa bagong sesyon.
Tiyakin mula sa dalawang dulo: isang paghahanap sa gateway gamit ang LAN source, at isang tunay na kahilingan mula sa kliyente ng LAN patungo sa destinasyong dapat dumaan sa tunnel. Ang rutang umiiral ngunit hindi kailanman pinipili ay kumikilos nang eksaktong parang walang ruta hanggang mabasa mo ang mga counter.