DHCP 121 seçeneğiyle LAN makinelerine VPN dönüş yolu verin

Uzak VPN istemcileri bağlanır, LAN sunucusu yanıtlar ve yanıt sıradan internet yönlendiricisinden çıkıp orada ölür. Tek bir sunucu statik bir yolla düzeltilebilir, ama bunların tamamı için bir alt ağ, ağ yapılandırmalarını zaten aldıkları yerde ele alınmalıdır. DHCPv4 seçeneği 121 tam olarak bu tür bir hedef yolu dağıtır ve insanların varsayılanı unuttukları anda genellikle yanlış yaptıkları kısım budur. Belirti tek yönlü trafiktir: istekler gelir ve yanıtlar kaybolur.

Önce üç adresi adlandırın

Somut bir LAN alın: 192.168.50.0/24, her zamanki varsayılan yönlendirici 192.168.50.1 üzerinde ve ayrı bir VPN geçidi 192.168.50.2 üzerinde. Kimliği doğrulanmış uzak istemciler 10.90.0.0/24 adresini kaplar.

Katılan her makinenin ihtiyaç duyduğu yol 10.90.0.0/24 via 192.168.50.2. Hedef istemci havuzudur ve sonraki atlama, geçidin tünel adresi değil LAN adresidir.

Sınıfsız statik yol olarak kodlayın

121 seçeneği önek ve sonraki atlama çiftlerini taşır ve RFC 3442 hem kodlamayı hem de bundan doğan istemci davranışını tanımlar. Yalnızca bu örnek LAN'a hizmet eden mevcut bir dnsmasq örneği için yapılandırmanın biçimi şöyledir:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Bu bir parça, yeni bir DHCP hizmeti değil. Birden çok segmenti yöneten bir sunucuda seçeneği hâlihazırda kullandığınız etiketler veya ağ ilkesiyle sınırlayın. Önceki yapılandırmayı elinizin altında tutun, çünkü bunu geri almak yeniden başlatma değil, bir kiralama yenilemesi daha demektir.

Varsayılan yolu kaybetmeyin

Tuzak burada. 121 seçeneğini alan bir istemci, olağan Router seçeneğini yok saymak zorundadır, bu yüzden yalnızca VPN havuzunun yolunu duyurmak o makineyi tamamen varsayılan yolsuz bırakabilir. Makine hâlâ yapılandırılmış görünür ve interneti sessizce kaybeder. Kullanıcılar bunu, her arayüz açıkken ağ çökmüş gibi anlatır.

Yukarıdaki parçanın yaptığı gibi amaçlanan varsayılanı aynı listeye ekleyin. Sınıfsız yolları uygulamayan istemciler için olağan Router seçeneğini de yerinde bırakın; kime ne gönderileceğine sunucunun kendi seçenek işleyişi karar verir.

İstemcinin neyi kabul edeceğini kontrol edin

Adresi elle verilmiş bir makine bunu asla almaz, çünkü kiralama istemez. İstemci desteği de değişir, bu yüzden her aygıtın 121 seçeneğine uyduğunu varsaymak yerine gerçekten çalıştırdığınız işletim sisteminde test edin. O sunucuların sahiplerine hangilerinin statik adresli olduğunu doğrulatın. O makinelerin kendi yol kayıtları gerekir, yoksa basitçe katılmazlar.

Yönetilen DHCP hizmetleri başka bir sınırdır. Bazı bulut ağları yöneticilerin rastgele seçenekler yayımlamasına izin vermez ve aynı segmentteki rakip bir DHCP sunucusu hiç seçenek olmamasından daha kötüdür.

Kiralamayı, sonra aramayı doğrulayın

DHCP sahibinden değişikliği uygulamasını isteyin, ardından bir istemcide kiralamayı yenileyin. Var olan kiralamalar yenilenene kadar eski yapılandırmayı korur, bu yüzden hemen sonuç garanti değildir.

Bir Linux istemcisinde gerçek yolları okuyun ve iki kaydı da doğrulayın:

ip -4 route
ip -4 route get 10.90.0.23

Bağlamsal arama havuzun yolunu 192.168.50.2 üzerinden ve varsayılanı 192.168.50.1 üzerinden göstermelidir. Varsayılan yoksa yukarıdaki tuzağı yeniden üretmişsinizdir.

Sonra gerçek alışverişi test edin

Yol dağıtımı yolun tamamı değildir. Ayrı geçit hâlâ yönlendirmeye, uzak eşlerin sahipliğine ve sunucuya izin veren bir erişim ilkesine ihtiyaç duyar; DHCP kimseyi doğrulamaz.

Son olarak bir kaldırma planı bulundurun. Öğrenilen statik bir yol VPN düştüğünde kendini geri çekmez, bu yüzden eskimiş bir sonraki atlama tünel gittikten çok sonra bile o öneki kara deliğe çevirebilir.