Bağlantı reddedildi bir sertifika sorunu değildir: VPN çalışma kılavuzu

İstemci, CRL'yi yeniden ürettikten hemen sonra bağlantının reddedildiğini söylüyor, bu yüzden CRL suçlu görünüyor. Değil. Ret, taşıma katmanının yanıtıdır ve sertifika doğrulaması daha sonra, tünelin el sıkışması içinde yapılır. Zamanlama bir bağlamdır, kanıt değil.

İki denetim olayları bir dakikadan kısa sürede ayırır ve hiçbiri güven ayarlarına dokunmaz.

Hatayı onu üreten katmanda okuyun

connect'ten gelen ECONNREFUSED, taşıma denemesinin reddedildiği anlamına gelir: bir şey reset ile yanıt verdi ya da yığın ulaşılamaz bir bağlantı noktası bildirdi. Bir sertifika sorunu bu hatayı üretemez, çünkü TLS el sıkışması taşıma bağlantısı olmadan asla başlamaz. Bir ret görüyorsanız istemci sertifika sunacak kadar ilerlememiştir. Bu tek gerçek, iptali neden olarak eler.

Tersi de geçerlidir. İptal edilmiş bir sertifika tamamlanmış bir TCP bağlantısı ve sunucuda doğrulama hatası olarak kaydedilen başarısız bir el sıkışma üretir.

TCP reddi: kimse dinlemiyor

TCP için, amaçlanan örneğin çalışıp çalışmadığını ve profildeki adres ile bağlantı noktasına bağlı olup olmadığını denetleyin. ss -lntp dinleyicileri gösterir ve bunlardan birinin yokluğu olağan açıklamadır. Paketleri düşürmek yerine reddeden bir güvenlik duvarı istemci tarafında aynı iletiyi üretir, bu yüzden ikisini de denetlersiniz.

Adres ailesini de denetleyin. 127.0.0.1 veya yalnızca IPv6'ya bağlı bir hizmet, diğerine çözümlenen istemciyi reddeder.

Sonra tahmin etmek yerine hizmet günlüğünü okuyun. CA bakımından sonra yeniden başlatma okunamayan veya eksik bir dosyada başarısız olabilir ve dinleme durumuna hiç ulaşmayabilir, günlük de dosyanın adını verir. Bu bir başlatma hatasıdır, reddedilen sertifikadan farklı bir hata.

UDP'nin reddedecek el sıkışması yok

UDP üzerinden OpenVPN TCP anlamında bağlantı kurmaz, bu yüzden connect anında reddedilecek bir şey yoktur. Linux'ta bir UDP soketinin gösterdiği hata, önceki bir datagramın oluşturduğu ICMP port-unreachable'dan gelebilir. udp(7) kılavuz sayfası bu eşzamanlı olmayan davranışı açıklar.

Bu yüzden bir UDP istemcisi, sunucu süreci çalışırken ama beklenen adrese bağlı değilken bir ret yazdırabilir.

Bir CRL gerçekte nerede denetlenir

CRL, TLS el sıkışması sırasında, karşı taraf sertifikasını sunduktan sonra ve yalnızca sunucu yapılandırması buna izin veriyorsa danışılır. OpenVPN'in crl-verify seçeneği dosyayı işaret eder ve başarısızlık sunucu günlüğünde sertifikayı adlandıran bir doğrulama hatası olarak görünür.

Bu nedenle iptal edilmiş bir istemci taşıma katmanında bağlanır ve ardından kimlik doğrulamada başarısız olur. Aynı sunucu, aynı bağlantı noktası, tamamen farklı bir ileti.

O aşamaya vardığınızda CRL'nin verenini ve geçerlilik tarihlerini denetleyin. Yanlış CA tarafından imzalanmış bir CRL ya da istemci bağlanmadan önce süresi dolmuş bir CRL, istemcinin kendi sertifikasıyla hiçbir ilgisi olmayan doğrulama hataları üretir.

Bir dahaki sefere kısa bir çalışma kılavuzu

Önce taşımayı doğrulayın: dinleyici var, adres ailesi doğru, güvenlik duvarı reddetmiyor. Sonra başlangıç günlüğünü okuyarak hizmetin dinleme durumuna ulaştığını doğrulayın. Ancak ondan sonra doğrulama iletileri için el sıkışma hatalarına bakın. Bu sırayı sabit tutun, çünkü her adım bütün bir neden sınıfını eler.

Taşımayı, çözümlenmiş hedefi, bağlantı noktasını ve hatanın tam metnini not edin. İstemciyi yeniden kurmak bu kanıtı yok eder ve genellikle hiçbir şeyi değiştirmez.