VPN bağlantı noktasını açmak istemcileri LAN’a ulaştırmaz

Bir giriş kuralı, ağ geçidinin kendisine adreslenen paketlere izin verir. İstemcinin başka bir ana bilgisayara trafiği yönlendirme, yol seçimi ve dönüş yolu gerektirir; bunlar ayrı ayrı test edilir.

Tünel açılıyor, istemci kimliğini doğruluyor, ama ağ geçidinin arkasındaki LAN görünmez kalıyor. Bunu düzeltmesi gereken kural VPN bağlantı noktasına izin veriyor ve tam yazıldığı gibi çalışıyor, çünkü o kural ağ geçidinin kendisine adreslenen paketleri yönetir. Ağ geçidinin arkasındaki ana bilgisayara giden istemci trafiğinin başka bir hedefi ve başka bir zinciri vardır. Başarılı oturum açma, çekirdeğin iki zincirden hangisine baktığını değiştirmez.

İki zincir, iki farklı hedef

Bir paketin kaderini nereye gittiği belirler, nasıl geldiği değil. Ağ geçidindeki bir adrese giden trafik yerel olarak teslim edilir ve giriş kurallarıyla değerlendirilir. Ağ geçidinin ilettiği trafik yönlendirme kurallarıyla değerlendirilir. Aynı tünel arayüzü iki tür paketi de üretebilir, bu yüzden tek bir kural iki işi kapsayamaz.

Bütün efsane tek cümlede: dinleyiciye izin vermek, arkasındaki ağa izin vermek hakkında hiçbir şey söylemez. Bunlar ayrı kanıtları olan iki ayrı karardır ve ikisinde de arayüz adı olması onları birleştirmez.

Dinleyici kuralı gerçekte neye izin verir

Dinleyici paketleri VPN sürecinde sonlanır ve tünelin kurulabilmesini asıl bu sağlar. Ağ geçidinin yönetim sayfası ve yerel tanılama yanıtı da ana bilgisayarın kendi giriş yolunu kullanır, bu yüzden ağ geçidine yapılan test başarılı olurken arkasındaki her şey başarısız olur. İki sonuç da doğrudur ve hiçbiri LAN ile ilgili değildir.

Süreç, istemci trafiğini başka bir hedef için kapsülden çıkardığında paket iletim yoluna girer ve orada izin gerekir. Başarılı kimlik doğrulama istemcinin kim olduğunu belirler; nereye gidebileceğini belirlemez. İki sorunun sahipleri, günlükleri ve hata iletileri farklıdır.

İstemciden test edin, asla ağ geçidinden değil

Ağ geçidinde üretilen test ana bilgisayarın kendi çıkış yolunu izler ve iletilen yol kapalıyken bile geçebilir. Teste istemciden başlayın ve akışın iki ucunu da izleyin.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

İstek tun0 üzerinde görünürse ve hedefe hiçbir şey ulaşmazsa, paket vardıktan sonra atılır; bu, iletim kurallarına veya hedefin kendi filtresine işaret eder. tun0 üzerinde hiçbir şey görünmezse istemci onu tünele bile göndermiyordur ve sorun ağ geçidindeki politikada değil istemcideki yönlendirmededir. Doğru çıkıp hiçbir şey döndürmeyen bir istekle karşılaştırın; dönüş yolu durumu budur.

İletim üç şey gerektirir, bir değil

Çekirdekte iletim açık olmalı, filtre kuralı akışı kabul etmeli ve hedefe ulaşılabilmeli, yanıtın döneceği bir yol bulunmalıdır. Üçünden biri eksikse istemci açısından sessizlik aynıdır.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Üç çıktıyı birlikte okuyun. Birincideki sıfır diğer ikisini anlamsız kılar ve ikincideki varsayılan atma politikası istemcinin paketlerini atarken ağ geçidinin kendi trafiği çalışmaya devam eder. Üçüncü çıktı dinleyici kuralının neden hiç sorun olmadığını gösterir.

İki kural kümesini belgelerde ayrı tutun

Dinleyici kuralını ve iletilen hizmetin kuralını ayrı satırlara, ayrı sahipler ve gerekçelerle yazın. VPN bağlantı noktası değiştiğinde veya yeni bir hizmet yayımlandığında bu ayrım, bir değişikliğin diğerini sessizce genişletmesini önler.

Her kimliği doğrulanmış eşi güvenilir bir LAN üyesi saymak yerine, ihtiyaç duyan istemci aralıkları ve hizmetler için dar kurallar kullanın. StrongSwan’ın iletim notları aynı sınırın dönüş rotası ve çeviri tarafını anlatır; bu da yine üçüncü bir karardır.

Son olarak, kullanıcı reddedildiğinde katmanları düz tutun. İstek ana bilgisayara ulaşıyor ve uygulama hesabı reddediyorsa, uygulama iznini o katmanda onarın; iletime izin vermek dosya paylaşımı kimlik bilgisi sağlayamaz ve başarıyla bağlanan diğer herkes için erişimi genişletir.

İlgili makaleler