OpenVPN-Adapter flackert ënner Windows? Kontrolléiert op eng duebel IP

Ënner Windows ass en OpenVPN-Adapter, deen eng Adress hëlt, se erëm fale léisst an dat all puer Sekonnen erëmhëlt, meeschtens keen DHCP-Fehler. Dem Adapter gëtt gesot, eng Adress ze benotzen, op déi schonn eppes Aneres äntwert, dofir markéiert Windows se als onbrauchbar an de Client fänkt vun Ufank un. De Client-Log bleift roueg, well de Konflikt drënner geléist gëtt, bannen an der eege Netzwierkstapp vum Betribssystem.

Dësen Ënnerscheed ass wichteg, well all Feelerbehiewungsschratt, deen op d'Tunnelkonfiguratioun zilt, eng duebel Adress op der Serversäit iwwersäit.

Fänkt mam Windows-Evenementslog un, net mam Client-Log

Windows registréiert Adresskonflikter am Systemlog, mat den Evenements-IDen 4198 an 4199. Den éischten mellt e Konflikt, dee fir eng Adress entdeckt gouf, den zweeten mellt, datt eng Schnëttstell d'Adress net konnt benotzen, mat där se konfiguréiert war. Keen ernimmt OpenVPN, an dat ass genee de Grond, firwat se liicht iwwersi ginn.

Holt déi rezent Evenementer a vergläicht hir Zäitstempel mam Erneierungszyklus vum Adapter: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. E Konflikt all fofzéng Sekonnen entsprécht engem Client, deen déiselwecht Adress géint ee Besëtzer erëm probéiert, deen nach ëmmer dorop äntwert. En eenzelen Konflikt beim Verbannen deit éischter op eng eemoleg Kollisioun hin. Wat och ëmmer, déi nächst Fro ass, wien soss d'Adress hält.

Dräi Arrangementer setzen zwee Hosten op eng Adress

Frot de Server, wien no sengem Verständnis d'Adress hält, a frot duerno d'Netzwierk, wien dorop äntwert. grep -H ifconfig-push /etc/openvpn/ccd/* listet all fest Adress vum Tunnel an dat Zertifikat, zu deem se gehéiert. ip -4 neigh show dev tap0 weist, wat d'Bréck op der zweeter Schicht geléiert huet. Dës zwou Lëschte vergläichen fënnt déi meescht Duplikater a manner wéi enger Minutt.

Dräi Arrangementer erklären bal all: en Agang an client-config-dir fixéiert eng Adress fir zwee Zertifikater, e gebréckte tap-Segment gëtt enger Maschinn eng Adress, déi en aneren Host schonn statesch huet, oder eng al Lease-Datei gëtt eng Adress zeréck, déi en nach verbonnenen Client sech esou virstellt. Den drëtte Fall ass dee geréiststen, well ifconfig-pool-persist bewosst Adressen fir bekannt Clienten erëmbenotzt.

Maacht d'Adress eenzegaarteg, amplaz drëm ze rennen

D'Startreihenfolg entscheet just, wien haut gewënnt, dofir behandelt all Korrektur, déi op der Restartreihenfolg baséiert, als temporär. Gitt all Client seng eege ifconfig-push Linn, oder verdeelt statesch Adressen aus engem Beräich, dee keng Bréck- oder Serverschnëttstell beréiert. Kontrolléiert d'Clientlëscht och op duebel gemeinsam Nimm, well duplicate-cn zwee Sessiounen eng Identitéit an domat eng fest Adress deele léisst. Wann en gebréckte Gerät wierklech eng fest Adress brauch, réckelt et an säin eege Subnetz oder reservéiert se aus dem Pool op enger Plaz, déi de Server festhält.

Läscht d'persist-Datei just nodeems Dir wësst, wéi eng Leasen se hält, soss verdeelt déi nächst Reconnectioun déi selwecht Adressen nach eng Kéier.

Startt an der richteger Reihenfolg nei a bestätegt een eenzege Besëtzer pro Adress

Wendt d'Ännerung als éischt um Server un a verbënnt duerno d'Clienten nei, sou datt all Participante géint de korrigéierte Pool registréiert. Wann Dir d'Clienten als éischt nei start, behalen se Adressen, déi de Server nach ëmmer als besat gesäit. Liest no dem Neistart de Statusfichier a bestätegt, datt all gemeinsamen Numm eemol mat enger Adress erschéngt. Zwee Agäng fir een Numm heesche, datt eng al Sessioun ni zougemaach gouf, net datt de Pool futti ass.

Wann e Client seng Adress nach ëmmer net halen kann, kontrolléiert, ob eng Bréckschnëttstell um selwechten Host se dréit. Eng Bréck, déi eng Adress vun engem Fournisseursgerät geierft huet, äntwert drop mat ARP och wann de VPN-Server déi Adress schonn engem Client ginn huet.

Kuckt iwwer en ganze Erneierungszyklus, ier Dir den Ticket zoumaacht

Eng eenzeg propper Liesung beweist näischt. Kuckt den Adapter op d'mannst zéng Minutten a forcéiert an der Mëtt eng Reconnectioun: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. D'Adress sollt d'Reconnectioun iwwerstoen an an engem favoriséierten Zoustand bleiwen.

Fuert duerno d'Evenementsufro vum éischte Schrëtt nach eng Kéier aus a bestätegt, datt se näischt Neies zréckgëtt. En rouegen Log iwwer eng Reconnectioun ass de Beweis, datt de Konflikt fort ass, während en rouegen Log no enger eenzeger Verbindung just heescht, datt d'Course nach net stattfonnt huet. Testt zum Schluss d'Ressource, fir déi den Tunnel existéiert, well eng Bréck, déi hir Adress verluer huet, e Fournisseurswee kënne briechen, während de VPN selwer gesond ausgesäit.

Schreift de Poolberäich, all fest Adress an den Host, deen se hält, an d'Servernoten. Da fällt de nächste Konflikt a Minutten op, amplaz en halwen Nomëtteg ze brauchen, fir en erëm z'entdecken.