Avertisment AF_INET OpenVPN: revenire inofensivă sau socket eșuat?

Două linii din jurnalul OpenVPN încep cu aceleași cuvinte, și doar una dintre ele raportează o problemă. Could not determine IPv4/IPv6 protocol. Using AF_INET este un anunț de revenire: profilul a lăsat familia de adrese deschisă, așa că demonul a ales una și a continuat. Ramura de eșec raportează că nu s-a creat niciun socket și cere o repornire. Tot ce urmează după prefixul comun le separă, așa că citiți mai departe înainte de a schimba ceva.

Ce raportează anunțul de revenire

OpenVPN acceptă o familie explicită prin proto udp4 sau proto udp6, și acceptă proto udp atunci când familia trebuie derivată la pornire. În al doilea caz demonul inspectează informațiile locale de legare și alege.

Când acea derivare funcționează, avertismentul indică direcția urmată și procesul continuă crearea socketului. Un server cu proto udp pe o gazdă cu stivă dublă ajunge astfel pe IPv4 destul de des. Nimic de pe acea cale nu este o eroare, și nimic din ea nu sugerează un atac, un server web lipsă sau un cont respins. Linia este utilă doar pentru că verificările ulterioare ar trebui comparate cu familia pe care o numește.

Tratați-o ca pe un răspuns la o singură întrebare, nu ca pe un diagnostic. Spune ce familie a ales acest proces, și nimic despre de ce un client nu se poate conecta.

Cum arată ramura de eșec

Mai târziu în același cod de socket există o ramură în care nu există niciun socket. Înregistrează mesajul mai scurt despre familia de adrese și cere o repornire, pentru că nu a mai rămas nimic cu care să continue. Cuvintele de început corespund revenirii; rezultatul nu.

Distingeți-le după ceea ce urmează. Dacă demonul continuă să ruleze și își raportează ascultătorul, linia era informație. Dacă iese sau repornește în buclă, discuția este acum despre legare.

Nici o potrivire din grep nu identifică ramura. Expresia apare în rezumate rotite, în linii rupte și în extrase de jurnal pe care oamenii le lipesc din a doua mână, așa că citiți liniile vecine și ordinea momentelor de timp, nu potrivirea unică.

Verificați ascultătorul, nu avertismentul

Un server care rulează răspunde direct la întrebarea despre familie, fără inferențe din textul jurnalului.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Potriviți familia, adresa și portul cu profilul. O linie 0.0.0.0:1194 este doar IPv4, în timp ce o linie [::]:1194 pe o gazdă cu stivă dublă poate accepta ambele familii în funcție de setarea bindv6only. Dacă profilul spune udp și socketul este IPv4, clienții al căror resolver returnează doar o înregistrare AAAA vor eșua înainte ca tunelul să fie măcar negociat.

Apoi testați de la un client asemănător utilizatorilor dvs.: aceeași cale a resolverului, același tip de rețea. O conexiune locală de la server dovedește foarte puțin despre traficul care traversează un dispozitiv NAT sau o regulă de firewall scrisă pentru cealaltă familie.

Când forțarea unei familii este corectă

Fixarea proto udp4 se potrivește unei implementări doar IPv4: un nume DNS doar A, reguli de firewall pentru o adresă v4, clienți în spatele operatorilor care oferă doar adrese v4. Elimină ambiguitatea și face următorul set de linii de jurnal previzibil.

Același argument funcționează invers pentru un mediu cu IPv6 pe primul loc, iar udp6 în fața unei baze de clienți doar A este o întrerupere auto-provocate. Forțarea unei familii doar pentru a reduce la tăcere un avertisment inofensiv este versiunea clasică a acestei greșeli, pentru că ați schimbat cine se poate conecta în schimbul unui jurnal mai liniștit.

Alegeți pe baza punctelor finale și a clienților care trebuie să le atingă. Manualul OpenVPN 2.6 documentează formele de transport, iar mesajul este rezultatul acelei alegeri, nu o intrare.

Păstrați evidența îngustă

Notați linia exactă cu marca sa de timp, setarea efectivă de transport din profilul care rulează, socketul așa cum îl raportează nucleul și etapa următoare care a eșuat. Acele patru elemente rezolvă aproape orice întrebare pe care o ridică mesajul, și niciunul nu necesită ghicire despre servicii nelegate. Ele supraviețuiesc și unei predări, ceea ce o captură de ecran a unui grep nu face.

Sugestiile de pachete care vin împreună cu acest avertisment nu au legătură până când o eroare numește un executabil lipsă.

Dacă ifconfig lipsește într-adevăr, demonul spune asta pe nume când un script îl apelează, și asta merită o investigație proprie. Linia AF_INET și un utilitar lipsă sunt eșecuri diferite, iar instalarea de lucruri pentru a vedea dacă avertismentul se schimbă este calea pe care o gazdă curată devine dezordonată.