De ce un răspuns UDP OpenVPN pleacă de la adresa greșită

Un client OpenVPN apelează o adresă, serverul răspunde de la alta, iar tunelul nu se ridică niciodată. Jurnalul serverului arată pachetul sosit, iar o captură arată răspunsul plecând, așa că eroarea este pusă pe seama clientului. Pe o gazdă cu mai multe interfețe, sau cu mai multe adrese pe o singură interfață, cele două părți pur și simplu nu sunt de acord asupra adresei folosite. Răspunsul este valid la nivel IP, totuși mulți clienți elimină un datagram a cărui sursă nu este adresa pe care au contactat-o.

Ce vede clientul când se schimbă sursa

Un soclu UDP care nu este legat de o anumită adresă locală nu are o sursă fixă, așa că nucleul alege una la trimitere. Alegerea provine dintr-o căutare de rută spre adresa clientului, iar sursa devine adresa interfeței pe care o selectează căutarea. Pe o mașină cu o singură interfață alegerea este invizibilă; pe o gazdă cu o adresă de administrare, o adresă publică și o adresă secundară pe aceeași placă de rețea, depinde de metricile și de politica de rutare. Rutarea bazată pe politici face nepotrivirea mai probabilă, nu mai puțin, pentru că o regulă poate selecta un uplink la care clientul nu a ajuns niciodată. Este suficientă o rută implicită învățată de la un furnizor plus o regulă de sursă care indică altul.

Clienții care filtrează răspunsurile, și urmărirea conexiunilor care așteaptă cvadruplul exact și sursa, vor elimina răspunsul fără un mesaj util. Apoi tunelul expiră ca și cum nimic nu ar fi sosit, și de aceea acest lucru este confundat cu o problemă de firewall pe partea clientului. O captură făcută doar pe server confirmă eroarea în loc să o explice, pentru că răspunsul chiar pleacă. Comparați sursa răspunsului cu adresa apelată de client înainte de a schimba orice altceva.

Ce face de fapt opțiunea multihome

Directiva se scrie ca multihome într-un fișier de configurare și ca --multihome pe linia de comandă, și face ca un server UDP să răspundă de la adresa la care a ajuns pachetul clientului. Nucleul livrează adresa de destinație originală ca date suplimentare la recepție, iar OpenVPN folosește acea valoare ca sursă a răspunsului. Astfel, un server care ascultă pe o adresă universală, local 0.0.0.0 pentru IPv4 sau echivalentul său IPv6, se comportă ca și cum fiecare client ar fi ajuns la un ascultător dedicat. Clienții care au intrat prin adresa publică primesc răspunsuri de la adresa publică, iar clienții de pe o adresă internă le primesc de la aceea. Nimic altceva din calea pachetului nu se mișcă: ruta, regulile de filtrare și configurația tunelului rămân exact cum erau.

Exact această ultimă proprietate face opțiunea sigură de adăugat la un server care altfel funcționează, și tot ea este motivul pentru care nu poate repara un filtru care permite o singură adresă. Pachetul trebuie totuși acceptat pe calea pe care o urmează, deci corecția sursei schimbă originea răspunsului și nimic mai mult. Este și doar pentru UDP: un ascultător TCP nu are această problemă în aceeași formă, pentru că conexiunea este identificată de cvadruplu, nu de adresa sursă a răspunsului.

Când o adresă locală fixă este valoarea implicită greșită

Înainte de a recurge la opțiune, verificați dacă serverul leagă o anumită adresă locală, pentru că un ascultător legat răspunde întotdeauna de la acea adresă. Acest lucru este corect pentru o implementare cu o singură interfață și greșit de îndată ce clienții folosesc în mod legitim mai mult de o adresă. Dacă legarea a fost deliberată, decideți dacă serverul ar trebui să accepte trafic pe adrese suplimentare. Eliminarea legării crește expunerea, așa că interfețele și rețelele sursă permise trebuie impuse de serviciu și de filtru, nu doar de adresa de legare.

Referința OpenVPN limitează opțiunea la serverele UDP, notează procesarea suplimentară din calea pachetului și consemnează ce platforme o suportă. Confirmați acest lucru pe versiunea instalată înainte de a planifica pe baza lui. Unde nu este suportată, alternativa este legarea adresei specifice sau corectarea rutei de întoarcere, iar ambele sunt modificări mai înguste decât par la prima vedere. Ascultarea pe universal are consecințe și dincolo de răspunsuri: un server pe toate adresele este accesibil din fiecare rețea la care este conectat gazda, iar aceasta poate să nu fie expunerea la care s-a gândit cineva.

Dovediți sursa răspunsului din exterior

Testați din exteriorul serverului și consemnați adresa și transportul exacte folosite de client înainte de a captura orice. Cele trei verificări de mai jos răspund la trei întrebări diferite, iar ordinea contează.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Captura arată adresa sursă din răspuns, iar acesta este faptul pe care se sprijină întregul articol. Lista de socluri arată la ce s-a legat de fapt serverul, pentru că un ascultător universal și unul specific arată identic într-un fișier de configurare și se comportă diferit în rețea. Căutarea de rută arată sursa pe care nucleul ar alege-o pentru acel flux, iar aceasta explică captura înainte de a schimba ceva. Repetați toate trei pentru IPv4 și IPv6 separat, pentru că sunt ascultători separați și căutări separate, iar o intrare universală pentru o familie nu spune nimic despre cealaltă.

Rutarea, descoperirea și filtrarea rămân separate

Păstrarea sursei răspunsului nu instalează o rută de ieșire, nu actualizează DNS-ul dinamic și nu face o familie de adrese să o accepte pe cealaltă. Pe un server cu mai multe uplink-uri, calea de întoarcere pentru fiecare sursă trebuie convenită deliberat, altfel răspunsurile pleacă printr-o interfață pe care filtrul clientului nu a permis-o niciodată. La fel, o adresă nouă după o schimbare de prefix trebuie să ajungă la clienți prin descoperire și prin fluxul de reconectare acceptat, nu prin înregistrarea veche.

Lăsați verificările identității serverului și validarea certificatelor exact așa cum sunt, pentru că o adresă schimbată nu justifică acceptarea unui partener neverificat. Dacă răspunsul pleacă acum de la sursa dorită și tunelul tot eșuează, considerați problema sursei rezolvată și mergeți mai departe. Următoarea eroare observată aparține rutării, filtrării sau autentificării, iar o altă schimbare a ascultătorului nu va ajunge la ea. Scrieți sursa răspunsului în tichet lângă adresa apelată de client, ca următoarea persoană să poată verifica același fapt cu o singură comandă.