Cererile părăsesc mașina, partenerul VPN răspunde, iar răspunsul nu ajunge niciodată la socket. Tunelul este activ, jurnalele partenerului arată că pachetul este trimis, și nimic din aplicație nu explică tăcerea. Pe Linux unul dintre suspecții obișnuiți este filtrarea căii inverse: un pachet IPv4 care sosește poate fi respins când validarea sursei nu se potrivește cu ruta pe care nucleul o așteaptă pentru acea sursă. Parcurgerea în ordine vă spune dacă aceasta este cauza sau o coincidență. De asemenea, vă împiedică să dezactivați un control de securitate pentru a repara o rută lipsă.

Ce decide validarea sursei

Nucleul verifică dacă adresa sursă a unui pachet este plauzibilă pentru interfața pe care a sosit, consultând tabelul de rutare pentru o rută înapoi la acea sursă. Dacă ruta inversă indică în altă parte, pachetul poate fi aruncat înainte ca vreo regulă de firewall sau vreun socket al aplicației să îl vadă. Acea verificare există pentru a face anumite tipare de falsificare mai dificile, și de aceea proiectele asimetrice și cele rutate pe politică se lovesc de ea, în timp ce orice client obișnuit din aceeași rețea funcționează bine. Clienții obișnuiți au rutare simetrică, exact ceea ce presupune verificarea.

Cuvântul important este plauzibilă. Pachetul poate fi perfect legitim și totuși poate eșua verificarea, pentru că nu legitimitatea este testată.

Citiți modul efectiv, nu un singur câmp

Există trei moduri: dezactivat, strict și relaxat. Cel strict impune o așteptare de rută diferită de cel relaxat, iar setarea globală interacționează cu cele pentru fiecare interfață, așa că citirea unui singur fișier poate descrie greșit ce este efectiv în vigoare. Citiți-le pe amândouă, și citiți-le pe interfața care primește răspunsul, nu pe cea a rutei implicite.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Căutarea rutei din a treia linie este partea pe care oamenii o sar. Ea vă spune ce crede nucleul despre sursă, și exact aceasta este intrarea verificării.

Găsiți nepotrivirea înainte de a schimba verificarea

Aflați de ce răspunsul sosește pe acea interfață și dacă ruta sa inversă ar trebui să fie diferită. O regulă de politică ce trimite cererile pe o cale în timp ce răspunsurile se întorc pe alta este un proiect legitim, și tot acel proiect este respins de validarea strictă. Marcajele folosite în rutarea pe politică pot conta și aici, pentru că schimbă ce returnează căutarea inversă.

Dacă ruta inversă pur și simplu lipsește, adăugarea ei repară cauza în loc să dezactiveze o verificare. O rută lipsă, o respingere a firewall-ului și un selector de trafic greșit produc același simptom vizibil, și doar unul dintre ele ține de validarea sursei.

Nu dezactivați global verificările sursei ca primă reacție. Asta schimbă un diagnostic concret cu o modificare largă de comportament pe care va trebui să o țineți minte mai târziu.

O ajustare selectivă pe care o puteți apăra

Dacă o ajustare îngustă este cu adevărat necesară, limitați-o la interfața care are nevoie de ea, notați de ce, și puneți-o în configurația care deține acea interfață ca să supraviețuiască unei reporniri. Apoi retestați exact fluxul care a eșuat, de la aceeași sursă la aceeași destinație, în loc de un ping către ceva comod.

Includeți un caz care ar trebui să fie în continuare refuzat. Dacă acel caz reușește acum, ajustarea a slăbit mai mult decât singura cale pe care voiați să o reparați.

Țineți IPv4 și IPv6 separate

Un sysctl care arată familiar nu este o politică pentru fiecare familie de adrese. IPv6 are propriul comportament și propriile setări, iar o mașină poate fi strictă pe o familie și permisivă pe cealaltă fără ca nimeni să observe până când o destinație anume eșuează. Verificați ambele dacă volumul de lucru le folosește pe amândouă.

Înregistrați modul, interfața, ieșirea căutării rutei și motivul modificării într-un singur loc. Următoarea persoană va găsi setarea și nicio explicație, și fie o va elimina, fie o va copia unde nu îi este locul.

Articole similare