I-route lang ang isang lokal na web service sa labas ng VPN ayon sa port

Isang serbisyo ng host ang dapat tumugon sa internet sa pamamagitan ng pisikal na uplink habang ang lahat ng iba pa sa makina ay gumagamit pa rin ng tunnel. Tatlong kondisyon ang nagpapasya kung kayang dalhin ng policy routing ang load na iyon, at bawat isa ay murang suriin bago ka magsulat ng patakaran. Dapat magtapos ang serbisyo sa host na ito at hindi sa likod ng DNAT o forwarded na port, dapat pahintulutan ng sariling patakaran ng VPN ang eksepsiyon, at dapat itugma mo ang tugon hindi ang kahilingan. Kung mabigo ang alinman sa tatlo, malinis na maglo-load ang mga utos sa ibaba pero wala itong gagawing kapaki-pakinabang.

Suriin ang tatlong kondisyon bago magsulat ng patakaran

Ang container na naglalathala ng port sa pamamagitan ng DNAT, o server na nasa likod ng port forwarding, ay gumagawa ng mga packet na hindi nagmumula sa host na ito. Ang mga packet na iyon ay ipinapasa, kaya ang patakarang nakabatay sa lokal na input ng host ay hindi kailanman nakikita ang mga ito at patuloy na ginagamit ng trapiko ang default na ruta. Kumpirmahin kung saan talaga tumatakbo ang serbisyo bago magpatuloy, dahil ito ang kondisyong pinakamadalas maliin ng mga tao.

Ang ikalawang kondisyon ay patakaran at hindi mekanika. Anumang rutang lumalampas sa tunnel ay eksepsiyon sa layunin ng tunnel, at sa isang pinamamahalaang host, ang desisyong iyon ay pag-aari ng may-ari ng patakaran, hindi ng taong nagde-debug ng timeout.

Itugma ang tugon, hindi ang destination port ng client

Ang tugon mula sa server na nakikinig sa TCP 443 ay lumalabas sa host na may source port 443. Ang browser sa parehong host na kumokonekta sa malayong HTTPS site ay nagpapadala ng ephemeral source port at destination port 443. Pareho silang trapiko sa port 443 at isa lang sa kanila ang dapat kumuha ng WAN table, kaya't ang pagtutugma sa destination port ay makakahuli ng maling kalahati.

Ang direksiyon ng tugon ang kaya mong makilala. Itugma ang source port, limitahan ang patakaran sa mga packet na lokal na nabuo, at sinasaklaw ng patakaran ang sariling mga sagot ng serbisyo nang hindi hinahawakan ang mga kahilingan ng browser.

Bumuo ng kumpletong return table bago tumuro doon ang patakaran

Ang walang laman na table ay nangangahulugang walang ruta, na mukhang sirang serbisyo kaysa sirang patakaran. Punan muna ito, gamit ang table number at priority na walang ibang inaangkin sa host:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Basahin ang mga numero mula sa buhay na host sa halip na kopyahin ang mga ito. Sinasabi ng ip -4 rule show kung aling mga priority ang nakuha, at ang pagdaragdag ng patakaran sa priority na mayroon na ay tahimik na binabago ang pagkakasunod-sunod ng dalawang patakarang mukhang maayos kapag hiwalay.

Dalawang selector ang gumagawa ng tunay na trabaho dito. Ang iif lo ay ang paraan ng kernel sa pag-uulat ng mga packet na mismo ng host ang gumawa, kaya hindi aksidenteng mahuhuli ng patakaran ang forwarded na trapikong galing sa labas. Pinaliit ito ng ipproto tcp sport 443 sa isang transport at isang port, na kasinsikip ng pinapayagan ng pangangailangan. Alisin ang protocol selector at huhulihin din ng patakaran ang UDP 443, na ibang serbisyo na may ibang gawi.

Panatilihin ang mga pribadong sagot sa loob ng tunnel

Kung ang parehong listener ay sumasagot din sa mga client sa pribadong panig, susubukan ng default na WAN route na humuhuli ng lahat sa table 100 na ibalik ang mga sagot na iyon sa uplink. Idagdag ang mga pribadong prefix na hindi dapat sumunod sa WAN default, o hayaang mahulog ang mga ito sa susunod na patakaran ng polisiya:

ip -4 route add table 100 throw 10.90.0.0/24

Ang rutang throw ay nagtatapos sa paghahanap sa table na ito at ibinabalik ang packet sa listahan ng patakaran, kaya nakakakuha ng pagkakataon ang susunod na VPN policy. Hindi ito mismo nagro-route ng anuman papasok sa tunnel, at kung walang susunod na patakarang may tugmang ruta, nabibigo pa rin ang packet; i-verify ang susunod na polisiya sa halip na ipagpalagay na ang throw ay pag-aayos.

Ang reverse-path filtering at mga patakaran ng firewall ng host ay nalalapat pa rin sa papasok na kahilingan. Tingnan ang kanilang tunay na hatol bago paluwagin ang validation, dahil ang eksepsiyon sa routing ay hindi ginagawang tinatanggap ng rp_filter ang return path na itinuturing nitong imposible.

Subukan ang TCP, pagkatapos QUIC, pagkatapos ang reboot

Magbukas ng isang koneksiyon mula sa awtorisadong external client at isa mula sa pribadong panig, pagkatapos suriin ang paghahanap ng tugon gamit ang tunay na address at port. Kung kinukuha ng external na tugon ang table 100 at hindi ang pribado, ginagawa ng patakaran ang hiniling mo.

Ang HTTP/3 ay inihahain sa UDP at hindi itutugma ng patakaran ng TCP, kaya kailangan ng QUIC listener ang sarili nitong selector, kung hindi ay patuloy nitong gagamitin ang tunnel habang gumagana ang HTTPS. Itago ang mga patakarang napagpasyahan mo sa component na nagmamay-ari ng interface, at kumpirmahin ang mga ito pagkatapos ng muling pagkonekta o pag-renew ng DHCP. Kapag tinanggal ng kalabang manager ang runtime route pagkatapos ng reboot, problema iyon sa pagmamay-ari na dapat ayusin sa pinagmulan, hindi dahilan para magdagdag ng mas malawak na patakaran ng NAT sa ibabaw.