Subrețea din aval vs VPN de desktop: excludeți tranzitul, nu aplicațiile

O mașină, două sarcini, un firewall: o legătură Wi-Fi în amonte, o mică subrețea Ethernet în spatele ei și un client VPN de desktop care presupune că tot ce iese din mașină este local. Aplicațiile lansate local ies pe calea de ieșire locală. Dispozitivele din spatele stației de lucru sosesc pe portul Ethernet și au nevoie de o decizie de transmitere. O excludere scrisă pentru prima cale nu vede niciodată a doua, și de aceea un browser ocolește tunelul, iar dispozitivele nu.

Două căi de pachete, o singură politică

Primul rând este ceea ce descriu majoritatea ghidurilor de split-tunneling. Al doilea este o configurație de router care se întâmplă să locuiască pe aceeași mașină. Topirea lor într-un singur model mental este greșeala; împart un nucleu, dar nu o politică. Desenați ambele căi înainte de a edita orice regulă, iar restul proiectului decurge din care cale lipsește.

Tabelul explică și de ce o mașină poate trece un test și poate eșua altul. Browserul de pe stația de lucru dovedește calea locală; un laptop conectat la portul Ethernet dovedește calea de transmitere. Validați fiecare modificare cu ambele, altfel a doua rămâne netestată oricât de des ați reîncărca browserul.

Ce clasifică de fapt o excludere de aplicație

O excludere per aplicație funcționează de obicei prin marcarea pachetelor unui proces sau ale unui utilizator și apoi rutarea traficului marcat în afara tunelului. Aceasta este o construcție de ieșire locală. Un pachet de la un dispozitiv din aval nu are proces local, așa că nu se potrivește niciodată cu selectorul, oricare ar fi selectorul.

Oricare ar fi selectorul, cele două liste nu sunt aceeași listă, și exact aceasta este ideea. Ghidul Mullvad pentru Linux descrie marcaje consumate de firewall-ul și de politica sa de rutare, iar exemplele sale vizează ieșirea locală; nu sunt o descriere acceptată a unui router din aval. Copierea lor produce o mașină care crede că are o excludere în timp ce transmite totul în tunel.

Scrieți contractul de tranzit

Numiți împreună prefixul sursă din aval și interfața de intrare, apoi restricționați acel prefix la intrare. Fără restricție, orice dispozitiv care ajunge la port poate revendica o adresă exclusă și poate ieși prin ocolire. Tratați-o ca două întrebări: au voie aceste gazde să folosească această legătură, și au voie să ajungă la stația de lucru sau la intervalele private ale tunelului? Acestea sunt permisiuni suplimentare, nu efecte secundare ale alegerii legăturii.

Permiteți transmiterea, apoi filtrați-o. Gateway-ul Linux are nevoie de transmitere activată, reguli care permit traficul dorit în ambele direcții și fie o rută de retur în amonte, fie o traducere de sursă limitată intenționat. NAT singur nu selectează legătura și nu acordă trecerea printr-un filtru; rescrie o adresă doar după acele decizii.

Clasificarea pentru tranzit trebuie să aibă loc înainte de decizia rutei de transmitere, adică în etapa prerouting și nu în output. O regulă plasată după decizie mai poate schimba pachetul, dar nu poate schimba unde a fost deja trimis.

Marcajele aparțin aplicației care le deține

Valorile marcajelor, numerele de tabel și prioritățile lanțurilor fac parte din politica aplicației VPN, nu sunt constante veșnice. O rețea durabilă care depinde de inserarea unei reguli într-un tabel pe care alt program îl regenerează se va rupe la următoarea actualizare, de obicei în timpul unei reconectări și nu la un moment convenabil.

Adăugarea unui al doilea lanț de bază cu verdict accept nu înlocuiește neapărat drop-ul unui lanț ulterior. Lanțurile de bază au cârlige și priorități, iar primul verdict din ordine câștigă; un accept într-un lanț nu anulează un drop la care alt lanț ajunge primul. Uitați-vă la setul complet de reguli și la ordinea politicii de rutare, nu la singurul contor care a crescut. Un contor dovedește că o regulă a rulat, niciodată că verdictul ei a fost cel aplicat.

Integrați, sau mutați subrețeaua

Cele două proiecte diferă prin cine deține ocolirea. Un proiect integrat păstrează o mașină și o politică, cu prețul dependenței de ciclul de viață al tabelelor aplicației VPN și de un set de marcaje pe care documentația ei le poate schimba. Un router dedicat pentru rețeaua din aval elimină complet acea dependență: subrețeaua are propria legătură în amonte, iar stația de lucru rămâne un client fără rol de transmitere.

Alegeți al doilea când rețeaua din aval trebuie să funcționeze în continuare prin actualizările VPN, sau când nimeni nu poate testa politica integrată după fiecare versiune. Alegeți primul doar când integrarea este documentată și cineva răspunde de ea.

Verificați granița în patru stări: conectat, reconectare, blocat intenționat și oprit. Verificați rezolvarea numelor și ambele familii de adrese în fiecare, pentru că o ocolire care scurge DNS nu este excluderea pe care ați proiectat-o. Testul trebuie să dovedească granița exactă, nu doar că s-a încărcat o pagină.