Operatörün NAT'ı arkasındaki bir dizüstü bile, VPN sunucusu buluşma noktası olduğu sürece bir iş arkadaşına hizmet verebilir. Oraya iki mekanizma ulaşır: istemci dışarı bağlanır ve sunucudan bir dinleme portu tutmasını ister ya da sunucu bir port yayımlar ve onu tünelin içine çevirir. İkisi de aynı erişilebilirlik sorununu çözer ve arıza, gözetim ve günlükleme sırasında farklı davranır. Üç koşul hangisinin kurulumunuza ait olduğunu belirler.

İki biçim, tek buluşma noktası

İlk biçimde istemci dışarı doğru bir SSH oturumu açar ve sunucudan seçilen portta dinlemesini ister, her bağlantıyı o oturum üzerinden geri gönderir. Sunucuda hiçbir şey yönlendirilmez ve paket çevirisi olmaz, bu yüzden tek gereksinim bir SSH hesabı, izin verilen bir yönlendirme ve port için bir güvenlik duvarı kuralıdır. Hizmet istemcide loopback'e bağlı kalır, ki genellikle istediğiniz budur.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

İkinci biçimde genel port sunucuya aittir ve her bağlantıyı istemcinin tünel adresine doğru yeniden yazar. Bu, IP yönlendirmenin açık olmasını, girişte hedef çevirisini ve çıkışta kaynak çevirisini gerektirir ve hiç SSH oturumu yokken de çalışmaya devam eder. Port oturuma değil sunucuya aittir ve gerçek durumların çoğunu belirleyen özellik budur.

Biçimlerin hiçbiri yapısı gereği daha güvenli değildir. İkisi de bir hizmet portunu sunucunun genel adresine ulaşabilen herkese açar ve ikisi de hâlâ hizmetin kendi kimlik doğrulamasına bağlıdır.

Birinci koşul: port oturumdan daha uzun yaşamalı mı

Ters yönlendirme tam olarak onu oluşturan SSH oturumu kadar yaşar. Bağlantı düştüğünde dinleyici kaybolur ve iş arkadaşı yavaş bir yol yerine reddedilen bağlantı görür. Komutun systemd birimi ve yeniden başlatma politikasıyla gözetilmesi bunu çözer ve ExitOnForwardFailure=yes başarısız bağlamayı hemen görünür kılar, yönlendirmesiz çalışan bir oturum bırakmak yerine.

Çevrilmiş port, kurallar kalıcıysa yeniden başlatmalara dayanır ancak istemcinin aynı tünel adresini korumasına bağlıdır. Yeniden bağlandıktan sonra dizüstüne başka bir adres veren dinamik havuz kuralı sessizce hiçbir yere yönlendirir. Önce tünel adresini ayırın, sonra kuralı yazın ve ikisini tek bir değişiklik olarak ele alın.

Hizmet gecenin üçünde kimse bakmadan yanıt vermek zorundaysa, sunucunun yayımladığı portlu biçim daha az hareketli parçaya sahiptir, çünkü ayakta kalması gereken tek süreç tünelin kendisidir.

İkinci koşul: güvenlik duvarı ve günlükler kime ait

Ters biçim tüm politikayı iki yerde tutar. sshd AllowTcpForwarding üzerinden uzak yönlendirmelere hiç izin verilip verilmediğine karar verir ve GatewayPorts dinleyicinin loopback'e mi yoksa her adrese mi bağlanacağına karar verir. Varsayılan no ile sunucu dışındaki bir iş arkadaşı yönlendirme başarılı olsa bile porta ulaşamaz ve bu bozuk bir tünel gibi görünür, oysa gerçekte bağlama adresidir.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Çevrilmiş biçim açık yönlendirme ve iki kural gerektirir ve ikinci kural tariflerin çoğunun yanıldığı yerdir. Kaynak çevirisini conntrack durumu DNAT ile sınırlamak, yalnızca hedef kuralının oluşturduğu bağlantıların yeniden yazıldığı anlamına gelir, sunucunun tünele gönderdiği her paket değil.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Bu yeniden yazma ilişkilendirmeyi de yok eder. Sonrasında istemci her arayanı sunucunun tünel adresi olarak görür, bu da adres başına her hız sınırını tek kovaya indirger ve kimin ne gönderdiğini gizler. İlişkilendirme önemliyse bağlantıyı sunucuda sonlandırın ya da izin kararını orada tutup hizmetin güvendiği bir başlıkta kimlik aktarın. Bu iki düzeltme arasındaki seçim, hizmetin bir proxy başlığını okuyup okumamasına bağlıdır.

Üçüncü koşul: tek port mu çok mu, ad kime ait

Tek portta tek hizmet, ters yönlendirmenin emek açısından kazandığı durumdur. Bir komut, bir hesap ve bir güvenlik duvarı kuralı gerekir ve temizlik oturumu öldürmektir. Aynı genel adreste birden çok hizmet sizi sunucunun yayımladığı biçime iter, çünkü her ters yönlendirme kendi sunucu portuna ihtiyaç duyar ve küme her hizmetle büyür.

Adlar işi daha da karmaşıklaştırır. Ters yönlendirme SNI'ye göre yönlendiren bir TCP proxy'sinin arkasında olabilir, oysa çevrilmiş port genellikle hizmet başına tek porttur. Hizmet TLS'i kendisi sonlandırıyor ve özgün ana bilgisayar adına ihtiyaç duyuyorsa proxy yaklaşımı onu korur ve DNAT yaklaşımı yalnızca hizmet o adı o portta kabul ediyorsa korur.

Üç koşuldan hangisinin biçimi belirlediğini yazın. Aksi hâlde ikinci hizmeti ekleyen sonraki kişi aynı karşılaştırmayı daha az bağlamla yeniden açacaktır.

Karar verin, sonra dışarıdan test edin

Yolu dizüstüne hiç rotası olmayan bir ağdan test edin ve istek çalışırken sunucudaki sayaçları izleyin. Sunucudan kendi genel adresine doğru test etmek burada hiçbir şey kanıtlamaz, çünkü paket yerelde oluşturulur ve gelen çeviri kancasına asla ulaşmaz, bu yüzden gerçek yol bozukken test geçebilir.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Sabit kalan sayaçlar paketin kurala asla ulaşmadığını gösterir, bu da sağlayıcıya veya ana makinenin güvenlik duvarına işaret eder. Hizmet reddederken hareket eden sayaçlar istemcinin kendi güvenlik duvarına veya hizmetin dinlediği adrese işaret eder. Paketi taşıyıp hiçbir şey döndürmeyen bir tünel, rota veya dönüş yolu sorunudur, ve bu üç sonuçtan hiçbiri istemci bağdaştırıcısını düzenleyerek ayıklanmamalıdır. Herhangi bir şeyi değiştirmeden önce hangi sayacın hareket ettiğini yazın, çünkü sonraki testin o temel çizgiye ihtiyacı var.

Biçim çalıştığında portu, sahibini ve gözetim yöntemini tünel yapılandırmasının yanına kaydedin. Yalnızca birinin shell geçmişinde var olan bir erişilebilirlik düzeltmesi, tekrarlanan bir olaydan bir yeniden başlatma uzaktadır.

İlgili makaleler