MULTI: adresă sursă greșită de la client: a cui era această adresă?

Jurnalul serverului afișează MULTI: bad source address from client, renunță la pachet, iar sesiunea rămâne conectată. Această combinație îi derutează pe cei care citesc mesajul ca pe o autentificare eșuată. Nu este: clientul s-a autentificat, iar pachetul sosit purta o adresă sursă internă pe care serverul nu a putut-o asocia cu acea instanță a clientului. Verificarea are loc înainte de livrare, de aceea tunelul pare sănătos în timp ce nimic util nu trece prin el.

Ce compară serverul înainte de livrare

Pentru fiecare pachet care sosește de la un client, serverul din spațiul utilizator se uită la adresa sursă din interiorul tunelului și întreabă starea sa internă de rutare cărui client îi aparține adresa. Dacă proprietarul este o altă instanță sau nu există niciun proprietar, pachetul este eliminat și avertismentul este emis.

Livrarea obișnuită prin interfața tunelului nu are loc niciodată.

Această ordine explică un detaliu care îi nedumerește pe oameni: contoarele firewall-ului gazdei nu se mișcă, pentru că pachetul nu a ajuns niciodată la firewall. Ajustarea filtrării căii inverse pe gazdă nu schimbă nimic aici, deoarece respingerea a avut loc în verificarea de asociere a demonului însuși. Citiți mesajul ca pe o afirmație despre proprietate, apoi aflați care dintre cele trei situații l-a produs.

Trei surse ale unei adrese interne care nu se potrivește

Clientul poate trimite de la o adresă care nu i-a fost alocată, dintr-o rețea pe care nimeni nu a declarat-o a sa, sau dintr-o copie a unei identități care are deja proprietar. Toate trei produc aceeași linie de jurnal. Ele diferă prin ceea ce trebuie să schimbați. Începeți cu adresa și lista de alocări curente și lăsați cele două fapte să aleagă cazul.

Distingerea lor cere două fapte: adresa respinsă din jurnal și alocările pe care serverul le consideră curente. Al doilea este disponibil din vizualizarea de stare sau de administrare a instanței care rulează și este singura autoritate pe care merită să o consultați, deoarece un fișier de configurare înregistrează intenții, nu starea prezentă.

Notați ambele înainte de a schimba ceva, apoi clasificați. O captură de ecran făcută după aceea nu este o înregistrare a stării care a produs avertismentul. Păstrați și marca temporală, deoarece alocările se mută între sesiuni.

LAN-ul din spatele unui client și iroute

Când un client de sediu își rutează propria rețea privată, acea rețea trebuie declarată ca aparținând clientului. Un fișier specific clientului cu o intrare iroute face asta, iar intrarea numește prefixul pe care clientul are voie să îl transporte.

O rută de kernel care îndreaptă același prefix către tunel este o cerință separată, iar adăugarea ei nu schimbă nimic din proprietatea internă a demonului.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Confirmați că identitatea efectivă corespunde numelui fișierului, deoarece o nepotrivire înseamnă că fișierul nu se încarcă niciodată și simptomul este identic cu o intrare lipsă. Nu adăugați un iroute larg pentru a reduce la tăcere avertismentul, deoarece aceasta transformă o sursă neașteptată într-una autorizată fără a răspunde de ce clientul a trimis-o. Manualul OpenVPN 2.6 documentează iroute, duplicate-cn și maparea identității ca mecanisme de control separate.

Aceeași identitate pe două mașini

Un profil copiat pe un al doilea laptop poartă același certificat și același nume comun. În funcție de setările serverului, conexiunea mai nouă o poate înlocui pe cea mai veche, iar verificarea de asociere o câștigă instanța care deține proprietatea.

Asta face ca defectul să pară intermitent și să apară doar când ambele dispozitive sunt treze.

Permiterea numelor comune duplicate le lasă pe ambele să se conecteze, dar nu le oferă adrese statice independente sau proprietate independentă. Dacă două dispozitive trebuie să coexiste, înregistrați-le separat, astfel încât fiecare să aibă propria identitate și propria alocare. Tratarea setării de duplicare ca reparație pentru acest avertisment lasă misterul pe loc și adaugă un al doilea.

Dovediți că asocierea s-a schimbat

Aplicați corecția prin proprietarul configurației, apoi reconectați clientul afectat pentru ca noua politică să se încarce.

Repetați același flux și confirmați trei lucruri: sursa internă a pachetului, instanța clientului cu care serverul îl asociază și comportamentul destinației după aceea.

Dacă avertismentul se oprește, dar aplicația tot eșuează, problema s-a mutat în loc să dispară. Redirecționarea, regulile de firewall și calea de întoarcere sunt etape separate, iar trecerea verificării de asociere înseamnă doar că pachetului i s-a permis să părăsească tunelul.