Rutați în afara VPN doar un serviciu web local, după port

Un serviciu al gazdei trebuie să răspundă internetului prin legătura ascendentă fizică în timp ce tot restul de pe mașină continuă să folosească tunelul. Trei condiții decid dacă rutarea bazată pe politici poate duce această încărcare, și fiecare este ieftin de verificat înainte de a scrie o regulă. Serviciul trebuie să se termine pe această gazdă, nu în spatele unui DNAT sau al unui port redirecționat, regulile proprii ale VPN-ului trebuie să permită excepția, și trebuie să potriviți răspunsul, nu cererea. Dacă eșuează oricare dintre cele trei, comenzile de mai jos se încarcă fără erori dar nu fac nimic util.

Verificați cele trei condiții înainte de a scrie o regulă

Un container care publică un port prin DNAT, sau un server aflat în spatele unei redirecționări de port, produce pachete care nu provin de pe această gazdă. Acele pachete sunt redirecționate, așa că o regulă bazată pe intrarea locală a gazdei nu le vede niciodată și traficul continuă să folosească ruta implicită. Confirmați unde rulează de fapt serviciul înainte de a continua, pentru că este condiția la care oamenii greșesc cel mai des.

A doua condiție este politică, nu mecanică. Orice rută care ocolește tunelul este o excepție de la scopul tunelului, iar pe o gazdă administrată acea decizie aparține celui care deține politica, nu persoanei care depanează un timp de expirare.

Potriviți răspunsul, nu portul de destinație al clientului

Răspunsul unui server care ascultă pe TCP 443 părăsește gazda cu portul sursă 443. Un browser de pe aceeași gazdă care se conectează la un site HTTPS aflat la distanță trimite un port sursă efemer și portul de destinație 443. Ambele sunt trafic pe portul 443 și doar unul ar trebui să folosească tabela WAN, de aceea o potrivire pe portul de destinație ar prinde jumătatea greșită.

Direcția răspunsului este ceea ce puteți distinge. Potriviți portul sursă, limitați regula la pachetele generate local, iar regula acoperă răspunsurile serviciului însuși fără a atinge cererile browserului.

Construiți un tabel de întoarcere complet înainte ca regula să indice spre el

Un tabel gol înseamnă nicio rută, ceea ce arată ca un serviciu stricat, nu ca o politică stricată. Completați-l mai întâi, cu un număr de tabel și o prioritate pe care nimic altceva de pe gazdă nu le revendică:

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

Citiți numerele de pe gazda activă în loc să le copiați. ip -4 rule show vă spune ce priorități sunt ocupate, iar adăugarea unei reguli pe o prioritate care există deja schimbă în tăcere ordinea a două reguli care separat par corecte.

Aici fac munca reală doi selectori. iif lo este modul în care nucleul raportează pachetele generate de gazda însăși, astfel încât regula nu poate prinde accidental trafic redirecționat care vine din afară. ipproto tcp sport 443 îl restrânge la un transport și un port, ceea ce este la fel de strâns pe cât permite cerința. Scoateți selectorul de protocol și regula prinde și UDP 443, care este un alt serviciu cu alt comportament.

Țineți răspunsurile private în interiorul tunelului

Dacă același ascultător răspunde și clienților din partea privată, o rută WAN implicită care prinde tot în tabelul 100 va încerca să trimită acele răspunsuri înapoi prin legătura ascendentă. Adăugați prefixele private care nu trebuie să urmeze ruta WAN implicită, sau lăsați-le să treacă la următoarea regulă de politică:

ip -4 route add table 100 throw 10.90.0.0/24

O rută throw încheie căutarea în acest tabel și returnează pachetul listei de reguli, astfel încât politica VPN care urmează își primește șansa. Ea însăși nu rutează nimic în tunel, iar dacă nicio regulă ulterioară nu are o rută potrivită, pachetul tot eșuează; verificați politica următoare în loc să presupuneți că throw este o soluție.

Filtrarea căii inverse și regulile de firewall ale gazdei se aplică în continuare cererii care sosește. Uitați-vă la verdictele lor reale înainte de a relaxa validarea, pentru că o excepție de rutare nu face ca rp_filter să accepte o cale de întoarcere pe care o consideră imposibilă.

Testați TCP, apoi QUIC, apoi o repornire

Deschideți o conexiune de la un client extern autorizat și una din partea privată, apoi inspectați căutarea răspunsului cu adresele și porturile reale. Dacă răspunsul extern folosește tabelul 100 iar cel privat nu, politica face ce ați cerut.

HTTP/3 este servit prin UDP și nu va fi potrivit de o regulă TCP, așa că un ascultător QUIC are nevoie de propriul selector, altfel va continua să folosească tunelul în timp ce HTTPS funcționează. Păstrați regulile la care vă opriți la componenta care deține interfața și confirmați-le după o reconectare sau o reînnoire DHCP. Când un manager concurent elimină o rută de execuție după o repornire, aceasta este o problemă de proprietate de rezolvat la sursă, nu un motiv pentru a adăuga reguli NAT mai largi deasupra.