İki VPN havuzu için kaynak yönlendirmesi: kuralınızın gözden kaçırdığı şey

İki istemci havuzu, bir ağ geçidi ve plan önemsiz görünüyor: bir kural ilk havuzu hızlı bağlantıdan çıkarıyor, bir diğeri ikinci havuzu iş ortağı tünelinden geçiriyor. Sonra kurallar yerinde ve ikinci havuz hâlâ varsayılan rotadan çıkıyor. Kural bozuk değil. Paketin kaynağı, aramanın gerçekleştiği anda yazarın beklediği şey değil, çünkü çeviri ve arama aynı paketin yolculuğunun farklı noktalarında gerçekleşiyor ve sıra çoğu kişinin çizdiği zihinsel diyagramın tersi.

Arama, kaynak yeniden yazılmadan önce gerçekleşir

Bir VPN istemcisinden yönlendirilen paket için çekirdek sabit bir sıra izler. Paket tünel arayüzüne gelir, conntrack ve DNAT'ın bulunduğu prerouting'ten geçer, sonra yönlendirme kararı verilir, sonra iletim, sonra SNAT'ın en son uygulandığı postrouting. from biçimindeki kural bu yönlendirme kararı sırasında bakılır, yani istemcinin özgün adresini görür, çevrilmiş olanı değil.

Dolayısıyla bir masquerade kuralı eklemek, giden akışa hangi politikanın uyduğunu değiştirmez. Değişen, uzak ucun ne gördüğü ve dolayısıyla hangi dönüş yolunun var olduğudur. Bunlar iki farklı sonuçtur ve değişiklik incelemeleri onları sürekli karıştırır. Bunları ayırın, tasarım genellikle bir dakika içinde netleşir.

Çevrilmiş adres kurallarda yanıt yönünde görünür. Ağ geçidine geri dönen paket çevrilmiş adrese adreslenmiştir ve hedefe veya paketin girdiği arayüze dayalı politika kurallarınız varsa eşleştireceğiniz değer odur. Aynı bağlantı, her yönde farklı bir doğruluk kaynağı.

Yani farklı kaynaklara sahip iki havuz gerçekten farklı tablolara ihtiyaç duyar ve tasarım doğrudur. Yukarıdaki tablonun dışladığı şey, uzak sitenin ne aldığına bakıp kuralı oradan çıkarma kısayoludur.

Ağ geçidinden yapılan test havuzun testi değildir

Ağ geçidinin kendi ürettiği trafik hiçbir zaman prerouting'ten geçmez, çünkü herhangi bir arayüze gelmemiştir. Çıkış yolunda yönlendirilir, kaynak olarak ağ geçidinin kendi adresi kullanılır ve istemci aralığına dayalı from kuralı eşleşmez. Bu alandaki her bilet, kutudan çalışıyor ama istemciden çalışmıyor diyorsa, aynı olgunun tekrarıdır.

İstemciyi yaklaşık olarak tahmin etmek yerine benzetin. Yönlendirme araması doğrudan sorulabilir, bir kaynak ve bir giriş arayüzü verilerek:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Bunu her havuz için bir kez çalıştırın. İki komut aynı arayüzü döndürürse kurallar havuzları ayırmıyor demektir ve neden ya eksik bir kural ya da ikisine de uyan daha yüksek öncelikli bir kuraldır. Farklı arayüzler döndürüp istemci yine de başarısız olursa hata aramanın ardındadır ve kurallara bakmayı bırakabilirsiniz.

Öncelik, dosyadaki konum değil

Kurallar artan öncelik sırasına göre değerlendirilir ve önemli olan sayıdır, yazdığınız sıra değil. local tablosu öncelik 0'da, main tablosu 32766'da ve varsayılan kural 32767'de bulunur, bu yüzden varsayılan öncelikle eklenen bir kural listenin sonuna yakın düşer ve neredeyse her şeye yenilir.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Belirtik bir öncelik, amaçlanan sırayı dosyada ve incelemede görünür kılar. Ayrıca sonradan yapılan bir eklemenin sessizce mevcut bir kuralın önüne geçmesini engeller; bu, çalışan bir politikanın ilgisiz bir değişiklikten sonra durmasının en yaygın nedenidir.

Eksik bir tabloyu işaret eden eşleşen bir kural diğer tuzaktır. 201 tablosunda varsayılan bir rota varsa ama hedefe giden rota yoksa paket düşürülür veya yanlış yere gönderilir ve kural tek başına bakıldığında tamamen doğru görünür. Kuralı değil, tabloyu okuyun. Kural bir işaretçidir ve boş bir tablo hiçbir yeri işaret eden bir işaretçidir.

Dönüş yolu yine de var olmalı

Kaynak politikası bir çıkış seçer. Dönüş yolu oluşturmaz. İkinci havuz iş ortağı tünelinden çıkıyorsa, iş ortağı 172.31.8.0/24 ağına nasıl ulaşacağını bilmelidir; ya ağ geçidine geri bir rota ile ya da zaten bildiği çevrilmiş adresleri alarak.

Bunlar arasında seçim yapmak görünür sonuçları olan bir tasarım kararıdır. İstemci aralığını geri yönlendirmek her istemcinin kimliğini iş ortağında korur ve sizin önekinizi kabul etmesini gerektirir. Çeviri, havuzu tek bir adresin arkasına saklar ve iş ortağının yalnızca o adresi kabul etmesini gerektirir; bunun bedeli, kimin bağlandığı konusunda sizin ve onun günlüklerinin artık uzlaşmamasıdır.

Ne seçerseniz seçin, havuz tanımının yanına yazın. Yalnızca birinin belleğinde var olan bir dönüş rotası, tam olarak iş ortağı bir güvenlik duvarını değiştirene kadar yaşayan ve sonra yeniden kurulması bir gün süren şeydir.

Politikada ağ geçidinin kendi tünelini yakalamayın

İstemciler için yazdığınız kurallar, hariç tutmadığınız sürece ağ geçidinin ürettiği trafik için de geçerlidir. Bir işarete veya çıkış arayüzüne dayalı geniş bir kural, ağ geçidinin iş ortağıyla olan kendi bağlantısını yakalayabilir ve o zaman politikayı taşıyan tünel politika tarafından yönlendirilir. Bu, sağlayıcı arızası gibi görünen bir döngü veya kesinti üretir.

Her kuralı tasarımın izin verdiği kadar dar tutun: kaynak öneki, giriş arayüzü ve destekleniyorsa yalnızca istemci paketlerinin taşıdığı bir işaret. Sonra her kural değişikliğinden sonra ağ geçidinin kendi bağlantısını test edin, çünkü arıza kendine gönderme yapar ve istemci testinde görünmez.

ip-rule kılavuz sayfası seçicinin ve önceliğin anlambilimini belgeler. Bunu her havuz için arama testiyle birleştirin, tasarım denetlenebilir hâle gelir; bir yıl dayanan politika yönlendirmesiyle herkesin dokunmaya korktuğu arasındaki fark budur.