Bir NIC mi, iki mi? VPN sunucusunun arayüz yerleşimini belirlemek

Tek bir fiziksel bağdaştırıcı birçok VPN sunucusu için yeterlidir ve bu da evrensel bir tasarım değildir. Şifreli bağlantı o bağdaştırıcıya gelir, VPN süreci onu çözer ve ardından iç trafik sanal bir arayüzden çıkar, yerel bir hizmete veya yönlendirilmiş bir LAN'a ulaşmadan önce. Bunun işleyip işlemeyeceği üç koşula bağlıdır: hedefin nerede olduğu, LAN'ın istemci havuzuna dönüş yolu olup olmadığı ve tek bir paylaşılan fiziksel bağlantının iddia ettiğiniz yalıtımı verip vermediği. Bu üçüne yanıt verin, bağdaştırıcı sayısı ardından gelir.

Bunu belirleyen üç koşul

İlk koşul hedeftir. VPN ana bilgisayarının kendisindeki bir hizmete yalnızca tünel arayüzünden ulaşılır, LAN'daki bir ana bilgisayar ise yönlendirme ve dönüş yolu gerektirir. İkinci koşul o dönüş yoludur, çünkü LAN aygıtı istemci havuzuna nasıl ulaşacağını bilmelidir; ister bir yolla, ister sunucuda çeviriyle.

Üçüncü koşul ayrımdır. Tek bağdaştırıcı, şifreli olsun olmasın her paketin tek bir bağlantıyı ve genellikle tek bir ilke zincirini paylaşması demektir, bu yüzden ayrı donanıma dayanan bir yalıtım iddiası tek bir arayüzle karşılanmaz. Bu, yol hakkında bir gerçektir; işletim sisteminin nasıl yapılandırıldığı hakkında değil. Tünel trafiğini yine de filtreleyebilirsiniz, ama sahip olmadığınız bir sınırı iddia edemezsiniz.

Üçünden hiçbiri kasada kaç port olduğuyla ilgili değil. Yönlendirme, adres sahipliği ve tasarımın fiziksel ayrıma ne kadar bağlı olduğuyla ilgili.

Fiziksel bölgeler, ayrı yukarı bağlantılar, verim veya bant dışı kurtarma yolu bunu haklı çıkardığında iki bağdaştırıcı meşru bir seçim olarak kalır. Bunlar somut gereksinimlerdir ve biri donanım sipariş etmeden önce yazılmalarına değer.

Hizmet VPN ana bilgisayarında çalıştığında

En basit durumda hiç yönlendirme gerekmez. Arka plan süreci istemcinin paketlerini tünel arayüzünde alır ve yerel bir sokete verir, yanıt da aynı arayüzden geri döner. Ana bilgisayar açısından istemci havuzunun adresi gerçek bir yerel adrestir.

Yine de iki şey doğru olmalıdır: hizmet, tünelin ulaşabildiği bir adreste dinlemeli ve ana bilgisayarın güvenlik duvarı tünel arayüzüne gelen trafiği kabul etmelidir. İkisi de aşağıdaki komutlarda görünür.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Bir hizmeti yalnızca genel adrese bağlamak veya tünel arayüzünü yanlışlıkla filtrelemek, ana bilgisayara ulaşan ve sonra ölen bir bağlantı üretir. Bu bir VPN arızası gibi görünür ve genellikle soket ya da güvenlik duvarı kararıdır.

Hedef LAN'da olduğunda

Tek bağdaştırıcılı tasarımın zorlu şöhretini kazandığı yer burasıdır. Sunucu istemcinin paketlerini LAN'a doğru iletmelidir, LAN aygıtı da yanıtları istemci havuzuna geri göndermelidir. Ya o havuzu LAN'da bir yol olarak taşırsınız, ya da sunucuda kaynak adresi çevirirsiniz ki yanıtlar sunucunun kendisine geri dönsün.

İki yanıt da meşrudur ve farklı biçimde başarısız olurlar. Dönüş yolu özgün istemci adresini hedefe görünür tutar; bu günlükler için iyidir, LAN adresleri varsayan güvenlik duvarı kuralları için kötüdür. Çeviri LAN'ı basit tutar ve istemcinin kimliğini hedeften saklar.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Asimetrik yol klasik belirtidir: istemcinin isteği ulaşır, yanıt başka bir yönlendiriciden çıkar ve bağlantı iki uçta da hata vermeden zaman aşımına uğrar. Tünel hakkında bir sonuca varmadan önce iki tarafta da yakalama yapın.

Bir takma ad neden ikinci bir bölge yaratmaz

Aynı bağdaştırıcıya ikinci bir adres eklemek veya ikinci bir portu taklit eden dummy arayüz oluşturmak çok az şeyi değiştirir. Paketler yine aynı fiziksel bağlantıdan, aynı anahtar portundan ve genellikle aynı güvenlik duvarı zincirinden çıkar, bu yüzden aralarında yeni bir sınır oluşmaz. Bu yapılandırma kolaylığıdır, segmentasyon değil. Onu bölge sınırı saymak, yalıtım iddiasının yalnızca kâğıt üzerinde yaşamasının yoludur.

Ayrı bir bölge yolda gerçek bir ayrım gerektirir ve bu gereksinimi ikinci bağdaştırıcı karşılar. Bir kural, VPN'e bakan trafiğin LAN'a bakan trafikle hiçbir zaman yayın alanını paylaşmamasına bağlıysa, ana bilgisayar nasıl adreslenirse adreslensin tek bir kablo bu özelliği veremez.

Bir ürün belirli bir mod için çok arayüzlü topoloji belgeliyorsa, bir geçici çözüm uydurmak yerine o ürünün belgelerini izleyin. Üreticiler desteklenen topolojileri sürümler arasında da değiştirir; bu, eski bir sihirbaz ekran görüntüsü yerine güncel kılavuzu okumak için bir nedendir daha.

Yerleşimi izin verdiğiniz trafiğe göre denetleyin

Sunucunun taşıması gereken trafik sınıflarını listeleyin: istemciden ana bilgisayara, istemciden LAN'a, ana bilgisayardan LAN'a ve şifreli dış bağlantı. Her sınıfın bir kaynağı, bir hedefi ve bir arayüzü vardır ve yerleşim dördünü aynı anda karşılamalıdır. Bunlardan üçünü ele alan tasarım genellikle talep üreten tasarımdır.

Ardından tasarım belgesindeki çizimi değil, gerçek arayüzleri ve gerçek yakalamayı doğrulayın. Aşağıdaki komutlar her iki görünümü de yazdırır.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Dış yakalama şifreli trafiği, iç yakalama ise tünel arayüzündeki çözülmüş trafiği gösteriyorsa ve fiziksel bağdaştırıcı ikisini de taşıyorsa, tek bir NIC işi görüyor demektir. İç yakalama boşsa sorun tünelde veya yönlendirme kurallarındadır, bağdaştırıcı sayısında değil. Topolojiyi o iki yakalama ve yönlendirme tablosundan belirleyin; bir sonraki değişikliğin karşılaştıracağı bir şey olur.