VPN adresi ile LAN DHCP kiralaması: tünelin IP'sini kim atıyor?

İstemciyi bağlayın ve Wi-Fi simgesi yerine bağdaştırıcıya bakın. 10.80.0.14 gibi bir adres, ofis LAN'ındaki hiçbir DHCP sunucusu o kiralamayı hiç kaydetmemiş olsa bile bir tünelin üzerinde durabilir. Numarayı hangi sürecin seçtiği, sorun gidermenin nereden başlayacağını belirler.

İstemcide her şey aynı görünür: bir IPv4 adresi, bir maske, bazen varsayılan ağ geçidi. Fark ancak o adrese kimin yanıt verdiğini ve kimin kaydını tuttuğunu sorduğunuzda ortaya çıkar.

Tünel adresini istemci tarafından okuyun

Windows, ilk satırı değil tüm bloğu okursanız farkı gösterir. ipconfig /all bağdaştırıcı açıklamasını, fiziksel adresi ve bir DHCP satırını yazdırır. PPP veya IKEv2 çevirmeli bağdaştırıcı genellikle DHCP'yi devre dışı olarak bildirir, çünkü bağlantı adresini bir LAN sunucusundan kiralamak yerine çevirme sırasında görüşmüştür. DHCP etkin tünel bağdaştırıcısı olağandışıdır ve ayrı bir incelemeyi hak eder.

Linux aynı bilgiyi iki araca böler. ip -4 addr show dev tun0 adresi ve önek uzunluğunu verir. nmcli -f IP4 connection show work değerin bağlantı profilinden, bağlantı üzerindeki DHCP alışverişinden veya itilen bir yapılandırmadan gelip gelmediğini ortaya koyar. WireGuard en net durumdur, çünkü arayüz göründüğünde wg-quick yapılandırma dosyasındaki Address satırını uygular ve bağlanma anında hiçbir eş bir şey atamaz.

Önek de bir şey söyler. Bir /32 veya 255.255.255.255 maskesi, ağ geçidinin tek bir ana bilgisayar adresine yönlendirme beklediğini gösterir; daha geniş bir maske ise tünelin arkasında bir yerde bağlantı üzerinde bir alt ağa işaret eder.

IKEv2 yapılandırma yükü ne taşır

IKEv2'nin bu iş için özel bir mekanizması vardır. RFC 7296, bölüm 3.15.1 içinde açıklanan yapılandırma yükü, INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS gibi öznitelikleri ve bunların IPv6 karşılıklarını taşır. İstemci tercihi yoksa sıfır uzunlukta değer içeren bir öznitelik gönderir ve yanıtlayan taraf kullanılmasını istediği değeri döndürür. Bu alışveriş zaten şifrelenmiş IKE_AUTH içinde akar, bu yüzden hiçbir DHCP yayını tüneli geçmez.

Bundan iki sonuç çıkar. Birincisi, adresi yanıtlayan taraf veya danıştığı herhangi bir yetkilendirme arka ucu seçer, bu yüzden bir havuz ağ geçidinde, bir RADIUS yanıtında veya bir kimlik sağlayıcı eşlemesinde yaşayabilir. İkincisi, DNS özniteliği adres özniteliğinden ayrıdır. 10.80.0.14 almak hangi çözümleyicinin döndüğü veya hiç dönüp dönmediği hakkında hiçbir şey söylemez.

Ağ maskesi özniteliği pratikte isteğe bağlıdır. Birçok kurulum yalnızca bir adres döndürür ve istemcinin bir ana bilgisayar yolu kurmasına izin verir, bu yüzden aynı havuz bir istemcide /32 gibi, diğerinde /24 gibi görünebilir.

LAN DHCP kapsamı ile VPN havuzunun çakıştığı yer

Sorun, iki atayıcı da aynı aralığa işaret ettiğinde başlar. 10.20.30.0/24 için DHCP sunucusu, 10.20.30.128/25 için yapılandırılmış bir VPN havuzu hakkında hiçbir şey bilmez, bu yüzden ağ geçidi aynı adresi uzak bir istemciye verirken onu 10.20.30.140 adresini bir yazıcıya kiralamaktan alıkoyan bir şey yoktur. Çakışma günlerce sessiz kalır ve sonra aralıklı bir yinelenen adres olarak ortaya çıkar.

Yönlendirilmiş bir saha-sahaya tasarım çakışmayı yapısı gereği önler. Şubedeki ana bilgisayar yerel DHCP sunucusunun verdiği adresi korur. İki ağ geçidindeki tünel arayüzleri kendi bağlantı adreslerini taşır ve yönlendirme tablosu paketlerin nasıl ilerleyeceğini belirler. Uzak erişim istemcilerinin adresleri üçüncü kategoridir ve ağ geçidinin bağlantı adresleriyle karıştırılmamalıdır.

Tüneli LAN'a köprülemek bu ayrımı ortadan kaldırır. Tasarım gerçekten tek bir yayın alanı gerektiriyorsa, VPN uç noktası adresleri kendi başına vermek yerine bir röle veya paylaşılan yetkili kaynak üzerinden DHCP sunucusuyla aynı atama kararlarına katılmalıdır.

Adresi hangi sürecin sahiplendiğini doğrulayın

Bir kapsamı değiştirmeden önce sahipliği kanıtlayın. İstemcide adresi ve öneki not edin. LAN'da kiralama veritabanında arayın. Ağ geçidinde dağıtmak üzere yapılandırıldığı havuzları listeleyin. Kiralama dosyasında bulunan bir adres bir DHCP sunucusuna aittir, yani tünel köprülenmiş veya röle edilmiştir; yalnızca ağ geçidi havuzunda bulunan bir adres tünelin uç noktasına aittir.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Yanıt netleştiğinde dört şeyi not edin: hangi bileşenin istemci adresini atadığını, bunun için hangi aralığın ayrıldığını, dönüş trafiğinin o aralığa nasıl ulaştığını ve hangi kaynakların onu kabul ettiğini. Bu dört kayıt, sanal bir bağdaştırıcı satırını operasyonel bir gerçeğe dönüştürür.

Oradayken DNS özniteliği için kontrolü yineleyin. Adresleri dağıtan ama çözümleyici vermeyen bir havuz, istemciyi yerel DNS'inde bırakır; bu, LAN'ın zaten kullandığı adresi dağıtan bir havuzdan farklı bir arızadır.