net.ipv4.conf.default.forwarding neden tun0'a dokunmaz
default.forwarding yalnızca yeni arayüzleri eker, canlı bir tüneli değil. ip_forward, şablon ve arayüzü onu sahiplenen namespace içinde karşılaştırın.
Şunu ayarladınız: net.ipv4.conf.default.forwarding=1, VPN'i yeniden başlattınız ve tünel hâlâ ağ geçidinin yönlendirmesi gereken paketleri düşürüyor. Ayar dosyada doğru görünüyor ve arayüz hâlâ iletmenin kapalı olduğunu bildiriyor. Bozulan bir şey yok: gelecekteki arayüzlerin devralacağı değeri değiştirdiniz, canlı tünelin kullandığını değil.
Bunu tünele sahip olan ana makinede, tünelin gerçekten var olduğu ağ namespace'inde gözden geçirin. Bir container veya ağ namespace'i arayüzü tutarken ana makine farklı sayılar gösterebilir.
Üç değeri birlikte okuyun
Ağ geçidinin tamamına ait anahtarı, yeni arayüzler için şablonu ve sizi ilgilendiren arayüzü karşılaştırarak başlayın. tun0 yerine gerçek giriş arayüzünü koyun ve dönüş arayüzünü de okuyun, çünkü iletme paketin vardığı noktada değerlendirilir.
sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwardingYaygın bir sonuç şudur: ip_forward = 0, default.forwarding = 1 ve tun0.forwarding = 0. İlk ikisi ana makinenin rolü konusunda anlaşamaz ve üçüncüsü arayüzün gerçekte ne yaptığını gösterir. Bu bileşim, hiçbir zaman yönlendirici olarak yapılandırılmamış, yalnızca bir şablon değeri verilmiş bir ana makineye uyar. Üç sayı birbiriyle çelişmiyor; üç farklı soruya yanıt veriyorlar. Şablon değerini yazmak da ana makinenin rolünü belirlemez.
Neden hareket eden tam da genel anahtar
net.ipv4.ip_forward ağ geçidinin tamamına ait denetimdir. Onu değiştirmek, aynı işlemin parçası olarak arayüz başına iletme ayarlarını günceller, bu yüzden tek bir yazma mevcut bir tünelin iletmeye başlamasını sağlayabilir. default.forwarding yalnızca sonradan başlatılan arayüzleri eker, dolayısıyla zaten var olan bir tünel doğduğu değeri korur.
Çekirdek belgeleri ip_forward özel olarak işaretler, ilgili bir nedenle: onu değiştirmek bir dizi başka IPv4 parametresini ana makine veya yönlendirici varsayılanlarına sıfırlar. Bu onu kör bir alet yapar. Ağ geçidi rolünü kurmanın parçası olarak bir kez ayarlamak sorun değil; hata ayıklama hilesi olarak tekrar tekrar değiştirmek, doğru yapmak için zaman harcadığınız yapılandırmayı sessizce yeniden yazabilir.
Arayüz başına değerler de bir nedenle var. Bilerek yönetilen bir ağ geçidi, asla yönlendirmemesi gereken bir arayüzde iletmeyi kapalı tutabilir, ana makine başka yerde iletse bile. Bu yüzden canlı arayüzü okumak önemlidir ve bu yüzden yalnızca genel değer tüm yanıt değildir. Böyle bir istisnayı bilinçli bir karar olarak okuyun ve o arayüzün neden farklı olduğunu yazın. Aksi halde bir sonraki mühendis onu iyilikle "düzeltir".
Ayarı doğru yerde kalıcı yapın
Tek seferlik başarılı bir sysctl -w çekirdeğin değeri kabul ettiğini kanıtlar. Yeniden başlatmaya dayanmaz ve yeniden bağlanırken arayüz yapılandırmasına dair kendi fikrini yeniden uygulayan bir ağ yöneticisine de dayanmaz. Ağ geçidi rolünü sysctl yapılandırma dosyasına veya ana makineye sahip olan ağ yöneticisine koyun, sonra onu uygulayan hizmeti yeniden başlatın.
Tünellerde sıra önemlidir. Yönetici arayüzü açılışta oluşturup iletmeyi sonradan uygularsa, arayüz eski varsayılanı devralabilir. Tüneli yeniden oluşturan bir hizmet yeniden başlatması da bir oluşturma olayıdır ve birim sağlıklı göründüğünde bunu kaçırmak kolaydır. Yalnızca dosyanın son içeriğini değil, sırayı denetleyin.
VPN yeniden bağlandıktan sonra ve bir kez daha yeniden başlatmadan sonra aynı üç değeri tekrar okuyun. Yeni oluşturulan tünel yeni bir arayüzdür ve yeni arayüz oluşturma anında geçerli olan varsayılanı alır. Sayılar bu olaylar arasında değişiyorsa, yapılandırmayı henüz tanımlamadığınız bir şey uyguluyor.
Bunu yanlış araçla onarmayın
İletme bozuk göründüğünde, güvenlik duvarını boşaltmak veya masquerading eklemek cazip gelir. İkisi de iletme anahtarını ele almaz. İletme durumu, iletme izni, hedefe giden bir yol ve dönüş yolu dört ayrı gereksinimdir ve yalnızca ilki sysctl'dir.
Doğru akışla da test edin. Ağ geçidinin kendi üzerinde yapılan bir istek iletmeyi hiç çalıştırmaz; bu yerel olarak üretilen trafiktir. Soru, VPN istemcisinden veya LAN ana makinesinden gelen bir paketin kabul edilip ileriye yönlendirilip yönlendirilmediğidir, bu yüzden test ağ geçidinin arkasından başlamalıdır.
IPv6 durumunu ayrı tutun
Burada her şey IPv4. IPv6 iletmesi, yönlendirici duyuruları ve accept_ra davranışının kendi denetimleri var ve ipv4 yolunu ipv6 ayarına kopyalamak, inandırıcı görünen ama işe yarar hiçbir şey yapmayan bir dosya üretir. Çift yığınlı bir ağ geçidinin her iki kümenin de bilinçli olarak yapılandırılmasına ihtiyacı vardır.
Son bir denetim: değerler uyuştuğunda, tünelin yolu hedef için seçiliyor mu ve dönüş yolu var mı doğrulayın. Yolu olmayan bir arayüzde açık iletme hâlâ bir kara deliktir ve bu arıza istemci tarafından aynı görünür.