VPN tüneli asla bağlanmıyor: paketler gerçekte nerede duruyor

Hiç oluşmayan bir tünel iki uçta da boş bir günlük bırakır. GRE, ESP veya UDP 4500'ün düşürülüp düşürülmediğini izleyin ve sunucuyu düzenlemeden önce operatör NAT'ını tespit edin.

İstemci tekrar tekrar deniyor, günlük el sıkışma tamamlanmadan duruyor ve sunucu hiçbir şey kaydetmiyor. Bu örüntü dikkati kimlik bilgilerinden uzaklaştırıp yola çeviriyor: iki uç arasında bir şey, tünelin ihtiyaç duyduğu protokolü taşımayı reddediyor. Her iki yapılandırmaya da dokunmadan önce paketlerin nerede durduğunu belirleyin, çünkü filtrelenmiş bir protokol ile yanlış parola çoğu istemcide aynı dostça hatayı üretir. Testler maliyete göre sıralanmış, en ucuz olan önce.

Trafiğin nerede durduğunu kanıtlayın

Aynı anda istemcinin giden arayüzünde ve sunucuda yakalayın. Gideni gelenle karşılaştırın ve farkın hangi yönde göründüğünü not edin.

Sunucuda hiçbir şey olmaması, yolun veya ilk NAT'ın trafiği düşürdüğü anlamına gelir; yanıtsız varışlar ise sunucudaki bir güvenlik duvarına veya var olmayan bir dönüş yoluna işaret eder. Tünelleri sık sık sonlandıran bir yönlendirici genellikle işe yarar bir günlük tutmaz, bu yüzden yakalama kaydın kendisi olur. Hedef bağlantı noktasını ve protokol numarasını yazın, çünkü her iki arıza da istemci penceresinde aynı görünür.

PPTP protokol 47 olmadan ölür

PPTP denetimi TCP 1723 üzerinden, verilerini ise GRE içinde taşır; GRE bir bağlantı noktası numarası değil, IP protokolü 47'dir. Yalnızca 1723'ü iletmek klasik sonucu verir: bağlantı kimlik doğrular ve sonra susar, çünkü yükü taşıyan protokol için hiçbir kural yoktur. İstemci bunu reddedilmiş bir paroladan ayırt edemez, bu yüzden yakalama yapılandırma değişikliklerinden önce gelmelidir.

Passthrough, gelen iletmenin ters yönünde çalışır ve yazılım çoğu zaman ikisi için aynı etiketi kullanır, herkesi şaşırtmaya yeter. Linux istemcide yerel güvenlik duvarı, yönlendirici devreye girmeden çok önce GRE'yi düşürebilir, bu yüzden protokol 47 kendi kuralına ihtiyaç duyar ve conntrack yardımcısı yüklenmiş olmalıdır. Ubuntu'nun ufw'si bu kuralları before dosyasında tutar, çünkü sıradan allow kuralları bir protokol numarasını ifade edemez. Ardından makineyi yeniden başlatmak yerine güvenlik duvarını yeniden yükleyin.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

İki NAT arkasında L2TP ve IPsec

L2TP IPsec içinde anahtar değişimi için UDP 500, NAT algılandığında UDP 4500 ve protokol 50 olarak ESP gerektirir. Bunların her biri ayrı ayrı filtrelenir, bu yüzden birine izin veren kural diğer ikisi hakkında hiçbir şey kanıtlamaz. Seri bağlı iki yönlendirici her paketi iki kez çevirir ve uçlar neyin müzakere edildiği konusunda artık anlaşamaz.

Dış modemi köprü moduna alın veya iç yönlendiricide NAT'ı kapatın, böylece genel adres tüneli sonlandıran cihaza ulaşır. İkisinin de mümkün olmadığı yerde tünel, çift NAT sınırının içinden başlatılmalı, orada sonlandırılmamalıdır.

Operatör ağları ve adres paylaşımı

WAN adresinin 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 veya 100.64.0.0/10 içinde olması, yönlendiricinin genel adresi olmadığı ve internetten gelen hiçbir iletmenin ona ulaşamayacağı anlamına gelir. Operatör düzeyindeki NAT ayrıca beklemediği protokolleri filtreler ve GRE mobil bağlantılarda sık sık kurban olur. WAN adresini yönlendiricinin kendisinde karşılaştırın, arkasındaki istemci için bir sorgu sitesinin bildirdiği adresle değil.

Aynı yönlendiriciyi kablolu hatta çalıştırmak, operatörle ilgili bulguyu tek bir testte yapılandırma hatasından ayırır. Operatör protokolü reddettiğinde kalan seçenekler 443 üzerinde başka bir taşıma veya içeriden başlatılan bir tüneldir.

Bağlantı noktalarını kapatmadan önce dinleyici listesini okuyun

Endişe verici bir bağlantı noktası taraması çoğu zaman etkin olarak gelen özellik kümesinden ibarettir. Dinleyicileri envanterleyin, her soketi bir özellikle eşleştirin, sonra bağlantı noktasını engellemek yerine özelliği kapatın, böylece iki görünüm birbirinden kopmaz.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther'in varsayılanları iyi bir örnektir: TCP 443, 992 ve 5555; L2TP/IPsec ve DNS tüneli özellikleri kendi soketlerini ekler. Bu özellikleri kapatmak dinleyicileri gizlemek yerine kaldırır ve dışarıdaki bir ana bilgisayardan yapılan test, operatörün bağlantı noktasını geçirip geçirmediğini söyler. Yerel olarak yanıt veren bir dinleyici yukarıda hâlâ kapalı olabilir, bu yüzden yönlendiricinin kendi WAN adresini harici bir hizmetin bildirdiğiyle karşılaştırın.

İlgili makaleler