İki hücresel saha, gelen port yok: çalışan bir merkez kurun

Hücresel bağlantılar üzerindeki iki saha her iki yönde de aynı sorunla karşılaşır: hiçbiri istenmeyen bir IPv4 bağlantısını kabul edemez, bu yüzden hiçbiri doğrudan bir tünelde sunucu rolünü üstlenemez. Çalışan mimari, ortaya erişilebilir bir üçüncü taraf koyar: her saha dışa doğru bağlanır ve orta yalnızca onayladığınız trafiği iletir. Bu orta, kendi yönettiğiniz bir yönlendirici ya da eşleri tanıştıran bir ürün olabilir ve bunlar aynı şey değildir. Aşağıdaki adımlar, her biri bir sonraki ona bağlı olmadan önce kanıt üretecek şekilde sıralanmıştır.

Hiçbir sahaya çağrı yapılamaz, bu yüzden ikisi de dışa çağrı yapmalı

Kısıtlamayı çevresinde tasarım yapmadan önce doğrulayın. Operatör WAN arayüzüne özel bir adres veriyorsa, sahanın kendi yönlendiricisindeki hiçbir port yönlendirmesi onu erişilebilir kılmaz, çünkü çeviri daha yukarıda gerçekleşir. Aynı bağlantı üzerinde genel bir IPv6 adresi bulunabilir ve tasarımı tümüyle değiştirebilir, bu yüzden kontrol her iki aileyi de kapsar. Yanıtı her saha için yazın, çünkü ikisi aynı operatörü paylaşsa bile kısıtlamaları nadiren aynıdır.

Olağan hücresel durum, operatörün çevrilmiş aralığından bir adres ve içinden geçen varsayılan bir yol gibi görünür. Bu, onarılacak bir arıza değil; merkezin var olma nedenidir. Aradığınız şey, saha önce konuşmadan üçüncü bir tarafın ulaşabildiği herhangi bir adrestir.

Önünüzdeki sahanın adresleme sorusunu iki komut yanıtlar. Bunları sahanın yönlendiricisinde çalıştırın, arkasındaki dizüstü bilgisayarda değil:

ip -4 addr show scope global
ip -6 addr show scope global

Eşleri kim tanıştırır ve paketleri kim taşır

Tanıştırma ve taşıma, ürünlerin sınırı görünür kılmadan sık sık birleştirdiği ayrı işlerdir. Bir buluşma mekanizması iki eşin aday bir yol bulmasına yardım eder; doğrudan yol yoksa bir aktarıcı paketlerini taşır. Eşleri tanıştıran bir hizmet satın almak size yönlendirici vermez ve bu fark, tasarımın bir merkeze gereksinim duyup duymadığını belirler.

Aşmanın kendi sözlüğü vardır ve sözcükler rolleri anlatır, garantileri değil. ICE belirtimi adayları ve bağlantı denetimlerini anlatır, STUN adres çevirisi hakkında bilgi edinmenin bir yolunu anlatır ve TURN onu uygulayan uygulamalar için aktarılan taşımayı anlatır. Bu mekanizmaların hiçbiri sıradan bir ağ geçidinde görünmez, çünkü onu bir keşif adresine yönelttiniz. Aşmayı bir ürün yeteneği olarak doğrulayın ve bir test aksini gösterene kadar aktarıcı varsayın.

Her saha için bir yol, bir eşin sahipliğinde

Merkez her saha için bir tünel, her birinin arkasında ayrı bir LAN öneki ve her önek için sahibini adlandıran bir yol gerektirir. Örnekte merkez 10.61.0.1, A sahası LAN 10.60.10.0/24 ile 10.61.0.11 ve B sahası LAN 10.60.20.0/24 ile 10.61.0.12'dir. Aşağıdaki her yol, öneki elinde tutan eşi gösterir, tünel arayüzünü değil:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

İletme etkin olmalıdır, yoksa paketler merkezde durur ve nedeni gösteren bir hata da olmaz. Son komut gerçek soruyu yanıtlar, çünkü kaynağı aramaya katarak paketin A sahasının LAN'ından B sahasının LAN'ına hangi yolu izleyeceğini sorar. Tünel arayüzünü adlandıran aramayı kanıt olarak, varsayılan yola düşeni ise bilmece değil eksik yol olarak ele alın. Sonra geçişi bilinçli olarak kısıtlayın, çünkü her eş arasında ileten bir merkez iki sahayı düz bir ağa dönüştürür ve sahip olduğunuzu sandığınız erişim politikası artık geçerli olmaz.

Şifrelemenin nerede bittiğine de karar verin. Merkez tünelin iki ucunu da tuttuğunda, o makinenin işletmecisi ve iş yükü güven ve kullanılabilirlik modeline katılır ve bant genişliği yolun parçası olur.

Her eşlemeyi operatör üzerinden canlı tutun

Her saha kendi tünelini başlatır ve her biri çeviri eşlemesini canlı tutmalıdır, yoksa operatör onu unutur. Başlatan taraftaki canlı tutma iletisi bu eşlemeyi el sıkışmalar arasında korur. İzin verilen önekleri merkezin adresi ve uzak LAN ile sınırlayın, böylece ele geçirilmiş bir eş sahip olmadığı bir öneki talep edemez:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Bloğu diğer sahada kendi uzak önekiyle yansıtın ve tüm tünel aralığına izin verme dürtüsüne karşı koyun. Yeni bir kaynak bağlantı noktasından durup yeniden başlayan bir el sıkışma, süresi dolmuş bir eşlemenin imzasıdır ve el sıkışmanın zaman damgaları bunun olduğunun kanıtıdır. Operatörün zaman aşımından kısa bir aralık, sürenin dolmasını sonradan onarmak yerine önler. Operatör çeviri davranışını değiştirdiğinde, bu sürelerin de onunla değişmesini bekleyin.

İki yönü de kanıtlayın, sonra kurtarmayı kanıtlayın

Doğrulama yönlüdür, bu yüzden A'dan B'ye bir ping tasarımın yarısını kanıtlar ve dönüş yolu hakkında hiçbir şey söylemez. Yanıt yolunu merkezde aynı kaynağı gözeten aramayla denetleyin, sonra testi diğer taraftan yineleyin. Taze el sıkışmalar da kanıta aittir, çünkü bir saat boşta kalmış bir tünel eski bir eşlemeyi sınıyor olabilir:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Sonra istediğiniz başarıyı değil, beklediğiniz arızayı test edin. Bir sahanın bağlantısını yeniden başlatın ve tünelin iki uca da insan eli değmeden geri döndüğünü doğrulayın, çünkü operatördeki her değişiklikten sonra operatör gerektiren bir tasarım bitmemiştir. Birincil yolu, varsa IPv6 alternatifini ve merkez erişilemez olduğunda davranışı kaydedin. Merkez artık kullanılabilirlik modelinizin bir parçası, bu yüzden bunu bir kesinti sırasında keşfetmek yerine yazın.