Același IP de server, două căi: marcarea fluxului exterior al OpenVPN

Protecția obișnuită împotriva buclei este o rută de host: trimite traficul către adresa publică a serverului VPN pe uplink, astfel încât sesiunea criptată să nu intre niciodată în propriul tunel. Asta funcționează exact până în momentul în care vrei să ajungi și la un serviciu web pe același server prin tunel, pentru că excepția este legată de destinație, iar destinația este identică. Ieșirea este să nu mai clasifici după destinație și să începi să clasifici după ce socket a trimis pachetul.

Începe cu cele două fluxuri pe care vrei să le separi

Un flux este transportul OpenVPN criptat propriu-zis, care trebuie să iasă pe uplink, altfel tunelul ar purta propria conexiune exterioară. Celălalt este o cerere HTTPS obișnuită către aceeași adresă publică, pe care o vrei în interiorul tunelului ca să ajungă la serviciu dintr-o sursă de tunel. Aceeași destinație, în multe cazuri același număr de port, cale necesară diferită.

Pentru acest parcurs, presupune un client pe 10.90.0.10 prin tun1, o adresă publică de server de 198.51.100.25 și o tabelă principală neatinsă a cărei rută implicită indică uplink-ul obișnuit. Partea de server trebuie să accepte și serviciul web pe calea interioară și să trimită traficul înapoi la sursa tunelului; trimiterea unui pachet către o adresă publică nu anulează listenerul sau politica de firewall a serverului.

Înainte de a schimba ceva, consemnează regulile actuale ale hostului și alege valori pe care nu le folosește nimeni altcineva: o marcă, un număr de tabelă și trei priorități de regulă. Păstrează o cale de întoarcere în mașină care nu trece prin această conexiune, pentru că o greșeală aici îți elimină propriul acces la distanță, nu doar strică o filă de browser.

Marchează socketul care poartă plicul

Configurația clientului primește o marcă pentru pachetele sale criptate de ieșire și nu mai instalează singură rute, astfel încât politica de înlocuire să fie singura care decide căile:

mark 42
route-noexec
disable-dco

Zecimalul 42 este hexazecimalul 0x2a, iar forma hexazecimală este cea cu care se vor potrivi regulile de rutare. Referința pentru link-options descrie mark ca aplicându-se pachetelor criptate de ieșire pe Linux, adică exact socketului a cărui cale trebuie s-o controlezi. Dezactivarea offload-ului canalului de date menține acest exemplu pe calea spațiului utilizator, unde comportamentul mărcii este cel descris.

route-noexec suprimă adăugările și eliminările automate de rute ale OpenVPN. Nu instalează nimic în locul lor, așa că din acest moment proprietarul rutelor trebuie să întrețină fiecare rută de care are nevoie tunelul. Dacă o destinație privată dispare după schimbare, aceea este politica de înlocuire lipsă, nu un defect al mărcii.

Nu păstra o rută de host în tabela principală pentru 198.51.100.25 în timp ce faci asta. O astfel de rută reintroduce exact excepția pe care designul încearcă să o restrângă și va câștiga pentru fluxul HTTPS înainte ca vreuna dintre politicile de mai jos să fie consultată.

Trimite tot restul către tabela tunelului

Odată ce interfața tunelului există și are adresa ei, politica arată astfel:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Prima regulă păstrează vizibile rutele specifice ale hostului, inclusiv orice rețea locală aprobată, făcând în același timp invizibilă ruta implicită a tabelei principale pentru această căutare. Distincția contează: suprimarea rutei implicite nu este același lucru cu ignorarea tabelei, iar excepțiile locale de care ai încă nevoie supraviețuiesc exact datorită ei. Citește acele excepții una câte una în loc să presupui că rezultatul este un întrerupător universal.

Traficul nemarcat cade apoi în tabela tunelului, preia sursa tunelului și iese prin VPN. Traficul marcat eșuează la testul fwmark pe următoarele două reguli și continuă către căutarea principală obișnuită mai jos în listă, unde ruta implicită a uplink-ului încă se află. Regula unreachable finală este cea care împiedică un flux nemarcat să cadă în tăcere înapoi pe uplink atunci când ruta tunelului lipsește. Selectorul este marca de la început până la sfârșit, iar adresa de destinație nu intră niciodată în decizie.

Păstrează garda respectivă în loc între deconectări și instaleaz-o împreună cu restul politicii, nu manual. O regulă care dispare odată cu interfața nu este o politică, ci o coincidență. Ștergerea politicii când cade tunelul schimbă modul de eșec din „blocat” în „scurs”, iar o rută de tunel învechită care expiră mai târziu este o problemă mult mai ușor de explicat decât traficul care a ieșit prin interfața greșită.

Fă calea de întoarcere să vadă aceeași marcă

Mărcile de ieșire sunt doar jumătate din mecanism, iar aceasta este partea pe care majoritatea reproducerilor o omit. Răspunsurile la sesiunea criptată sosesc pe uplink și sunt supuse validării căii de întoarcere, care întreabă dacă sursa ar fi rutată înapoi pe același drum pe care a venit. Fără ajutor, acea căutare aplică politica ta de tunel nemarcată și concluzionează că pachetul este pe interfața greșită.

Corectura aparține proprietarului firewall-ului: salvează marca pe conexiunea de ieșire, restaurează-o pe pachetele de intrare corespunzătoare și activează tratarea marcajelor validate de sursă pentru calea relevantă. Faptul că OpenVPN setează o marcă de socket nu face niciunul dintre aceste trei lucruri, iar o rețetă care listează doar opțiunile clientului este incompletă. Cere acea integrare în scris, pentru că este partea cea mai puțin vizibilă a designului și cea mai ușor de pierdut la o reconstrucție.

Nici verificarea laxă a căii de întoarcere nu este un substitut. Modul lax are în continuare nevoie de o rută pentru sursă, iar garda unreachable pe care ai adăugat-o elimină deliberat una pentru căutările nemarcate. Fă integrarea mărcii de conexiune finalizată și revizuită înainte de a te baza pe acest design și tratează filtrele de host ca o chestiune separată: o marcă este un semnal de rutare, nu o permisiune. Dacă integrarea lipsește, simptomul este o sesiune care se stabilește și apoi devine tăcută de îndată ce încep să sosească răspunsuri.

Demonstrează cu două căutări de rută

Compară ce decide nucleul pentru cele două contexte și citește câmpurile dev și src în locul stării de ieșire:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Prima căutare ar trebui să se rezolve la tun1 cu sursa tunelului, iar a doua la uplink. Sunt căutări sintetice, deci dovedesc politica, nu procesul activ: confirmă separat calea de transport reală a clientului aflat în execuție, apoi fă o cerere HTTPS reală cu verificarea certificatelor activată.

Notează ce nu acoperă designul înainte de a-l declara terminat. DNS, IPv6 și ciclul de viață al regulilor au nevoie fiecare de propria decizie, iar acesta este un exemplu de rutare IPv4, nu o configurație completă de confidențialitate. Valoarea lui este selectorul: plicul primește excepția uplink-ului, iar un serviciu obișnuit la aceeași adresă nu trebuie s-o moștenească.