OpenVPN istemcileri neden ağ geçidinin IPsec seçicilerini kaçırıyor

Ağ geçidinden uzak IPsec tünelinin arkasındaki bir konağa ping atın, temiz yanıt verir; tünel sağlıklı görünür ve bilet ilerler. Sonra bağlı bir istemci aynı konağı dener ve hiçbir şey geri gelmez. O ping asla istemcinin akışının kanıtı değildi, çünkü ağ geçidinin kendi kaynak adresiyle çıktı ve başka bir IPsec seçicisiyle eşleşti. İki durumun neden ayrıldığını anlamak, düzeltmenin büyük bölümüdür.

Ağ geçidinin pingi istemcinizin hiç kullanmadığı bir akışı sınar

Hangi ilkenin geçerli olduğuna kaynak adres karar verir. Ağ geçidinde üretilen bir paket, yerel LAN'ından veya tünelin uç noktasından bir adresle çıkar ve ona uyan ilke tam olarak bu durum için yazılmıştır. İstemcinin paketi OpenVPN arayüzüne istemci havuzundan bir adresle gelir; bu tamamen başka bir seçicidir.

Bu yüzden arıza yönlendirme sorunu gibi görünür, oysa gerçekte ilke kapsamı sorunudur. Ağ geçidinden erişilebilirlik, eşin çalıştığını ve önerilerin görüşüldüğünü kanıtlar; havuzun korunup korunmadığına dair hiçbir şey kanıtlamaz.

Uygulamanın gerçekten ihtiyaç duyduğu uzak öneki itin

Bağlı istemciler için 10.8.0.0/24 ve korunan uzak ağ için 172.30.239.0/25 örnek çiftini alın. İstemcinin ihtiyacı ikinci öneke giden bir rotadır; ağ geçidinin LAN'ına ya da başka bir tünel adresine değil. Havuza itilen rota, istemciyi bu trafiği ağ geçidine teslim etmeye ikna eden şeydir. O olmadan paket, hata ayıkladığınız ilke kararına asla ulaşmaz.

İtilen rotaları kabul eden bir Community sunucusunda direktif gerçek maskeyi alır: push "route 172.30.239.0 255.255.255.128". Access Server aynı hedefi kurulu sürümün özel ağ veya erişim kuralı ayarları üzerinden yapılandırır; yönlendirilmiş ya da çevrilmiş kip bilinçli olarak seçilir. Üretilen güvenlik duvarı zincirlerini sahibi olan yapılandırma yerine düzenlemek, çalışan bir kurulumu yeniden üretilemez hale getirmenin yoludur.

Bağlandıktan sonra sunucunun niyetini değil, istemcinin yönlendirme tablosunu okuyun. Yalnızca havuzu kapsayan rota, itmenin hiç ulaşmadığı anlamına gelir; tünel üzerinden varsayılan rota ise bu gereksinimden daha geniştir ve sizi sonra şaşırtır. Maskeyi ve öneki birlikte denetleyin, çünkü /25'in /24 olarak itilmesi komşu adreslerin trafiğini taşıyamayacağı bir yola sokar. Ardından istemcinin o hedef için tünel arayüzünü seçtiğini doğrulayın.

Seçiciler istemci havuzunu içersin

İstemci adreslerini koruyan yönlendirilmiş erişim için IPsec ilkesi havuz ile uzak önek arasındaki trafiği korumalıdır. Ağ geçidinin kendi LAN'ı için yazılmış seçiciler pingi geçirir ve istemcinin isteğini düşürür; bu, bu incelemeyi başlatan asimetrinin tam kendisidir.

Yapılandırılmış önerilerin yanı sıra görüşülen ilkeyi de inceleyin; örneğin strongSwan'da ipsec statusall ya da uygulamanız için eşdeğer durum komutuyla. İlke tabanlı IPsec'te olağan rota fiziksel bir arayüzü gösterebilirken eşleşen trafik hâlâ şifrelenir, bu yüzden tünel aygıtının olmaması hiçbir şey kanıtlamaz. Seçici çiftlerini not ettiğiniz havuz ve önekle karşılaştırın.

Ağ geçidindeki genel kaynak NAT da eşleşmeyi bozabilir. Bir masquerade kuralı, ilke denetiminden önce istemcinin kaynağını yeniden yazarsa paket artık yazdığınız seçiciye benzemez. Geniş bir masquerade kuralının ikinci VPN için kötü bir düzeltme olmasının bir nedeni budur: hangi ilkenin geçerli olduğunu ve uzak tarafın hangi adresi kaydettiğini değiştirir. Yönlendirmeyi düşündüğünüz trafiği muaf tutun ya da bilinçli olarak çevirin ve seçicileri güncelleyin.

Yönlendirmeyi ya da çeviriyi bilinçli seçin

Yönlendirme istemci adresini uzak taraf için görünür tutar; böylece uzak günlükler ve kaynak başına kurallar anlamlı kalır ve uzak ağ geçidinin havuza dönüş yolunu bilmesi gerekir. Çeviri havuzu tek bir adresin arkasına saklar; bu, dönüş rotası sorununu ortadan kaldırır ve istemci başına kimliği yok eder.

Tek bir tasarım seçin ve yazın, çünkü ikisi farklı seçiciler ve farklı güvenlik duvarı sırası gerektirir. Yarı uygulanmış bir masquerade ikisinin arasında kalır ve hiçbirini tatmin etmez. Yazılı seçim, bir sonraki mühendisin hatayı bilinçli karardan ayırmasını da sağlar.

Döngüyü iletme ve yanıtta kapatın

Ağ geçidi amaçladığınız protokolü ve hedefi iletmelidir; bu, IP iletiminin açık olması ve çifti izin veren bir iletme zinciri olması demektir. Sonra uzak taraf yanıtları IPsec yolundan geri göndermelidir ve bu onların ağ geçidindeki yönlendirme kararıdır, sizinki değil. İki yarı da olağan yapılandırmadır ve ikisi de kolayca yarım bırakılır. Ayrı ayrı test edin ki eksik bir iletme kuralı bozuk tünelle karıştırılmasın.

İstemciden uygulamaya tek bir gerçek istekle doğrulayın; isteğin OpenVPN arayüzünden, IPsec kararından ve uzak konaktan geçişini izleyin. Yanıtı ayrı bir gözlem olarak inceleyin, çünkü gelen istek ile hiç dönmeyen yanıt istemcinin yerinden aynı görünür. İzlenen tek bir istek, ağ geçidinden atılacak her sayıda pingden daha değerlidir.

Test ederken hedef yetkisini dar tutun ve kural olmadan bir istemcinin hizmete ulaşamadığını doğrulayın. Kurulu bir rota ile kurulmuş bir ilişkilendirme, verilmiş erişimle aynı şey değildir.