O aplicație legată de o interfață? Calea ei VPN nu este cea implicită

O aplicație de pe mașină iese prin VPN și alta nu, iar ambii utilizatori jură că nu au schimbat nimic. Diferența este adesea o decizie de legare luată de aplicația însăși: un socket legat de un dispozitiv, o adresă sursă aleasă înainte de conexiune sau un spațiu de nume cu propria tabelă de rutare. Fiecare schimbă ce cale se aplică, și niciuna nu apare într-o verificare generică de IP în browser.

Trei legări diferite, trei efecte diferite

Legarea de un dispozitiv și legarea de o adresă sursă sunt operații înrudite cu consecințe diferite. O legare de dispozitiv poate forța traficul să iasă printr-o interfață și poate ocoli căutarea normală a rutei pentru acel socket. Legarea de o adresă sursă trece totuși prin selecția rutei, dar sursa aleasă poate corespunde unei reguli de politică și poate trimite pachetul în altă parte. Distincția sună academic până când o regulă rutează după sursă. Atunci decide totul.

Spațiul de nume de rețea este al treilea caz. Are propriile interfețe și propria tabelă de rutare, așa că o aplicație din interior nu este deloc afectată de valoarea implicită a gazdei. Tratarea tuturor trei ca același lucru produce explicații încrezătoare care nu trec primul test.

Stabiliți ce setează de fapt aplicația

Citiți configurația de rețea a aplicației sau comportamentul ei documentat înainte de a atinge rutele. Dacă expune o alegere de interfață, un câmp de adresă sursă sau o opțiune de spațiu de nume, acea setare este primul lucru de inspectat. Dacă nu, legarea poate fi internă și vizibilă doar prin urmărire sau prin diagnosticele proprii.

Pe Linux, opțiuni de socket precum SO_BINDTODEVICE au domeniu și cerințe de permisiuni documentate, iar un proces fără privilegii poate să nu le poată seta deloc. Această constrângere este un indiciu util: dacă opțiunea nu poate fi aplicată, aplicația probabil nu este sursa diferenței.

Rutarea după politică citește sursa

Când este configurată rutarea după politică, o regulă poate alege o tabelă pe baza sursei pachetului. De aceea un socket care leagă o adresă sursă poate urma o regulă pe care calea implicită nu o atinge niciodată, chiar dacă nicio interfață nu este numită explicit.

Reproduceți căutarea cu aceeași familie de adrese, sursă și spațiu de nume pe care le folosește aplicația. O căutare generică de rută dintr-un shell în spațiul de nume al gazdei răspunde la altă întrebare, iar această nepotrivire este cel mai frecvent motiv pentru care o rută funcțională pare stricată.

Tunel divizat și procese auxiliare

Tunelul divizat pe aplicație adaugă încă un strat. Clientul poate potrivi pachetul sau procesul aplicației, iar un ajutor care își deschide propriul socket este un subiect separat. Un lansator și serviciul său din fundal pot produce conexiuni diferite sub același nume vizibil.

Verificați dacă regula de tunel divizat acoperă procesul care se conectează efectiv. Dacă aplicația se leagă de o anumită interfață, iar clientul VPN potrivește după pachet, cele două decizii pot diferi fără ca vreuna să fie greșită.

Testați calea proprie a aplicației

Rulați o cerere nouă din aplicație după fiecare modificare. Un browser care arată ieșirea dorită nu este o dovadă echivalentă pentru alt program legat de altă interfață, iar conexiunile din cache pot continua să folosească vechea cale mult după ce o setare se schimbă. Închideți sesiunea veche înainte de a judeca noua regulă. Altfel testul măsoară trecutul.

Referința pentru socketuri Linux documentează SO_BINDTODEVICE și cerințele sale. Citiți mai întâi configurația aplicației înseși, reproduceți căutarea în același context și abia apoi decideți dacă ruta sau legarea trebuie schimbată.