VPN üzerinden DHCP: yayını köprülemek mi, iletmek mi?

Tünelin karşı tarafındaki yeni dizüstü bilgisayar adres alamıyor, oysa aynı bilgisayar merkez ofiste çalışıyor. İlk akla gelen tahmin tünelin DHCP'yi engellediğidir. Çoğu zaman yayının hiçbir zaman yolu olmamıştır: yapılandırılmamış istemci 255.255.255.255 adresine gönderir ve sıradan bir IP yönlendirici bu paketi iletmez. Tünel tam olarak yönlendirilen bir tünelin yaptığını yapıyor.

İki tasarım bunu değiştirebilir ve bunlar eşdeğer değildir. Biri yayını taşır; diğeri isteği iletir.

Yayın yönlendiriciden asla geçmez

Adresi olmayan bir DHCPv4 istemcisi 0.0.0.0 adresinden sınırlı yayın adresine UDP 67 ve 68 numaralı bağlantı noktalarından gönderir. Bu paket tasarım gereği kendi bağlantısında kalır. Onu ileten bir yönlendirici, hizmet ettiği her segmenti sular altında bırakırdı.

Bu yüzden yönlendirilen saha-sahaya tünel, aktarıcıyı bir sunucuya bağlar. İstemcinin yayın etki alanını genişletmez ve hiçbir güvenlik duvarı kuralı bunu sağlamaz.

Köprülenen tünel gerçekte neyi genişletir

Bilinçli olarak köprülenen bir VPN, desteklenen topolojisi kapsamında Ethernet yayınını taşıyabilir ve o zaman DHCP yerel trafik olarak geçebilir. Bu gerçek bir seçenektir, ancak 2. katman tasarım kararıdır. Yayınla birlikte arıza etki alanını ve erişim sınırını da genişletiyorsunuz.

Köprüleme ayrıca bir yayın fırtınasının, ARP taramasının veya kötü niyetli bir DHCP sunucusunun nereye ulaşabileceğini değiştirir. Uzak ofisi aynı anahtara takmayacaksanız, sadece adres dağıtmak için tüneli köprülemeyin. Etkinleştirmeden önce bu etki yarıçapını test edin.

Bu, adres sağlamaktan daha büyük bir karardır ve bilinçli olarak verilmelidir.

Bunun yerine isteği iletin

Olağan yanıt, istemcinin yerel ağında bir aktarıcıdır. Yayını alır, onu unicast bir isteğe dönüştürür ve kendi adresini ağ geçidi adresi alanına koyar. Sunucu o aktarıcı adresine yanıt verir.

Örnek bir uzak ofis için aktarıcı ofisin LAN'ında bulunur ve sunucuya saha VPN'i üzerinden ulaşılır. O ofis için kapsamı, aktarıcı ve sunucu kimliklerini ve tam dönüş yolunu yapılandırın. Tünelden UDP 67'ye izin vermek, sunucuya hangi havuzun kullanılacağını söylemez.

İleten ancak hiç yanıt almayan bir aktarıcı genellikle dönüş yolu sorunudur. Kapsamı değiştirmeden önce aktarıcı adresine dönüş yolunu kontrol edin.

DHCP'yi ARP'den ve tünel adreslemesinden ayırın

DHCP UDP/IP üzerinden çalışır. Ethernet'te bir ana bilgisayar, aday adresin zaten kullanımda olup olmadığını kontrol etmek için ARP'yi de kullanabilir. Bu çakışma kontrolü ayrı bir bağlantı-yerel işlemdir, DHCP iletilerinin taşıyıcısı değildir. DHCP aslında ARP'tir demek yanlıştır; ikisinin hiç ilişkisi yok demek fazla geniştir.

Bir VPN istemcisi tünel adresini DHCP yayını yerine VPN protokolünden veya sunucunun kendi havuzundan da alabilir. Adında DHCP geçen bir seçenek, iletilen bir DHCP paketini değil, istemciye itilen ayarları tanımlıyor olabilir. DHCP'nin hiç devrede olduğunu varsaymadan önce sunucunun havuzunu kontrol edin.

Alıcı ağı, atamanın sahibini, kapsamı, bir aktarıcı olup olmadığını ve kesinti sırasında beklenen davranışı kaydedin. Ardından bu model üzerinden yeni bir kiralama ve yenileme test edin. İki saha aynı yönetilmeyen havuzu hizmete sunabiliyorsa, ilk dolaşan dizüstü bilgisayarı bekleyen bir çakışmanız var.