OpenVPN-adapter wat op Windows flikker? Kyk vir 'n duplikaat-IP

Op Windows is 'n OpenVPN-adapter wat 'n adres neem, dit laat vaar en dit elke paar sekondes herhaal, gewoonlik nie 'n DHCP-fout nie. Die adapter word aangesê om 'n adres te gebruik waarvoor iets anders reeds antwoord, so Windows merk dit as onbruikbaar en die kliënt begin oor. Die kliëntlog bly stil omdat die konflik onder dit opgelos word, binne die bedryfstelsel se eie netwerkstapel.

Daardie onderskeid maak saak, want elke foutsoekstap wat op die tonnelkonfigurasie gemik is, sal 'n duplikaatadres aan die bedienerkant miskyk.

Begin by die Windows-gebeurtenislog, nie die kliëntlog nie

Windows teken adreskonflikte in die Stelsellog aan, met gebeurtenis-ID's 4198 en 4199. Die eerste rapporteer 'n konflik wat vir 'n adres opgespoor is, die tweede rapporteer dat 'n koppelvlak nie die adres kon gebruik waarmee dit opgestel is nie. Nie een noem OpenVPN nie, en dit is juis waarom hulle maklik oor die hoof gesien word.

Haal die onlangse gebeure en vergelyk hulle tydstempele met die adapter se hernuwingsiklus: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. 'n Konflik elke vyftien sekondes pas by 'n kliënt wat dieselfde adres probeer teenoor 'n eienaar wat aanhou daarop antwoord. 'n Enkele konflik by verbindingstyd dui eerder op 'n eenmalige botsing. In beide gevalle is die volgende vraag wie anders die adres hou.

Drie reëlings plaas twee gashere op een adres

Vra die bediener wie hy dink die adres hou, en vra dan die netwerk wie daarvoor antwoord. grep -H ifconfig-push /etc/openvpn/ccd/* lys elke vasgepen tonneladres en die sertifikaat waaraan dit behoort. ip -4 neigh show dev tap0 wys wat die brug op laag twee geleer het. Deur daardie twee lyste te vergelyk, word die meeste duplikate in minder as 'n minuut gevind.

Drie reëlings verantwoord vir byna almal: 'n client-config-dir-inskrywing pen een adres vir twee sertifikate vas, 'n oorbrugde tap-segment gee 'n masjien 'n adres wat 'n ander gasheer reeds staties het, of 'n verouderde huurlêer gee 'n adres terug wat 'n kliënt wat nog verbind is, dink hy besit. Die derde geval is die verraderlikste, want ifconfig-pool-persist hergebruik doelbewus adresse vir bekende kliënte.

Maak die adres uniek in plaas daarvan om daarvoor te jaag

Die opstartvolgorde bepaal net wie vandag wen, so beskou enige oplossing wat op die herbeginvolgorde berus as tydelik. Gee elke kliënt sy eie ifconfig-push-reël, of ken statiese adresse toe uit 'n reeks wat geen brug- of bedienerkoppelvlak raak nie. Gaan die kliëntlys ook na vir duplikaat-common names, want duplicate-cn laat twee sessies een identiteit deel en dus een vasgepen adres. As 'n oorbrugde toestel werklik 'n vaste adres nodig het, skuif dit na sy eie subnet of reserveer dit uit die poel op 'n plek wat die bediener aanteken.

Vee die persist-lêer eers uit nadat jy weet watter huurkontrakte dit hou, anders sal die volgende herverbinding dieselfde adresse weer uitgee.

Herbegin in die regte volgorde en bevestig een eienaar per adres

Pas die verandering eers op die bediener toe en verbind dan die kliënte weer, sodat elke deelnemer teen die gekorrigeerde poel registreer. As jy die kliënte eerste herbegin, bly hulle adresse hou wat die bediener nog as beset beskou. Lees ná die herbegin die statuslêer en bevestig dat elke common name een keer met een adres verskyn. Twee inskrywings vir een naam beteken dat 'n ou sessie nooit toegemaak is nie, nie dat die poel stukkend is nie.

As 'n kliënt steeds nie sy adres kan behou nie, kyk of 'n brugkoppelvlak op dieselfde gasheer dit dra. 'n Brug wat 'n adres van 'n verskafferstoestel geërf het, sal ARP daarvoor antwoord selfs wanneer die VPN-bediener daardie adres aan 'n kliënt gegee het.

Hou dop oor 'n volle hernuwingsiklus voordat jy die kaartjie sluit

Een skoon lesing bewys niks. Hou die adapter minstens tien minute dop en forseer 'n herverbinding in die middel: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Die adres behoort die herverbinding te oorleef en in 'n voorkeurtoestand te bly.

Voer dan die gebeurtenisnavraag van die eerste stap weer uit en bevestig dat dit niks nuuts teruggee. 'n Stil log oor 'n herverbinding is die bewys dat die konflik weg is, terwyl 'n stil log ná 'n enkele verbinding net beteken die wedloop het nog nie gebeur nie. Toets laastens die hulpbron waarvoor die tonnel bestaan, want 'n brug wat sy adres verloor het, kan 'n verskafferpad breek terwyl die VPN self gesond lyk.

Teken die poelreeks, elke vasgepen adres en die gasheer wat dit besit in die bediener se notas aan. Die volgende botsing neem dan minute om raak te sien in plaas van 'n middag om weer te ontdek.