Windows-da OpenVPN adapteri yanıb-sönür? Dublikat IP-ni yoxlayın

Windows-da ünvan götürüb onu itirən və hər neçə saniyədən bir bunu təkrarlayan OpenVPN adapteri adətən DHCP xətası deyil. Adapterə artıq başqa bir şeyin cavab verdiyi ünvandan istifadə etmək tapşırılır, buna görə Windows onu yararsız sayır və klient yenidən başlayır. Klient jurnalı səssiz qalır, çünki toqquşma onun altında, əməliyyat sisteminin öz şəbəkə yığınında həll olunur.

Bu fərq vacibdir, çünki tunel konfiqurasiyasına yönəlmiş hər diaqnostika addımı server tərəfindəki dublikat ünvanı qaçıracaq.

Windows hadisə jurnalından başlayın, klient jurnalından yox

Windows ünvan toqquşmalarını Sistem jurnalında 4198 və 4199 hadisə ID-ləri ilə qeyd edir. Birincisi ünvan üçün aşkarlanmış toqquşmanı bildirir, ikincisi interfeysin konfiqurasiya olunduğu ünvandan istifadə edə bilmədiyini bildirir. Heç biri OpenVPN-i qeyd etmir, buna görə də onları gözdən qaçırmaq asandır.

Son hadisələri götürün və onların vaxt damğalarını adapterin yenilənmə dövrü ilə müqayisə edin: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Hər on beş saniyədə bir toqquşma, həmin ünvana cavab verməyə davam edən sahibə qarşı eyni ünvanı təkrar yoxlayan klientə uyğun gəlir. Qoşulma anındakı tək toqquşma isə birdəfəlik toqquşmaya işarə edir. Hər halda, növbəti sual ünvanı başqa kimin saxladığıdır.

Üç düzüm iki hostu bir ünvana qoyur

Serverdən soruşun ki, ünvanı kimin saxladığını düşünür, sonra şəbəkədən soruşun ki, ona kim cavab verir. grep -H ifconfig-push /etc/openvpn/ccd/* hər bərkidilmiş tunel ünvanını və aid olduğu sertifikatı sadalayır. ip -4 neigh show dev tap0 körpünün ikinci qatda nə öyrəndiyini göstərir. Bu iki siyahını müqayisə etmək dublikatların çoxunu bir dəqiqədən az vaxtda tapır.

Üç düzüm onların demək olar hamısını izah edir: client-config-dir qeydi iki sertifikat üçün bir ünvan bərkidir, körpülənmiş tap seqmenti maşına başqa hostun artıq statik olaraq malik olduğu ünvanı verir, və ya köhnəlmiş icarə faylı hələ qoşulmuş klientin özünə aid saydığı ünvanı qaytarır. Üçüncü hal ən hiyləgərdir, çünki ifconfig-pool-persist tanınmış klientlər üçün ünvanları qəsdən təkrar istifadə edir.

Ünvan üstündə yarışmaq əvəzinə onu unikal edin

Yükləmə sırası yalnız bugün kimin qalib gəldiyini həll edir, ona görə yenidən başlatma ardıcıllığına əsaslanan istənilən düzəlişi müvəqqəti sayın. Hər klientə öz ifconfig-push sətrini verin və ya heç bir körpü və server interfeysinin toxunmadığı diapazondan statik ünvanlar ayırın. Klient siyahısını dublikat ümumi adlar üçün də yoxlayın, çünki duplicate-cn iki sessiyaya bir şəxsiyyəti və buna görə də bir bərkidilmiş ünvanı paylaşmağa imkan verir. Körpülənmiş cihaz həqiqətən sabit ünvan tələb edirsə, onu öz alt şəbəkəsinə köçürün və ya serverin qeyd etdiyi yerdə hovuzdan ayırın.

Persist faylını yalnız hansı icarələri saxladığını bildikdən sonra silin, əks halda növbəti yenidən qoşulma eyni ünvanları yenidən paylayacaq.

Düzgün sıra ilə yenidən başladın və hər ünvan üçün bir sahib olduğunu təsdiqləyin

Dəyişikliyi əvvəlcə serverdə tətbiq edin, sonra klientləri yenidən qoşun ki, hər iştirakçı düzəldilmiş hovuza qarşı qeydiyyatdan keçsin. Klientləri əvvəl yenidən başlatmaq onları serverin hələ tutulmuş saydığı ünvanlarla qoyub gedir. Yenidən başlatmadan sonra status faylını oxuyun və hər ümumi adın bir ünvanla bir dəfə göründüyünü təsdiqləyin. Bir ad üçün iki qeyd köhnə sessiyanın heç vaxt bağlanmadığını bildirir, hovuzun pozulduğunu yox.

Əgər klient hələ də ünvanını saxlaya bilmirsə, eyni hostdakı körpü interfeysinin onu daşıyıb-daşımadığını yoxlayın. Vendor cihazından ünvan miras almış körpü, hətta VPN serveri həmin ünvanı klientə verdikdə belə, ona ARP cavabı verəcək.

Bileti bağlamazdan əvvəl tam yenilənmə dövrünü gözləyin

Bir təmiz oxunuş heç nəyi sübut etmir. Adapteri ən azı on dəqiqə izləyin və ortada yenidən qoşulmanı məcburi edin: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Ünvan yenidən qoşulmadan sonra da qalmalı və üstünlük verilən vəziyyətdə qalmalıdır.

Sonra ilk addımdakı hadisə sorğusunu yenidən işə salın və yeni heç nə qaytarmadığını təsdiqləyin. Yenidən qoşulma boyunca səssiz jurnal toqquşmanın getdiyinin sübutudur, tək qoşulmadan sonrakı səssiz jurnal isə yalnız yarışın hələ baş vermədiyini bildirir. Nəhayət, tunelin mövcud olduğu resursu sınaqdan keçirin, çünki ünvanını itirmiş körpü VPN özü sağlam görünərkən vendor yolunu poza bilər.

Hovuz diapazonunu, hər bərkidilmiş ünvanı və ona sahib hostu server qeydlərində yazın. Onda növbəti toqquşmanı tapmaq bir günorta yerinə bir neçə dəqiqə çəkəcək.