OpenBSD VPN ağ geçidinde tun0 üzerinden LAN için NAT

Aynı OpenBSD ağ geçidine sahip iki mühendis, uzak bir ağa ulaşmak için size sık sık iki farklı kural seti verir ve her ikisi de savunulabilir. Kaynak çevirisi ile dönüş yolu arasındaki seçim hiç de sözdizimi sorunu değildir. Her şey karşı tarafın 192.168.88.0/24 hakkında zaten ne bildiğine ve günlüklerinizde neyi saklamanız gerektiğine bağlıdır. Burada hata yaparsanız nat-to satırı tamamen doğru görünürken yanıtlar uzak varsayılan ağ geçidinde kaybolur.

Yönlendirme ve yeniden yazma farklı soruları yanıtlar

Yönlendirme tablosu 172.20.0.0/16'nın tun0 üzerinden erişilebilir olduğuna karar verir ve bu karar herhangi bir pf çevirisine danışılmadan önce verilir. Ardından kaynak çevirisi paket başlığını değiştirir, böylece uzak uç LAN ana bilgisayarı yerine ağ geçidinin tünel adresini görür. Hiçbir mekanizma diğerinin yerini almaz: nat kuralı bir yol yaratamaz ve bir yol, özel alt ağınızı hiç duymamış uzak bir yönlendiriciyi ikna edemez. Karşı tarafın dönüş yolu yoksa yanıtlar atılır veya kendi varsayılan ağ geçidine iletilir ve hiçbir kural ayarı bunu düzeltmez.

Basitçe söylemek gerekirse, iletme trafiğin nereye gittiğini, çeviri ise nereden geliyor göründüğünü yanıtlar. Kural setini tasarlarken ikisini ayrı zihinsel kutularda tutun.

Karar veren üç koşul

Üç soruyu sırayla sorun, tasarım genellikle kendini seçer. Uzak ağın 192.168.88.0/24 için tünel adresine işaret eden statik bir yolu var mı, yoksa yöneticisi o yoldaki yönlendiricileri kontrol ediyor mu? Öyleyse LAN adreslerinin değişmeden seyahat etmesine izin verin ve çeviriyi tamamen atlayın. Karşı tarafta istemci başına görünürlük gerekiyor mu, erişim politikası için de denetim izi için de? Gerekiyorsa kaynağı korumak yönlendirme emeğine değer. Tünel adresi uzak bir yola yazılacak kadar kararlı mı, yoksa yeniden bağlanmalar arasında değişiyor mu?

Yanıtlardan herhangi biri hayır veya bilinmiyorsa nat-to pragmatik seçenektir ve aynı zamanda geri alınabilir olandır. Karşı taraf düzgün bir yol eklediğinde çeviri kuralı tek satırda çıkar. Hiç kurulmamış bir dönüş yolu, biri tünel neden yalnızca bir yönde çalışıyor diye her sorduğunda size bir destek başlığına mal olur.

Parçayı pf'nin gerçekten değerlendireceği yere yerleştirin

Aşağıdaki parça LAN'ın 192.168.88.0/24, uzak ağın 172.20.0.0/16 ve tünel arayüzünün tun0 olduğunu varsayar. İçinde sonraki atlamayı seçen hiçbir şey yoktur. Yalnızca tünelden çıkmakta olan paketlerde kaynağı yeniden yazar.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

O ilk satırdaki iki ayrıntı ağırlığın çoğunu taşır. tun0 etrafındaki parantezler pf'ye her durum kaydı oluşturduğunda arayüz adresini okumasını söyler; bu, yeniden bağlanmadan sonra tünel yeniden numaralandığında önemlidir. match sözcüğü kuralın yeniden yazıp sonra aşağı düştüğü anlamına gelir, bu yüzden ayrı bir pass kuralı akışı yine de kabul etmelidir. match satırında adlandırılan arayüz de yönlendirme tablosunun seçtiği arayüz olmalıdır, aksi hâlde pf kuralı paketin gerçekte izlediği yoldan farklı bir çıkış yolunda değerlendirir.

Çekirdek tarafını unutmayın. IPv4 iletimi etkin olmalı ve tünel ile LAN için durum tutan pass kuralları tüm bunlar anlam kazanmadan önce var olmalıdır. Buradaki anahtar sözcük sırası için OpenBSD FAQ'deki PF NAT bölümü doğru referanstır.

Trafiğe güvenmeden önce kural setini doğrulayın

Önce sözdizimini pfctl -nf /etc/pf.conf ile denetleyin; bu, dosyayı yüklemeden ayrıştırır. Sonra politikayı yükleyin ve çekirdeğin gerçekte ne tuttuğunu geri okuyun, çünkü temiz ayrıştırılmış bir kural yine de gölgelenebilir veya yanlış arayüze bağlanabilir. pfctl -sn çeviri kurallarını yüklenmiş biçimlerinde yazdırır ve pfctl -sr filtre kurallarını değerlendirme sırasına göre yazdırır.

Sonra kabloyu izleyin. Ağ geçidinde tcpdump -ni tun0 'host 172.20.0.10', tünelden çıkan kaynak adresin tünel adresi mi LAN ana bilgisayarı mı olduğunu gösterir. Hızlı bir netstat -rn -f inet hedefin hangi arayüze çözüldüğünü doğrular. Trafik akmaya başlayınca pfctl -ss durum kayıtlarını listeler; bir akış durum oluşturmadıysa paket hiçbir zaman durum oluşturan bir kuralla karşılaşmamıştır.

Tünel tarafı doğru görünüyor ama yanıtlar hâlâ gelmiyorsa pf'yi düzenlemeyi bırakın. Kalan arıza uzak yönlendiricide, yanıtın o tarafın ulaşamayacağı özel bir adrese gönderildiği yerde.

Çeviri tasarrufundan fazlasına mal olduğunda

Çeviri istemcileri gizler ve bazen bu tam olarak yanlış takastır. Üst üste binen alt ağlar bir durumdur: karşı taraf da içeride 192.168.88.0/24 kullanıyorsa, LAN ana bilgisayarlarını ağ geçidi olarak sunmak çakışmayı iyileştirmek yerine daha da kötüleştirir. Trafiği adres çiftine göre seçen IPsec politikaları başka bir durumdur, çünkü güvenlik politikası veritabanı çeviriden önce eşleştirilir ve yeniden yazdığınız paketi hiç görmez. Kullanıcı başına faturalayan, sınırlayan veya denetleyen her kurulum da kaynak tek bir adrese çöktüğü anda ihtiyaç duyduğu kimliği kaybeder.

Taşınabilir pf türevleri ayrı bir tuzaktır. Kendi kural dosyalarını üreten ürünler NAT'ın kendi arayüzlerinden yapılandırılmasını bekler ve elle düzenlenen parçalar bir sonraki yeniden yüklemede üzerine yazılır. match anahtar sözcüğü ortaya çıkmadan önce yazılmış kılavuzlardan kopyalanan kural setleri güncel bir çekirdekte yüklenmez, bu yüzden sözdizimini taşıyın ve tahmin etmek yerine hatayı okuyun.

Gerçek ağlarla temasta hayatta kalan karar kuralı kısadır: yapabildiğinizde dönüş yolu kurun, yapamadığınızda çevirin ve üç koşuldan hangisinin sizi bu seçime ittiğini yazın. O not, sıradaki kişiye yarım gün kazandırır.