/64'ünüzü bölmek IPv6'yı VPN istemcilerine yönlendirmez

İstemci genel bir IPv6 adresi gösteriyor, el sıkışma tamamlandı ve internetten hiçbir şey geri dönmüyor. Havuz ayarı doğru görünüyor çünkü doğru; adres geçerli ve tünel onu taşıyor. Başarısız olan şey teslimat ve teslimat, VPN sunucusunun üstünde alınan ve hiçbir istemci tarafı yapılandırmasının etkileyemediği bir karara bağlı.

Mit: /64'ünüzün bir parçası zaten erişilebilir

Hikâye çekici: sunucunun genel bir /64'ü var, ikiye bölün, diğer yarısını VPN havuzuna verin ve o istemciler artık internette. Öneki bölmek gerçekten çakışma olmadan adres tahsis eder. Ancak bu adreslerden birine giden bir paketin nereye gitmesi gerektiğine upstream ağının nasıl karar verdiğini değiştirmez.

IPv6'nın güvenilebilecek varsayılan bir çeviri katmanı yoktur, bu yüzden dönüş yolu ya yönlendirme ya da bağlantı düzeyinde teslimat olarak var olmalıdır. Bir istemcinin tünel adresine gönderilen paket upstream yönlendiricisine ulaşır ve o yönlendirici kendi tablosundan bir iletme kararı verir. Tablo fiziksel bağlantıyı gösteriyorsa paket oraya gider, VPN sunucunuz ne düşünürse düşünsün.

Bütün arıza budur: ileri yön çalışır çünkü sunucunuz onu gönderir, geri yön ise bir atlama ötede ölür çünkü upstream istemcinin var olduğunu hiç öğrenmedi.

Bağlantıda teslimatın gerçekte gerektirdiği şey

Upstream, /64'ün tamamını fiziksel bağlantıda saydığında her hedef adresi komşu keşfiyle çözer. O bağlantıya bir istek gönderir ve adresin sahibinin yanıt vermesini bekler. Tünelin arkasındaki VPN istemcisi o bağlantıda değildir ve yanıt veremez, bu yüzden istek yanıtsız kalır ve paket atılır.

Bir /65 ayırmak bu beklentiyi değiştirmez. Upstream aralığı hâlâ bağlantıda sayar, çünkü fikrini değiştirecek tek şey istemci adına yanıt veren bir rota veya proxy'dir. Bir VPN yapılandırmasını düzenlediğiniz için ikisi de ortaya çıkmaz. Havuzun kendi istemcileri arasında kusursuz çalışıp yine de başka her yerden erişilemez olmasının nedeni tam olarak bu boşluktur.

Proxy komşu keşfi iki dünyayı köprüleyebilen mekanizmadır. Ağ geçidi sahip olduğu belirli istemci adresleri için isteklere yanıt verir ve trafiği tünele iletir. Çalışır ve havuza uyan bir yaşam döngüsüyle tam olarak bu adreslerle sınırlandırılmalıdır, çünkü artık hizmet vermediğiniz bir adres adına yanıt vermek başkasının trafiğini kara deliğe çevirir. Bazı upstream'ler beklemedikleri proxy yanıtlarını kabul etmez, bu yüzden bu tasarım sağlayıcının onayına da ihtiyaç duyar.

Yönlendirilmiş teslimatın gerektirdiği şey

Daha temiz tasarım, upstream'in gerçekten ağ geçidinize yönlendirdiği bir tahsistir. Bu, devredilmiş bir önek veya daha küçük bir blok için statik bir rota olabilir ve gereklilik her iki durumda da aynıdır: upstream tablosu istemci aralığı için sunucunuzu göstermelidir. O zaman dönüş trafiği ağ geçidine ulaşır ve ağ geçidi onu tünele iletir.

Yönlendirilmiş teslimat komşu keşfi sorununu tamamen ortadan kaldırır, bu yüzden akıllıca bir şey inşa etmeden önce sağlayıcıdan bunu istemeye değer. Rotayı yazılı olarak isteyin ve bir sonraki atlamanın upstream'in gerçekten ulaşabildiği adres olduğunu doğrulayın.

Her iki tasarım da ağ geçidinde IPv6 iletiminin etkin olmasına ve iletilen akışa her iki yönde izin veren güvenlik duvarı kurallarına ihtiyaç duyar. Teslimat, yolun geri kalanı için bir ön koşuldur, bir yedek değildir. İletimi kapalı çalışan bir rota, eksik bir rota ile tamamen aynı sessizliği üretir, bu yüzden herhangi bir şeyi yeniden tasarlamadan önce ikisini de kontrol edin.

Doğru kurulması gereken iki bağımsız rota

Havuz öneki ve istemcinin kendi varsayılan rotası ayrı ayarlardır ve bunları karıştırmak bozuk bir tünel gibi görünen kısmi bağlantı üretir. Havuz sunucuya hangi adreslerin dağıtılacağını söyler. İstemcinin rotaları, istemcinin hangi hedeflere trafiği tünele gönderdiğini belirler.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Yukarıdaki önek belgeleme alanıdır ve yeniden yönlendirme yalnızca IPv6 için geçerlidir; IPv6 teslimatı hâlâ düzeltilirken çift yığın kurulumunun sıklıkla istediği şey tam olarak budur. IPv4 yeniden yönlendirmesi IPv6 kapsamı oluşturmaz ve iki ayardan hiçbiri diğerini gerektirmez.

Hangi politikayı uygularsanız uygulayın, IPv6'nın bağlı olduğu denetim trafiğini çalışır durumda tutun. Packet Too Big mesajları yalnızca TCP ve UDP'ye izin veren bir güvenlik duvarının klasik kurbanıdır ve bunları düşürmek, kurulan ve ardından daha büyük aktarımlarda takılan bağlantılar üretir.

Yönlendirici duyuruları üçüncü hareketli parçadır. Ağ geçidi üst bağlantıda duyurmaya başlarsa, istemcilerin ve komşuların bağlantıdaki önekler hakkında inandıklarını değiştirebilir ve bu, az önce belgelediğiniz tasarımı sessizce geçersiz kılabilir.

Tasarımı kaydedin ki yeniden inşa onu yeniden üretsin

Üç nesneyi ayrı ayrı yazın: istemci tahsisi, istemcinin hedef rotası ve tahsis için upstream'in teslimat yöntemi. Üçüne de sahip bir okuyucu kurulumu yeniden inşa edebilir; yalnızca havuz ayarına sahip bir okuyucu özgün hatayı yeniden üretir.

Ardından dönüş yönünü açıkça test edin, dışarıdan geri gelmesi gereken bir paketle. openvpn(8) kılavuzu server-ipv6 ve redirect seçeneklerini kapsar ve sağlayıcınızın yönlendirme onayı kılavuzun kapsayamadığı yarıyı kapsar.