Përshtatësi OpenVPN në Windows dridhet? Kontrolloni për një IP të dyfishtë

Në Windows, një përshtatës OpenVPN që merr një adresë, e lëshon dhe e përsërit këtë çdo disa sekonda zakonisht nuk është gabim DHCP. Përshtatësit i thuhet të përdorë një adresë të cilës diçka tjetër i përgjigjet tashmë, kështu që Windows e shënon si të papërdorshme dhe klienti fillon nga e para. Regjistri i klientit mbetet i qetë sepse konflikti zgjidhet poshtë tij, brenda vetë stakut të rrjetit të sistemit operativ.

Ky dallim ka rëndësi, sepse çdo hap i zgjidhjes së problemeve i drejtuar nga konfigurimi i tunelit do të humbasë një adresë të dyfishtë në anën e serverit.

Filloni me regjistrin e ngjarjeve të Windows, jo me regjistrin e klientit

Windows regjistron konfliktet e adresave në regjistrin e Sistemit, me ID-të e ngjarjeve 4198 dhe 4199. I pari raporton një konflikt të zbuluar për një adresë, i dyti raporton se një ndërfaqe nuk mundi të përdorte adresën me të cilën ishte konfiguruar. Asnjëri nuk përmend OpenVPN, dhe pikërisht për këtë është e lehtë t'i anashkalosh.

Nxirrni ngjarjet e fundit dhe krahasoni vulat e tyre kohore me ciklin e rinovimit të përshtatësit: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Një konflikt çdo pesëmbëdhjetë sekonda përputhet me një klient që riprovon të njëjtën adresë ndaj një pronari që vazhdon t'i përgjigjet. Një konflikt i vetëm në momentin e lidhjes tregon më tepër një përplasje të njëhershme. Në çdo rast, pyetja tjetër është kush tjetër e mban adresën.

Tre rregullime vendosin dy pritës në një adresë

Pyetni serverin kush mendon se e mban adresën, më pas pyetni rrjetin kush i përgjigjet asaj. grep -H ifconfig-push /etc/openvpn/ccd/* liston çdo adresë tuneli të fiksuar dhe certifikatën së cilës i takon. ip -4 neigh show dev tap0 tregon çfarë ka mësuar ura në shtresën e dytë. Krahasimi i këtyre dy listave gjen shumicën e dublikatave në më pak se një minutë.

Tre rregullime shpjegojnë pothuajse të gjitha: një hyrje në client-config-dir fikson një adresë për dy certifikata, një segment tap i urëzuar i jep një makine një adresë që një pritës tjetër e ka tashmë statikisht, ose një skedar qiraje i vjetruar kthen një adresë që një klient ende i lidhur mendon se e zotëron. Rasti i tretë është më dinaku, sepse ifconfig-pool-persist ripërdor qëllimisht adresa për klientë të njohur.

Bëjeni adresën unike në vend që të garoni për të

Rendi i nisjes vendos vetëm kush fiton sot, prandaj çdo rregullim i bazuar në sekuencën e rinisjes trajtojeni si të përkohshëm. Jepini çdo klienti rreshtin e vet ifconfig-push, ose caktoni adresa statike nga një interval që asnjë ndërfaqe ure ose serveri nuk e prek. Kontrolloni edhe listën e klientëve për emra të përbashkët të dublikuar, sepse duplicate-cn lejon dy sesione të ndajnë një identitet dhe për rrjedhojë një adresë të fiksuar. Nëse një pajisje e urëzuar ka vërtet nevojë për një adresë fikse, zhvendoseni në nënrrjetin e vet ose rezervojeni nga grupi në një vend që serveri e regjistron.

Fshini skedarin persist vetëm pasi të dini çfarë qirash mban, përndryshe rilidhja tjetër do të shpërndajë përsëri të njëjtat adresa.

Rinisni në rendin e duhur dhe konfirmoni një pronar për adresë

Zbatojeni ndryshimin fillimisht në server, më pas rilidhni klientët, që çdo pjesëmarrës të regjistrohet kundrejt grupit të korrigjuar. Nëse rinisni klientët fillimisht, ata mbeten me adresa që serveri i konsideron ende të zëna. Pas rinisjes lexoni skedarin e statusit dhe konfirmoni se çdo emër i përbashkët shfaqet një herë me një adresë. Dy hyrje për një emër nënkuptojnë se një sesion i vjetër nuk u mbyll kurrë, jo se grupi është prishur.

Nëse një klient ende nuk arrin ta mbajë adresën e tij, kontrolloni nëse e mban një ndërfaqe ure në të njëjtin pritës. Një urë që trashëgoi një adresë nga një pajisje furnizuesi do t'i përgjigjet ARP për të edhe kur serveri VPN tashmë ia ka dhënë atë adresë një klienti.

Vëzhgoni për një cikël të plotë rinovimi përpara se ta mbyllni biletën

Një lexim i pastër nuk provon asgjë. Vëzhgoni përshtatësin të paktën dhjetë minuta dhe detyrojeni një rilidhje në mes: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresa duhet t'i mbijetojë rilidhjes dhe të mbetet në një gjendje të preferuar.

Më pas ekzekutoni përsëri pyetësorin e ngjarjeve nga hapi i parë dhe konfirmoni se nuk kthen asgjë të re. Një regjistër i qetë përgjatë një rilidhjeje është dëshmia se konflikti u zhduk, ndërsa një regjistër i qetë pas një lidhjeje të vetme tregon vetëm se gara nuk ka ndodhur ende. Së fundi, provoni burimin për të cilin ekziston tuneli, sepse një urë që humbi adresën e saj mund të thyejë një rrugë furnizuesi ndërsa vetë VPN-i duket i shëndetshëm.

Regjistroni intervalin e grupit, çdo adresë të fiksuar dhe pritësin që e zotëron në shënimet e serverit. Atëherë përplasja tjetër vërehet brenda minutash, në vend që të duhet një pasdite e plotë për ta rizbuluar.