VPN ve web için tek bir genel ana makine: roller nasıl bölünür

Tek bir makine üç ihtiyacı aynı anda karşılayabilir: tünelleri sonlandırmak, HTTPS'e yanıt vermek ve iki özel LAN arasında iletmek. Bunun mantıklı olup olmadığı, kâğıt üzerinde karara bağlayabileceğiniz üç şeye bağlıdır: genel adresin sahibi kim, her bağlantı noktası ve protokol çiftinin sahibi kim ve hangi sürece paket iletme izni verilmiş. Bunları doğru yaparsanız paylaşılan ana makine sıradan bir şeydir. Yanlış yaparsanız, temiz başlayan ve asla yanıt vermeyen bir hizmetle bir hafta sonu geçirirsiniz.

Aşağıdakiler bir yapı listesi değil, bir karar prosedürüdür. Her adım, yeni eklediğiniz rolün gerçekten yalıtıldığını kanıtlayan kontrolle biter.

Adresin sahibini bağlantı noktalarından önce seçin

Bir tünel uç noktası ile bir web sunucusu aynı çekirdeği paylaşabilir; aynı anda tek bir adresi, bağlantı noktasını ve protokolü paylaşmak başarısız olan şeydir. WireGuard genellikle UDP 51820 kullanır, OpenVPN UDP 1194 veya TCP 443 kullanır ve bir web sunucusu TCP 443 kullanır. Can yakan çift, HTTPS'in yanında TCP 443 üzerinden OpenVPN'dir, çünkü ikisi de aynı soketi ister ve çekirdek onu ilk bağlanana verir. Yalnızca önündeki bir çoğullayıcı, örneğin sslh veya TLS bilen bir vekil sunucu, bu bağlantı noktasını paylaşmalarına izin verir ve arızası tam olarak bir güvenlik duvarı sorunu gibi görünen bir bileşen ekler.

Herhangi bir şeyi değiştirmeden önce sahiplere bakın: ss -lntup dinleyen her soketin yerel adresini, bağlantı noktasını ve sürecini yazdırır. Gösteren iki satır 0.0.0.0:443 ikinci hizmetin hiç bağlanmadığı anlamına gelir, init betiği ne kadar neşeli olursa olsun. Köprüleme de sahibi taşır. eth0 şuna katıldığında br0, IP br0 adresine geçer ve eth0 adını anan her güvenlik duvarı kuralı eşleşmeyi bırakır, bu yüzden hizmetleri köprüye bağlayın ve ip -br addr ile doğrulayın.

Aynı sahiplik kuralı sanal makinelerde ortaya çıkan bir sürprizi açıklar. Aynı LAN'daki bir konuğun içinde çalışan tünel sunucusu konuğun adresini korur, bu yüzden ana makinenin kendi adresine yönelen bağlantılar ana makinede kalır ve konuğun tüneli onları asla görmez, istemci profili ne derse desin.

İki LAN arasında yönlendirin veya bir tarafı NAT yapın

Birbirini görmeyen iki LAN, her biri genel ana makineyi arayabilir; o da ardından tüneller arasında iletir. Bu yönlendirilmiş tasarım üç şey gerektirir: iletme açık, her uzak öneke bir yol ve geçişe izin veren bir iletme ilkesi. sysctl -w net.ipv4.ip_forward=1 ilkini kapsar, ip route add 10.20.0.0/24 dev wg1 ikincisini, ve nft add rule inet filter forward iifname "wg0" oifname "wg1" accept gibi bir nftables satırı üçüncüsünü.

Kaynak NAT eklemek daha kolay, hata ayıklamak daha zordur. Maskeleme istemcinin adresini yeniden yazar, bu yüzden uzak taraf gerçek ana makine yerine merkezi görür ve erişim kuralları ile günlükleri atıf için kullanışsız hale gelir. İki ağ da sizinse yönlendirin. Bir taraf geri dönüş yolu eklemeyecek üçüncü bir tarafa aitse NAT bu hafta çıkan seçenektir. Her durumda adres planını yazın, çünkü çakışan iki /24 hiçbir yapılandırmayla yönlendirilemez.

Kutunun bir dizüstü bilgisayar için internet çıkışı olarak hizmet etmesi, aynı kutunun gelen tünelleri sonlandırmasını engellemez. Bunu yalnızca çakışan adresler engeller ve bu yüzden adres planı önemli olan belgedir.

İki rol durdurulmuşken bölünmeyi test edin

Yararlı test çıkarmadır: iki rolü durdurun ve üçüncüsünün hâlâ yanıt verdiğini doğrulayın. Tünel hizmeti kapalıyken bir web isteği tamamlanmalı ve web sunucusu durdurulmuşken bir tünel el sıkışması tamamlanmalıdır. İkisi de yalnızca her şey çalışırken çalışıyorsa, kazara bir bağımlılığınız var: paylaşılan bir güvenlik duvarı tablosu, başıboş bir yol veya yanlış adrese işaret eden bir ad.

Üç komut bu testi somutlaştırır. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ yerel dinleyicinin harici DNS olmadan yanıt verdiğini kanıtlar, wg show istemcide el sıkışmanın tamamlandığını kanıtlar ve tcpdump -ni any port 51820 merkezde yönlendirme sorununu anahtar sorunundan ayırır. Yakalamada hiç görünmeyen bir el sıkışma ana makineden önce ölmüştür: sağlayıcı güvenlik duvarı, yanlış genel adres veya yolda bir NAT kuralı.

İletilen LAN'lar için çıkarmayı tekrarlayın. Bir eş bağlantısı kesildiğinde merkez üzerinden ping başarısız olmalıdır; yeniden bağlandığında ping bir kurala dokunmadan geri dönmelidir. Yalnızca tünel yeniden başlatıldıktan sonra geri dönen ping erişilebilirliğe değil ilkeye işaret eder ve bu başka bir düzeltmedir.

Rolleri çıkarırken kural kümesini okunabilir tutun. nft list ruleset gerçekten ihtiyaç duyduğunuz her yön için bir kabul kuralı göstermelidir ve her şeyi kabul eden bir iletme zinciri ayrıştırma değil, çalışan bir demodedir.

Yalnızca IPv6 erişim hatları ve IPv4 hizmetleri

Bazı erişim hatları yalnızca IPv6 erişilebilirliği verir ve hizmetler yine de IPv4 üzerinden yayınlanmalıdır. Tünelin kendisi hâlâ trafiği geçiren aile üzerinden gider, yayınlanan hizmet ise tünelin içindeki bir adreste oturur. Bu olağan varsayımı tersine çevirir ve izlemeyi sessizce bozar: IPv4 yolu için yazılmış bir güvenlik duvarı kuralı veya çalışma süresi denetimi artık hiçbir şey taşımayan bir arayüzü izler.

Her aileyi ayrı ayrı test edin: curl -4 ve curl -6, çünkü başarılı tek bir istek denemediğiniz yol hakkında hiçbir şey söylemez. Bağlantı noktası sahipliği aileler arasında değişmez ama dinleyici değişir: ss -lntup IPv4 ve IPv6 soketlerini ayrı satırlarda listeler ve 0.0.0.0:443 kapsamaz [::]:443 süreç çift yığınlı bir soket istemedikçe.

Bir ailede yanıt verip diğerinde reddeden hizmet genellikle bir dinleyici sorunudur, yönlendirme değil. Tasarımı bitmiş ilan etmeden önce her rolün kendi adresine veya bağlantı noktasına sahip olduğunu, iletmenin açık ve izinli olduğunu ve diğer ikisi durdurulmuşken her rolün hâlâ yanıt verdiğini doğrulayın.