WireGuard istemcisi OpenVPN istemcisine ulaşamıyor mu?

İki tünel de bağlanıyor, her istemci ağ geçidine ulaşıyor ve biri diğerinin adresini denediği anda paketler kayboluyor. İki el sıkışmanın hiçbirinde yanlış bir şey yok ve anahtarları yeniden vermek bunu değiştirmiyor. Ağ geçidi kendi iki arayüzü arasında sıradan şifrelenmemiş IP paketleri taşıyor, bu yüzden protokollerin birbirini anlaması hiç gerekmiyor; ihtiyaçları olan şey, hiçbir el sıkışmanın sağlamadığı üç şeydir. Kaynak istemcide hedef kapsamı, ağ geçidinde kaynak sahipliği ve uzak tarafta bir dönüş yolu. Belirti üçü için de aynı, bu yüzden birlikte teşhis edilirler.

Belirtide her seferinde tek bir parça eksik

Bu tasarım wg1 üzerinde 10.71.0.0/24 WireGuard havuzu ve tun1 üzerinde 10.72.0.0/24 OpenVPN havuzu kullanıyor, ikisi de tek bir ağ geçidinde bitiyor. Test edilen istek 10.71.0.5 adresinden 10.72.0.30 üzerindeki HTTPS'e gidiyor. Aşağıdaki her adım bu tek akışla ilgili. Her kontrolün farklı bir arıza imzası var, kullanıcı hepsini aynı yaşasa da, ve genellikle her seferinde üçünden yalnızca biri eksik.

İki havuzun da gerçekten bu ağ geçidinde olduğunu ve iletmenin tünellerin yaşadığı ad alanında açık olduğunu doğrulayarak başlayın. İki protokolü farklı ad alanlarında sonlandıran bir ağ geçidi aralarında hiçbir şey iletmez ve herhangi bir eş yapılandırmasını okumadan önce bunu elemek gerekir.

Kolun hedef kapsamını genişletin

WireGuard istemcisinde mevcut eş girdisi OpenVPN hedefi için ağ geçidini seçmelidir, yani hedef öneki o eşin izin verilen listesinde yer almalıdır. Onu eklemek ikinci bir tünel oluşturmaz; istemcinin o adresi ararken hangi eşi seçtiğini değiştirir ve wg-quick ile yol genellikle listeyi otomatik izler.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Gerçek anahtar ve uç nokta satırlarını dokunulmadan bırakın ve Table = off kullanan bir yöneticinin bu listeden hiç yol almadığını unutmayın. Bu durumda aynı öneki sistem yönlendirme tablosuna sahibi kurmalıdır ve orada eksik bir yol tam olarak eksik izinli önek gibi görünür.

Kaynak sahipliğini ağ geçidinde tutun

Bu istemcinin ağ geçidindeki eş girdisi tam olarak o istemcinin kaynak adresine sahip olmayı sürdürmelidir. İzin verilen adresler iki yönde denetlenir: giden trafik için eş seçerler ve gelen bir paketin kaynağının onu gönderen eşe ait olduğunu doğrularlar. OpenVPN havuzunu kolun girdisine koymak, kol ona ulaşmak istediği için, trafiği yanlış katılımcıya yönlendiren hatadır.

AllowedIPs = 10.71.0.5/32

Bu girdiyi yönlendirme kolaylığı değil sahiplik beyanı olarak okuyun. İstemcinin ulaşması gereken her şey istemcinin hedef listesine aittir, ağ geçidinin bu eşin ne gönderebileceğine dair tasavvuruna değil.

OpenVPN tarafına dönüş yolu verin

Hedefin artık WireGuard kaynağına dönüş yoluna ihtiyacı var ve havuz istemcileri için bu genellikle OpenVPN sunucusundan itilen bir yol olarak gelir. Yalnızca sahip olması gereken istemcilere itin ve direktifin uygulandığını varsaymak yerine istemcide kabul edildiğini doğrulayın.

push "route 10.71.0.0 255.255.255.0"

Yol dağıtımı yetkilendirme değildir. Hedef havuzda değil de başka bir OpenVPN istemcisinin arkasındayken, o istemcinin kendi LAN sahipliği ve iletme gereksinimleri tasarıma katılır, ve itilen yol yalnızca ilk yarıdır. Gereksinimi direktif eklemeden önce grafik olarak yeniden yazın: hangi düğüm hangi önekin sahibi ve hangi düğüm ona doğru iletiyor.

Yalnızca izin vermeyi amaçladığınız o tek hizmete izin verin

İletme açık ve iki havuz da yönlendirilebilirken geriye kalan soru politikadır. Kuralı genel olarak arayüz çifti için değil o belirli akış için yazın, uygulamadan önce önizleyin ve yanıtlar yeni bağlantı olarak engellenmesin diye durum tutan dönüş yolunu koruyun. Kuru çalıştırma hiçbir maliyeti yoktur ve neyin ekleneceğini tam olarak gösterir.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Bunlar iletilen trafik için kurallardır, ağ geçidinin iki VPN hizmeti için dinleme kurallarından ayrıdır. Dış UDP bağlantı noktalarını açmak iç isteği yetkilendirmez ve iç isteği yetkilendirmek ağ geçidine sınırsız SSH ya da iletmede varsayılan izin gerektirmez. Hedefin kendi güvenlik duvarı ve dinleme adresi de uyuşmalıdır, çünkü loopback'e bağlı bir hizmet en dikkatli yönlendirilmiş paketi bile reddeder. Konuşmanın yalnızca bir yönünü kapsayan politika genellikle başarılı bir istek ve sessiz bir yanıtla başarısız olur, bu da üç sonuçtan en kafa karıştırıcısıdır.

Karşılıklı yollar genellikle kaynak çevirisinin gerekmediği anlamına gelir, bu da WireGuard adresini hedefte korur ve günlükleri okunur kılar. İki protokol devrede diye genel masquerading eklemeyin ve var olan bir çeviri kuralını neye bağlı olduğunu bilmeden kaldırmayın. Ardından o tek akışı baştan sona doğrulayın ve izin verilmeyen bir kaynağı ya da bağlantı noktasını da test edin: her iki tarafta çalışan bir el sıkışma ne çapraz yolu ne de yalıtımı kanıtlar.