pfSense OpenVPN: başka bir yönlendiricinin arkasındaki ağa ulaşmak

Dizüstü bilgisayarınız VPN üzerinden pfSense LAN'ına ulaşır ve iki atlama daha içerideki bir hizmete yine ulaşamaz, fark ise sahip başına bir yönlendirme kararıdır. Bir paketin gidiş-dönüşünü tamamlaması için üç cihazın anlaşması gerekir: istemci, güvenlik duvarı ve hedef ağı gerçekten elinde tutan yönlendirici. Bunlardan birini kaçırırsanız belirti aynı görünür.

Bir kuralı değiştirmeden önce tek bir paketi bu üç karardan geçirin, çünkü her sahibin farklı bir denetimi ve farklı bir arıza biçimi vardır.

Tek paket, üç yönlendirme kararı

İstemci hedefin tünele ait olup olmadığına karar verir ve yalnızca bildiklerinden karar verebilir: itilen bir rota, yerel bir rota veya zaten her şeyi kapsayan varsayılan bir rota. pfSense paketin sonra nereye gönderileceğine karar verir; bu, başka bir yönlendiricinin arkasındaki ağ için doğru arayüzdeki ulaşılabilir bir ağ geçidi üzerinden statik rota anlamına gelir. Alt yönlendirici VPN havuzuna dönüş yolunu bilip bilmediğine karar verir; bilmiyorsa yanıt atılır veya işe yaramaz bir yere gönderilir. Her karar diğer ikisinden bağımsızdır.

Bunlardan herhangi birinin arızalanması aynı kullanıcı raporunu verir. Bu yüzden hata ayıklama sırası araçlardan daha önemlidir.

İstemciye tahmin değil önek verin

IPv4 tünel ağı /30'dan büyük olan bir pfSense SSL/TLS sunucusunda, IPv4 Local network(s) alanı bağlandıklarında istemcilere rotalar dağıtır. İstemcinin bir tane uydurmasına güvenmek yerine alt öneki oraya ekleyin. Ardından bağlandıktan sonra istemcinin gerçek tablosunu okuyun, çünkü route-nopull içeren bir profil veya bir rota filtresi sunucunun gönderdiğini yok sayabilir. Sunucu tamamen doğru olabilirken istemci hiçbir şey kurmaz.

Diğer sunucu kipleri ve topolojiler farklı sınırlara sahiptir ve istemci ya da bağlantı başına ilke, belirli bir istemcinin ne aldığını değiştirebilir. Önce yanlışlıkla test ettiğiniz istemcide değil, önemli olan istemcide doğrulayın.

pfSense'i iç yönlendiriciye yönlendirin

pfSense'te statik bir rota tanımlı ve ulaşılabilir bir ağ geçidi gerektirir ve o ağ geçidi için seçilen arayüz gerçekten ona ulaşan arayüz olmalıdır; Netgate'in statik rota kılavuzu bunu böyle açıklar. Örnek bir düzenlemede geçiş bağlantısı güvenlik duvarında 192.168.77.1 ve iç yönlendiricide 192.168.77.2'dir, hizmet ağı ise arkasında 172.16.30.0/25'tedir. Rota sonra öneki ve sonraki atlamayı adlandırır, hizmetin adresini değil. Uzak ağdan bir adresi ağ geçidi olarak kullanmak, doğru görünen ama hiçbir yere iletmeyen bir rota kurmanın yaygın bir yoludur.

Bir arayüze ad vermek arkasındaki ağları tanımlamaz. Statik rota o tanımdır.

Uzak taraf havuzu bilmelidir

Alt yönlendirici havuz için bir dönüş rotasına ihtiyaç duyar; bu örnekte rota 192.168.77.1 üzerinden 10.55.0.0/24'tür ve varsayılan bir rota ya da dinamik bir protokol zaten bir tane sağlamıyorsa gereklidir. Hizmet ana bilgisayarının kendi ağ geçidi o yönlendiriciye doğru gitmelidir; bu, yönlendirici onun varsayılan ağ geçidi olduğunda genellikle doğru, ana bilgisayar elle yapılandırıldığında yanlıştır. Güvenlik duvarındaki ilke yönlendirmesi de belirli trafik için tabloyu geçersiz kılabilir, bu yüzden rotanın yanlış olduğu sonucuna varmadan önce bir kuralın başka bir ağ geçidi seçip seçmediğini kontrol edin.

Bu tasarım için çeviri gerekmez ve istemcinin kaynak adresini görünür tutmak alt ağın kendi ilkesini uygulamasına izin verir.

Kabul için tek bir yeni isteği tünel girişinden, güvenlik duvarının iç çıkışından ve hedeften gelen yanıttan geçirin. Bunun yerine çeviri bilinçli olarak kullanılıyorsa, alt ağın hangi kaynağı gördüğünü ve yanıtın nasıl dönmesinin beklendiğini kaydedin.

Üç sahibin planını izin verilen uygulamanın yanında saklayın, böylece sonraki yönetici yolu yeniden keşfetmek yerine yeniden kurabilsin.