Adaptorul OpenVPN clipește pe Windows? Verificați un IP duplicat

Pe Windows, un adaptor OpenVPN care ia o adresă, o abandonă și repetă acest lucru la fiecare câteva secunde de obicei nu este o eroare DHCP. Adaptorului i se spune să folosească o adresă la care răspunde deja altceva, așa că Windows o marchează ca inutilizabilă și clientul o ia de la capăt. Jurnalul clientului rămâne liniștit pentru că conflictul se rezolvă dedesubt, în stiva de rețea a sistemului de operare.

Această distincție contează, pentru că fiecare pas de depanare îndreptat spre configurația tunelului va rata o adresă duplicată pe partea de server.

Începeți cu jurnalul de evenimente Windows, nu cu jurnalul clientului

Windows înregistrează conflictele de adrese în jurnalul de sistem, cu ID-urile de eveniment 4198 și 4199. Primul raportează un conflict detectat pentru o adresă, al doilea raportează că o interfață nu a putut folosi adresa cu care era configurată. Niciunul nu menționează OpenVPN, și exact de aceea sunt ușor de trecut cu vederea.

Extrageți evenimentele recente și comparați marcajele lor de timp cu ciclul de reînnoire al adaptorului: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflict la fiecare cincisprezece secunde corespunde unui client care reîncearcă aceeași adresă împotriva unui proprietar care continuă să răspundă pentru ea. Un singur conflict la momentul conectării indică mai degrabă o coliziune punctuală. În orice caz, următoarea întrebare este cine mai deține adresa.

Trei aranjamente pun două gazde pe o singură adresă

Întrebați serverul cine crede că deține adresa, apoi întrebați rețeaua cine răspunde pentru ea. grep -H ifconfig-push /etc/openvpn/ccd/* listează fiecare adresă de tunel fixată și certificatul căreia îi aparține. ip -4 neigh show dev tap0 arată ce a învățat puntea la al doilea nivel. Compararea acestor două liste găsește majoritatea duplicatelor în mai puțin de un minut.

Trei aranjamente explică aproape toate: o intrare în client-config-dir fixează o adresă pentru două certificate, un segment tap punte oferă unei mașini o adresă pe care o altă gazdă o are deja static, sau un fișier de lease învechit returnează o adresă pe care un client încă conectat crede că o deține. Al treilea caz este cel mai viclean, pentru că ifconfig-pool-persist refolosește în mod deliberat adrese pentru clienți cunoscuți.

Faceți adresa unică în loc să concurați pentru ea

Ordinea de pornire decide doar cine câștigă astăzi, așa că tratați ca temporară orice corectare bazată pe secvența de repornire. Dați fiecărui client propria linie ifconfig-push, sau alocați adrese statice dintr-un interval pe care nu îl atinge nicio interfață de punte sau de server. Verificați și lista de clienți pentru nume comune duplicate, pentru că duplicate-cn permite ca două sesiuni să împartă o identitate și deci o adresă fixată. Dacă un dispozitiv punte are într-adevăr nevoie de o adresă fixă, mutați-l în propria subrețea sau rezervați-o din grupul de adrese într-un loc pe care serverul îl înregistrează.

Ștergeți fișierul persist doar după ce știți ce lease-uri conține, altfel următoarea reconectare va distribui din nou aceleași adrese.

Reporniți în ordinea corectă și confirmați un singur proprietar pe adresă

Aplicați schimbarea mai întâi pe server, apoi reconectați clienții, astfel încât fiecare participant să se înregistreze față de grupul corectat. Dacă reporniți clienții primii, aceștia rămân cu adrese pe care serverul le consideră încă ocupate. După repornire, citiți fișierul de stare și confirmați că fiecare nume comun apare o dată cu o adresă. Două intrări pentru un nume înseamnă că o sesiune veche nu s-a închis niciodată, nu că grupul este stricat.

Dacă un client tot nu își poate păstra adresa, verificați dacă o interfață de punte de pe aceeași gazdă o poartă. O punte care a moștenit o adresă de la un dispozitiv al furnizorului va răspunde la ARP pentru ea chiar și atunci când serverul VPN a dat deja acea adresă unui client.

Urmăriți un ciclu complet de reînnoire înainte de a închide tichetul

O singură citire curată nu dovedește nimic. Urmăriți adaptorul cel puțin zece minute și forțați o reconectare la mijloc: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresa ar trebui să supraviețuiască reconectării și să rămână într-o stare preferată.

Apoi rulați din nou interogarea de evenimente din primul pas și confirmați că nu returnează nimic nou. Un jurnal liniștit de-a lungul unei reconectări este dovada că conflictul a dispărut, în timp ce un jurnal liniștit după o singură conectare înseamnă doar că cursa nu a avut loc încă. În final, testați resursa pentru care există tunelul, pentru că o punte care și-a pierdut adresa poate rupe o cale a furnizorului în timp ce VPN-ul în sine pare sănătos.

Notați intervalul grupului, fiecare adresă fixată și gazda care o deține în notele serverului. Atunci următoarea coliziune se observă în câteva minute, în loc să fie nevoie de o după-amiază întreagă pentru a o redescoperi.