Drejto vetëm një shërbim web lokal jashtë VPN-së sipas portës

Një shërbim i hostit duhet t'i përgjigjet internetit përmes lidhjes fizike ngjitëse, ndërsa gjithçka tjetër në makinë vazhdon të përdorë tunelin. Tre kushte vendosin nëse drejtimi i bazuar në politikë mund ta mbajë atë ngarkesë, dhe secili është i lirë për t'u kontrolluar përpara se të shkruani një rregull. Shërbimi duhet të përfundojë në këtë host dhe jo pas një DNAT ose një porte të ridrejtuar, rregullat e vetë VPN-së duhet ta lejojnë përjashtimin, dhe ju duhet të përputhni përgjigjen, jo kërkesën. Nëse dështon ndonjë nga të tre, komandat më poshtë ngarkohen pa gabime, por nuk bëjnë asgjë të dobishme.

Kontrolloni tre kushtet përpara se të shkruani një rregull

Një kontejner që publikon një port përmes DNAT, ose një server pas një ridrejtimi porte, prodhon paketa që nuk e kanë origjinën në këtë host. Ato paketa ridrejtohen, prandaj një rregull i bazuar në hyrjen lokale të hostit nuk i sheh kurrë dhe trafiku vazhdon të marrë rrugën e parazgjedhur. Konfirmoni ku shërbimi ekzekutohet vërtet përpara se të vazhdoni, sepse ky është kushti ku njerëzit gabojnë më shpesh.

Kushti i dytë është politikë dhe jo mekanikë. Çdo rrugë që anashkalon tunelin është përjashtim nga qëllimi i tunelit, dhe në një host të menaxhuar ai vendim i takon atij që zotëron politikën, jo personit që korrigjon një afat kohor.

Përputhni përgjigjen, jo portën e destinacionit të klientit

Përgjigja e një serveri që dëgjon në TCP 443 e lë hostin me portën burimore 443. Një shfletues në të njëjtin host që lidhet me një sajt HTTPS të largët dërgon një portë burimore të përkohshme dhe portën e destinacionit 443. Të dyja janë trafik i portës 443 dhe vetëm njëra duhet të marrë tabelën WAN, prandaj një përputhje e portës së destinacionit do të kapte gjysmën e gabuar.

Drejtimi i përgjigjes është ajo që mund të dalloni. Përputhni portën burimore, kufizoni rregullin te paketat e krijuara lokalisht, dhe rregulli mbulon përgjigjet e vetë shërbimit pa prekur kërkesat e shfletuesit.

Ndërtoni një tabelë të plotë kthimi përpara se rregulli të tregojë drejt saj

Një tabelë bosh do të thotë asnjë rrugë, gjë që duket si shërbim i prishur dhe jo si politikë e prishur. Plotësojeni së pari, me një numër tabele dhe prioritet që asgjë tjetër në host nuk i kërkon:

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

Lexoni numrat nga hosti aktiv në vend që t'i kopjoni. ip -4 rule show ju tregon cilat prioritete janë zënë, dhe shtimi i një rregulli në një prioritet që ekziston tashmë ndryshon në heshtje renditjen e dy rregullave që veçmas duken në rregull.

Punën e vërtetë e bëjnë këtu dy përzgjedhës. iif lo është mënyra se si kerneli raporton paketat që i ka krijuar vetë hosti, kështu që rregulli nuk mund të kapë aksidentalisht trafik të ridrejtuar që vjen nga jashtë. ipproto tcp sport 443 e shtrëngon atë në një transport dhe një portë, gjë që është aq e ngushtë sa lejon kërkesa. Hiqni përzgjedhësin e protokollit dhe rregulli do të kapë edhe UDP 443, që është një shërbim tjetër me sjellje tjetër.

Mbani përgjigjet private brenda tunelit

Nëse i njëjti dëgjues u përgjigjet edhe klientëve në anën private, rruga e parazgjedhur e WAN-it që kap gjithçka në tabelën 100 do të përpiqet t'i kthejë ato përgjigje përmes lidhjes ngjitëse. Shtoni prefikset private që nuk duhet të ndjekin parazgjedhjen e WAN-it, ose lërini të bien në rregullin tjetër të politikës:

ip -4 route add table 100 throw 10.90.0.0/24

Rruga throw e përfundon kërkimin në këtë tabelë dhe e kthen paketën te lista e rregullave, kështu që politika e VPN-së që vjen më pas merr shansin e saj. Ajo vetë nuk drejton asgjë në tunel, dhe nëse asnjë rregull i mëvonshëm nuk ka një rrugë përputhëse, paketa përsëri dështon; verifikoni politikën tjetër në vend që të supozoni se throw është një rregullim.

Filtrimi i rrugës së kundërt dhe rregullat e murit të zjarrit të hostit vazhdojnë të zbatohen për kërkesën që mbërrin. Shikoni verdiktet e tyre reale përpara se të lironi validimin, sepse një përjashtim drejtimi nuk e bën rp_filter të pranojë një rrugë kthimi që e konsideron të pamundur.

Testoni TCP, pastaj QUIC, pastaj një rinisje

Hapni një lidhje nga një klient i jashtëm i autorizuar dhe një nga ana private, pastaj inspektoni kërkimin e përgjigjes me adresat dhe portat reale. Nëse përgjigja e jashtme merr tabelën 100 dhe ajo private jo, politika po bën atë që kërkuat.

HTTP/3 ofrohet përmes UDP dhe nuk do të përputhet nga një rregull TCP, prandaj një dëgjues QUIC ka nevojë për përzgjedhësin e vet, përndryshe do të vazhdojë të përdorë tunelin ndërsa HTTPS funksionon. Ruani rregullat me të cilat ndaleni te komponenti që zotëron ndërfaqen, dhe konfirmojini pas një rilidhjeje ose një rinovimi DHCP. Kur një menaxher konkurrues heq një rrugë ekzekutimi pas një rinisjeje, ky është një problem pronësie që duhet rregulluar në burim, jo një arsye për të shtuar rregulla NAT më të gjera sipër.