OpenVPN-adapter flikkert op Windows? Kontrolearje op in dûbele IP
In flikkerjende Windows-adapter is faak in adreskonflikt, net in stjoerderbug. Lês de barrens 4198 en 4199, fyn de twadde eigner, en fêstigje dan unike adressen.
Op Windows is in OpenVPN-adapter dy't in adres nimt, it wer loslit en dat elke pear sekonden werhellet, meastentiids gjin DHCP-bug. Tsjin de adapter wurdt sein dat er in adres brûke moat dêr't al wat oars op antwurdet, sadat Windows it as net brûkber markearret en de klant op 'e nij begjint. It klantlogg bliuwt stil om't it konflikt derûnder oplost wurdt, binnen de eigen netwurkstapel fan it bestjoeringssysteem.
Dat ferskil is fan belang, want elke probleemoplossingsstap rjochte op de tunnelkonfiguraasje sil in dûbel adres oan de serverkant misse.
Begjin mei it Windows-barrenslogboek, net mei it klantloch
Windows registrearret adreskonflikten yn it systeemlogboek, mei barren-ID's 4198 en 4199. De earste rapportearret in konflikt dat foar in adres fûn is, de twadde rapportearret dat in ynterface it adres net brûke koe dêr't it mei konfigurearre wie. Gjin fan beide neamt OpenVPN, en krekt dêrom wurde se maklik oersjoen.
Hielje de resinte barrens op en fergelykje har tiidstimpels mei de fernijingssyklus fan de adapter: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. In konflikt elke fyftjin sekonden past by in klant dy't itselde adres op 'e nij besiket tsjin in eigner dy't der op trochgiet te antwurdzjen. In inkeld konflikt by ferbiningstijd wiist earder op in ienmalige botsing. Yn beide gefallen is de folgjende fraach wa't it adres noch hat.
Trije opstellings sette twa hosts op ien adres
Freegje de server wa't neffens him it adres hat, en freegje dan it netwurk wa't derop antwurdet. grep -H ifconfig-push /etc/openvpn/ccd/* listet elk fêstset tunneladres en it sertifikaat dêr't it by heart. ip -4 neigh show dev tap0 lit sjen wat de brêge op 'e twadde laach leard hat. It fergelykjen fan dy twa listen fynt de measte dûbelingen yn minder as in minút.
Trije opstellings ferklearje hast alle gefallen: in ynfier yn client-config-dir fêstiget ien adres foar twa sertifikaten, in oerbrêge tap-segment jout in masine in adres dat in oare host al statysk hat, of in ferâldere lease-bestân jout in adres werom dat in noch ferbûn klant mient te besitten. It tredde gefal is it ferriederlikst, om't ifconfig-pool-persist bewust adressen werbrûkt foar bekende klanten.
Meitsje it adres unyk ynstee fan derom te wedstriiden
De opstartfolchoarder bepaalt allinnich wa't hjoed wint, behannelje dêrom elke repartaasje basearre op de werstartfolchoarder as tydlik. Jou elke klant syn eigen ifconfig-push-rigel, of wize statyske adressen ta út in berik dat gjin brêge- of serverynterface rekket. Kontrolearje de klantlist ek op dûbele mienskiplike nammen, want duplicate-cn lit twa sesjes ien identiteit diele en dêrom ien fêstset adres. As in oerbrêge apparaat echt in fêst adres nedich hat, ferpleatse it dan nei syn eigen subnet of reservearje it út 'e pool op in plak dat de server fêstleit.
Wiskje it persist-bestân pas neidat jo witte hokker leases it hâldt, oars dielt de folgjende werferbining deselde adressen wer út.
Werstarte yn 'e goede folchoarder en befêstigje ien eigner per adres
Pas de wiziging earst op 'e server ta en ferbyn dan de klanten op 'e nij, sadat elke dielnimmer him tsjin 'e korrizjearre pool registrearret. As jo de klanten earst werstarte, hâlde se adressen dy't de server noch altyd as beset beskôget. Lês nei de werstart it statusbestân en befêstigje dat elke mienskiplike namme ien kear mei ien adres ferskynt. Twa ynfieringen foar ien namme betsjutte dat in âlde sesje nea slein is, net dat de pool stikken is.
As in klant syn adres noch net hâlde kin, kontrolearje dan oft in brêge-ynterface op deselde host it draacht. In brêge dy't in adres fan in leveransiersapparaat erfd hat, sil der ARP op antwurdzje sels as de VPN-server dat adres al oan in klant jûn hat.
Sjoch in folsleine fernijingssyklus lâns foardat jo it ticket slute
Ien skjinne lêzing bewiist neat. Sjoch de adapter op syn minst tsien minuten lâns en twingje healwei in werferbining ôf: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. It adres heart de werferbining te oerlibjen en yn in foarkarstastân te bliuwen.
Fier dan de barrensfraach fan 'e earste stap op 'e nij út en befêstigje dat dy neat nijs weromjout. In stil logboek oer in werferbining hinne is it bewiis dat it konflikt fuort is, wylst in stil logboek nei ien ferbining allinnich betsjut dat de wedstriid noch net barde is. Test as lêste de boarne dêr't de tunnel foar bestiet, want in brêge dy't syn adres ferlern hat, kin in leveransierspaad brekke wylst de VPN sels sûn liket.
Skriuw it poolberik, elk fêstset adres en de host dy't it hat yn 'e servernotysjes. Dan is de folgjende botsing yn in pear minuten te sjen ynstee fan in hiele middei om wer te ûntdekken.