Windows'ta bir adres alıp bırakan ve bunu birkaç saniyede bir tekrarlayan OpenVPN bağdaştırıcısı genellikle DHCP hatası değildir. Bağdaştırıcıya başka bir şeyin zaten yanıt verdiği bir adres kullanması söylenir, bu yüzden Windows onu kullanılamaz olarak işaretler ve istemci baştan başlar. İstemci günlüğü sessiz kalır çünkü çakışma onun altında, işletim sisteminin kendi ağ yığınında çözülür.

Bu ayrım önemlidir, çünkü tünel yapılandırmasına yönelik her sorun giderme adımı sunucu tarafındaki yinelenen adresi gözden kaçıracaktır.

İstemci günlüğüyle değil, Windows olay günlüğüyle başlayın

Windows adres çakışmalarını Sistem günlüğüne 4198 ve 4199 olay kimlikleriyle kaydeder. Birincisi bir adres için algılanan çakışmayı bildirir, ikincisi bir arabirimin yapılandırıldığı adresi kullanamadığını bildirir. Hiçbiri OpenVPN'den söz etmez ve tam bu yüzden gözden kaçırmak kolaydır.

Son olayları çekin ve zaman damgalarını bağdaştırıcının yenileme döngüsüyle karşılaştırın: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Her on beş saniyede bir çakışma, aynı adrese yanıt vermeye devam eden bir sahibe karşı aynı adresi yeniden deneyen istemciye karşılık gelir. Bağlanma anındaki tek bir çakışma ise daha çok tek seferlik bir çarpışmaya işaret eder. Her iki durumda da sıradaki soru, adresi başka kimin tuttuğudur.

Üç düzen iki ana bilgisayarı tek adrese koyar

Sunucuya adresi kimin tuttuğunu düşündüğünü sorun, sonra ağa ona kimin yanıt verdiğini sorun. grep -H ifconfig-push /etc/openvpn/ccd/* sabitlenmiş her tünel adresini ve ait olduğu sertifikayı listeler. ip -4 neigh show dev tap0 köprünün ikinci katmanda ne öğrendiğini gösterir. Bu iki listeyi karşılaştırmak yinelenenlerin çoğunu bir dakikadan kısa sürede bulur.

Üç düzen neredeyse hepsini açıklar: client-config-dir içindeki bir girdi iki sertifika için tek adres sabitler, köprülenmiş bir tap segmenti bir makineye başka bir ana bilgisayarın zaten statik olarak sahip olduğu adresi verir veya eski bir kiralama dosyası hâlâ bağlı bir istemcinin kendisine ait sandığı adresi döndürür. Üçüncü durum en sinsi olanıdır, çünkü ifconfig-pool-persist bilinen istemciler için adresleri bilerek yeniden kullanır.

Adres için yarışmak yerine onu benzersiz yapın

Önyükleme sırası yalnızca bugün kimin kazanacağını belirler, bu yüzden yeniden başlatma sırasına dayanan her düzeltmeyi geçici sayın. Her istemciye kendi ifconfig-push satırını verin veya hiçbir köprü ya da sunucu arabiriminin dokunmadığı bir aralıktan statik adresler ayırın. İstemci listesini yinelenen ortak adlar için de denetleyin, çünkü duplicate-cn iki oturumun tek bir kimliği ve dolayısıyla tek bir sabitlenmiş adresi paylaşmasına izin verir. Köprülenmiş bir aygıt gerçekten sabit adrese ihtiyaç duyuyorsa, onu kendi alt ağına taşıyın veya sunucunun kaydettiği bir yerde havuzdan ayırın.

persist dosyasını yalnızca hangi kiralamaları içerdiğini öğrendikten sonra silin, yoksa sonraki yeniden bağlanma aynı adresleri yeniden dağıtır.

Doğru sırayla yeniden başlatın ve her adres için tek sahip olduğunu doğrulayın

Değişikliği önce sunucuya uygulayın, sonra istemcileri yeniden bağlayın, böylece her katılımcı düzeltilmiş havuza kaydolur. İstemcileri önce yeniden başlatmak onları sunucunun hâlâ kullanımda saydığı adreslerle bırakır. Yeniden başlatmadan sonra durum dosyasını okuyun ve her ortak adın tek bir adresle bir kez göründüğünü doğrulayın. Bir ad için iki girdi, eski bir oturumun hiç kapatılmadığı anlamına gelir, havuzun bozuk olduğu değil.

Bir istemci hâlâ adresini koruyamıyorsa, aynı ana bilgisayardaki bir köprü arabiriminin onu taşıyıp taşımadığını kontrol edin. Satıcı aygıtından adres devralan bir köprü, VPN sunucusu o adresi bir istemciye vermiş olsa bile onun için ARP yanıtı verir.

Kaydı kapatmadan önce tam bir yenileme döngüsü boyunca izleyin

Tek bir temiz okuma hiçbir şeyi kanıtlamaz. Bağdaştırıcıyı en az on dakika izleyin ve ortasında yeniden bağlanmayı zorlayın: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adres yeniden bağlanmayı atlatmalı ve tercih edilen durumda kalmalıdır.

Ardından ilk adımın olay sorgusunu yeniden çalıştırın ve yeni bir şey döndürmediğini doğrulayın. Yeniden bağlanma boyunca sessiz bir günlük, çakışmanın gittiğinin kanıtıdır; tek bir bağlantıdan sonraki sessiz günlük ise yalnızca yarışın henüz yaşanmadığı anlamına gelir. Son olarak tünelin var olma nedenini test edin, çünkü adresini kaybeden bir köprü, VPN'in kendisi sağlıklı görünürken satıcı yolunu bozabilir.

Havuz aralığını, her sabitlenmiş adresi ve onu elinde tutan ana bilgisayarı sunucu notlarına yazın. Böylece bir sonraki çakışma, yeniden keşfetmek için koca bir öğleden sonra yerine dakikalar içinde fark edilir.

İlgili makaleler