VPN değişikliğinden sonra yönlendirici yönetimi neden yanıt vermeyi bırakır

Yönlendiricide bir tüneli test etmek için bir rotayı veya güvenlik duvarı kuralını değiştirdiniz ve şimdi yönetim sayfası on dakika önce sorunsuz çalışan dizüstü bilgisayardan yanıt vermiyor. İlk tepki VPN'i suçlamaktır. Çoğu zaman tünel sağlıklıdır ve diğer üç şeyden biri bozulmuştur: yönlendiricinin kendi adresine dönüş rotası yoktur, bir giriş politikası isteği düşürür veya aradığınız adreste bir web hizmeti dinlemiyordur. Üçü de tarayıcıda aynı görünür, bu yüzden insanlar bir saat boyunca tüneli yeniden başlatır ve hiçbir şey öğrenmez.

İlk öldürülmesi gereken efsane şudur: çalışan bir tünel içeri dönüş yolu değildir. Kendi güven soruları olan yeni bir ağ bağlantısıdır ve kimsenin incelemediği yeni bir yol açarken eski yönetim yolunuzu sessizce kaldırabilir.

Tünel hiçbir zaman yönetim yolu olmadı

Yönlendirme ve giriş farklı işlerdir. "Bir istemci tünel üzerinden NAS'a ulaşabilir mi?" yönlendiriciden geçen paketlerle ilgili bir yönlendirme sorusudur. "Yönlendiricinin SSH portunu açabilir miyim?" yönlendiricinin kendisine adreslenmiş paketlerle ilgili bir giriş sorusudur. Yönlendirilen trafik için yazılmış bir izin kuralı ikinci soru için hiçbir şey yapmaz ve trafiği kusursuz taşıyan bir tünelin yönetim oturumunuzu yine de reddetmesinin en yaygın nedeni budur.

Ters hata bir arayüz adına güvenmektir. Tünel eşe şifrelenir, arkasındaki her hizmete değil ve bir arayüz etiketindeki VPN kelimesi hangi kaynakların oturum açmasına izin verilmesi gerektiği hakkında hiçbir şey söylemez.

Birinci katman: yönlendiricinin kendi adresine bir rota var mı?

İstemcide başlayın ve çekirdeğe paketin nereye gideceğini sorun. Linux'ta ip route get 10.6.0.1 seçilen rotayı, çıkış arayüzünü ve kaynak adresi yazdırır. Sağlayıcınıza doğru varsayılan rotayı bildiriyorsa paket tünele hiç girmez ve yönlendiricideki hiçbir kural onu kurtaramaz.

Tünel tarafının sorunun kendi sürümü vardır. WireGuard, AllowedIPs'i bir şifreleme anahtarı yönlendirme tablosu olarak ele alır: her uçta bir eşin hangi kaynak adreslerini kullanabileceğini ve hangi hedeflerin o eşe gönderileceğini bildirir. İstemci girdisi yönlendiricinin tünel adresini içermiyorsa istemcinin oraya rotası yoktur. O istemci için sunucu girdisi istemcinin tünel adresini kapsamıyorsa sunucu herhangi bir güvenlik duvarı kuralına bakmadan paketi düşürür.

Politikada hata ayıklamadan önce ulaşmayı beklediğiniz tam adresi doğrulayın. Eski bir DNS kaydı veya değişiklikten önce önbelleğe alınmış bir komşu girdisi sizi yönlendiricinin hiç sahip olmadığı bir adrese gönderir.

İkinci katman: giriş politikası, yönlendirme politikası değil

Güvenlik duvarları kuralları paketin geldiği arayüzde değerlendirir. pfSense ve OPNsense'te arayüz sekmesi ve kural sırası, güvenlik duvarının kendi hizmetlerine giden trafiğin izinli olup olmadığına karar verir; LAN istemcilerini internete çıkaran bir kural, tünel eşine web arayüzünü açma izni veren bir kural değildir. firewall4'lü OpenWrt'te her bölge bir giriş politikası taşır, option input 'ACCEPT' veya 'REJECT' ve girişi REJECT olan bölgedeki bir tünel arayüzü, yönlendirmeye izin veriliyorsa trafiği yönlendirmeye devam ederken yönetim bağlantılarını reddeder.

Yeni yolun çalışması için kilitlenme karşıtı kuralı devre dışı bırakmayın. O kural kötü bir kuralın LAN yönetim adresini kilitlemesini önler; LAN alt ağını korur, yeni oluşturduğunuz tünel alt ağını değil. Yöneticinin kaynağı için tek bir dar kural ekleyin ve güvenlik ağını rahat bırakın. pfSense'in yönetici erişimi belgeleri bu kontrollerin nerede olduğunu açıklar.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Üçüncü katman: o adreste dinleyen bir şey var mı?

Bir hizmet çalışıyor olabilir ve yine de erişilemez olabilir çünkü tek bir adrese bağlanmıştır. OpenWrt'nin uhttpd'si /etc/config/uhttpd içinde açık dinleme girdileri tutar, örneğin list listen_http '0.0.0.0:80'; yalnızca LAN adresine bağlanan bir derleme tünel adresinde hiçbir şey kabul etmez ve dinleme arayüzü ayarı sunan ürünler de aynı şekilde davranır. Yukarıdaki dinleme komutları buna doğrudan yanıt verir.

Ardından reddi sessizlikten ayırın. nc -vz 10.6.0.1 443 reddedilen bağlantı döndürüyorsa paket yönlendiriciye ulaştı ve bir şey onu reddetti, ya kapalı bir port ya da açık bir ret kuralı. Zaman aşımına kadar asılı kalmak paketin düşürüldüğü veya hiç yönlendirilmediği anlamına gelir. Bu fark size sıradaki hangi katmanı inceleyeceğinizi söyler ve beş saniye sürer.

Bir VPN arayüzü sınırdır, kurtarma yolu değil

Şifreleme kabloyu korur; yönetim sayfasını kimin açabileceği hakkında hiçbir şey söylemez. Tünel çalışmaya başladığında, erişilebilirliği tünel arayüzünde her şeye izin vererek çözme dürtüsüne direnin. Yöneticilere kendi tünel adreslerine bağlı bir kural veya ayrı bir yalnızca-yönetici tüneli verin ve sıradan kullanıcıları, NAS'ı, kameraları ve aile dizüstülerini yönetim portundan uzak tutun. Dosya paylaşımına ihtiyaç duyan bir eş, yönlendiricinin oturum açmasından bir kural uzakta olmamalıdır.

Yönlendiricinin rolü yanıtı değiştirir. Tüneli sonlandıran bir yönlendirici ondan yöneticileri meşru şekilde kabul edebilir, yalnızca internet çıkışı olarak tüneli kullanan bir yönlendirici ise genellikle bunu yapmamalıdır. Her iki durumda da alt ağ izni oturum açma değildir, bu yüzden hesap kimlik doğrulamasını ve taşıma güvenliğini açık tutun.

Kilitlenmeden sonra insanların yaptığı telafi hamlesi daha kötüdür: WAN yönetimini etkinleştirmek veya bir portu web arayüzüne yönlendirmek. Bu, kısa bir kesintiyi kalıcı bir maruziyete dönüştürür ve oturum açma sayfası o zaman internetteki her tarayıcıya erişilebilir olur. İzin verilen taraf kadar reddedilen tarafı da test edin, böylece yönetici erişimi olmaması gereken bir eş oturum açma istemi yerine zaman aşımı veya ret alır.

Yeni bir bağlantıyla da test edin. Durum bilgili bir güvenlik duvarı mevcut akışları durum tablosunda tutar, bu yüzden zaten açık olan SSH oturumunuz her yeni bağlantıyı engelleyen bir değişikliği atlatabilir. Kilitlenme böylece bir sonraki yeniden başlatmaya veya dizüstünün bir sonraki uykusuna kadar görünmez kalır.

Politikaya dokunmadan önce dönüş yolunu hazırlayın

İlk değişiklikten önce dört şey yazın: tünel ölürse cihaza nasıl ulaşacağınız, örneğin seri konsol, sağlayıcı konsolu veya LAN'daki bir makine; mevcut yapılandırmanın nereye aktarıldığı; hangi tek kuralı veya rotayı değiştireceğiniz; ve o öğeyi tam olarak nasıl geri alacağınız. OpenWrt'te sysupgrade -b /tmp/backup.tar.gz yapılandırmayı yakalar ve düzenlemeler uci commit çalıştırılana kadar beklemede kalır, bu da zamanında fark ederseniz size ucuz bir geri alma verir. pfSense yapılandırma geçmişi tutar ve AutoConfigBackup yalnızca önceden etkinleştirilmişse yardımcı olur. Yönlendirici fail-closed bir kural kümesi çalıştırıyorsa, planladığınız bakım yolunun o kuralın engellediği trafiğin içinde olmadığını doğrulayın ve yeniden başlatmanın kalıcı kuralları silmek yerine yeniden uyguladığını unutmayın.

Her denemede bir sınır değiştirin, sonra açık tuttuğunuz kabuk yerine yeni bir bağlantıdan test edin. Test başarısız olursa bir sonraki katmana dokunmadan önce o tek değişikliği geri alın. Tünel tüm süre ayakta kalabilir, ancak yeşil durum simgesi hâlâ girebildiğinizin kanıtı değildir.

Ayrılmadan önce hızlı kontrol:

• Yönlendiriciye yeni düzenlediğiniz kurala bağlı olmayan bir kaynaktan ulaşabiliyor musunuz?
• Tünel arayüzündeki giriş politikası yalnızca yöneticinin kaynağına izin veriyor mu?
• Yönetim hizmeti tünelde var olan bir adrese mi bağlı?
• Bir reddedilen eşi ve yeni bir oturumu test ettiniz mi?
• WAN yönetim yüzeyi hâlâ kapalı mı?