Yönlendiricide VPN mi, port yönlendirme mi: hangisi kazanır?

Yönlendirici VPN'i kendisi sonlandırır ve eski bir yönlendirme kuralı aynı UDP portunu yerel ağdaki bir makineye göndermeye devam eder. Gerçek uç nokta bunlardan yalnızca biri olabilir ve çekirdek ikisi arasında karar vermez. Hedef çevirisi, yerel hizmete başvurulmadan önce paketi yeniden yazar, bu yüzden VPN süreci başka bir yere gönderilmiş trafiği bekler. Görev, portun kime ait olduğuna karar vermek ve ardından kuralları uyumlu hale getirmektir.

Bir port, iki sahiplik iddiası

Yönlendiricinin içinde çalışan bir VPN sunucusunun kendi soketine giden bir gelen izne ihtiyacı vardır. Aynı port için hedef NAT girişi tamamen başka bir yere gider: bir yerel ağ adresi ve bir yönlendirme kararı. Bunlar farklı günlüklere ve farklı hata biçimlerine sahip farklı uç noktalardır. Olağan ipucu, bir adres ailesinin çalışıp diğerinin çalışmamasıdır, çünkü kalan giriş tek bir aile için yazılmış ve hiç yeniden gözden geçirilmemiştir.

Düzenlemeden önce iddiayı yazın: aile, dış adres, taşıma, port ve çevrilmiş hedef.

Çeviri yerel denetimden önce çalışır

Hedef NAT, çekirdek yerel teslimat ile yönlendirme arasında seçim yapmadan önce, yönlendirme öncesi aşamada paketin hedefini değiştirir. Hedef bir yerel ağ ana bilgisayarı olduğunda paket yönlendirme yolunu izler. Yönlendiricinin kendi soketi için giriş kuralları hiçbir zaman dikkate alınmaz, bu yüzden istemci beklerken VPN günlüğü boş kalır.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Bu sıra mekanizmanın tamamıdır ve cihaz arayüzleri onu değiştirmeden onay kutularının arkasına saklar. Paketin hangi yolu izleyeceğine hâlâ hedefin sahibi karar verir.

Yerel ağ ana bilgisayarı amaçlanan uç noktaysa yönlendirme doğrudur ve yönlendirici o portta da dinlememelidir.

Bir eşlemeyi tutun, diğerini kaldırın

O port ve aile için NAT girişlerini listeleyin ve hayatta kalanı seçin:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Aynı numaraya sahip bir TCP girişi UDP arızasıyla ilgisizdir ve ikisini tek bir nesne olarak ele almak yanlış kuralın silinmesine yol açar. Yerel soket kazanması gerektiğinde, çakışan eşlemenin sahibi tam o girişi kaldırır veya yeniden yazar ve yönlendiricinin kendi portu için gelen izin yerinde kalır. İlgisiz yönlendirmeler, yönetim yolu ve kural kümesinin bir kopyası değişikliği atlatmalıdır.

VPN ayrı bir ana bilgisayarda yaşıyorsa yönlendirme doğru nesnedir. Bir kapsayıcıdaki veya sanal makinedeki hizmet, kutu yönlendirici olarak adlandırılsa bile yayımlanmış bir port gerektirebilir, bu yüzden kutudaki etiketi değil soketi ve ad alanını izleyin.

Sahibini dışarıdan doğrulayın

Her aileyi ayrı ayrı test edin, çünkü yönlendiricide sona eren bir IPv6 bağlantısı, eski bir kuralın yönlendirdiği IPv4 bağlantısı hakkında hiçbir şey söylemez. Hangi uç noktanın yanıt verdiğini görmek için alıcı hizmetin günlüğünü okuyun ve istemcinin başarı iletisini zayıf kanıt sayın. Anlamlı bir test için yeni bir akış gerekir. Dış ana bilgisayardan nc -zvu 203.0.113.7 1194 ile bir sonda gönderin ve kazananın günlüğünü journalctl -u openvpn@server -n 20 ile okuyun. Yönlendiricinin dinleyicisi bağlantıyı kendisi günlüğe kaydeder, yerel ağ ana bilgisayarı ise kendi hizmetinde kaydeder.

Bağlantı izleme, mevcut akışları özgün eşlemelerinde tutar, böylece kurulmuş bir oturum yeni düzelttiğiniz kuraldan daha uzun yaşayabilir.

Amaçlanan uç nokta normal kimlik denetimleriyle yanıt verdikten sonra tünelin arkasındaki özel bir kaynağı test edin. Dış dinleyiciye ulaşmak yalnızca ilk adımdır; iç yönlendirme ve uygulama yetkilendirmesi ayrı sonuçlardır.