İki site, bir alt ağ, bir WireGuard merkezi: çalıştırın

İki site de aynı LAN aralığını kullanıyor ve tasarımı gerçekten bozan şey çakışma değil. Merkez, siteyi yalnızca hedef adresine göre seçmek zorunda ve iki aynı hedef ona seçim için hiçbir şey vermiyor. Çalışan bir ofisi tünele uydurmak için yeniden numaralandırmak, genellikle her yayımlanan hizmete tünelin taşıyabileceği ayrı bir adres vermekten daha kötü bir takas. Aşağıdaki tasarım her siteden bir HTTPS hizmeti yayımlar, başka bir şey değil.

Çakışma neden gerçek sorun değil

WireGuard hedefe göre iletir: bir eşin AllowedIPs değerleri paketin hangi eşe gideceğini belirler. İki eş aynı anda 10.10.7.0/24 duyurusu yapamaz, biri her aramayı kazanmadıkça. Bu, tünelin değil eş tablosunun bir özelliğidir, bu yüzden buradaki çözüm yönlendirme hilesi değil adres planıdır.

Plan, LAN duyurusunu tamamen bırakmak. Bunun yerine hizmet başına bir takma ad duyurun, site başına bir adres, ve her sitenin ağ geçidi bu takma adı kendi gerçek uygulamasına çevirsin.

Kullanıcı iki benzersiz adresi yönlendirir, belirsiz öneki hiç görmez ve iki ofisin hiçbirinde bir şey değişmez. Bu aynı zamanda sınırı dürüstçe söyler: her siteden bir HTTPS hizmeti yayımlıyorsunuz, iki ağı birleştirmiyorsunuz. Aşağıdaki kurallar küçük kalır çünkü ifade dar. Daha geniş bir ifade daha geniş kurallar gerektirirdi ve bu tasarımlar tam olarak böyle karmaşıklaşır.

Her siteye kullanıcının yönlendirebileceği bir takma ad verin

Adresleri kullanıcının makinesinde, merkezde veya iki LAN'ın hiçbirinde hiçbir şeyle çakışmayan bir aralıktan seçin. Burada merkez 10.66.0.1, kullanıcı 10.66.0.10, ağ geçitleri 10.66.0.21 ve 10.66.0.22, iki takma ad ise 10.77.1.20 ve 10.77.2.20. Merkez her takma adı ona sahip eş üzerinden yayımlar, böylece bir takma ada gönderilen giden paket yalnızca eşleşen siteden çıkabilir:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

Kullanıcı tarafı yalnızca iki takma ada ihtiyaç duyar, bu da istemci yapılandırmasını iki LAN önekinden de uzak tutar. O yapılandırmada hiçbir şey gerçek LAN'ların hiçbirini anmaz:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Her ağ geçidi merkezi ve kullanıcının kaynağını duyurur, başka bir şeyi değil, böylece bir site hiçbir zaman diğer sitenin LAN'ını öğrenmez. Keepalive sitenin üst bağlantısında bir NAT eşlemesi sürdürür; trafiğe izin vermez ve güvenlik duvarı neyin kabul edileceğine hâlâ karar verir. Bir ağ geçidinin yapılandırmasını diğerine kopyalamak, özel anahtar, arabirim adresi ve takma ad hepsi değiştiği sürece sorun değildir.

Merkez iki eşi arasında neye izin vermeli

Merkez paketleri kendi iki eşi arasında iletir, bu forward zincirinde bir karardır, giriş kararı değil. IPv4 iletimini platformun olağan mekanizmasıyla etkinleştirin, sonra tasarımın ihtiyaç duyduğu çiftlere tam olarak izin verin.

Aşağıdaki kural kullanıcının bir takma ada ve bir bağlantı noktasına erişmesine izin verir ve bağlantı izleme yoluyla dönüş trafiğine izin verir. Forward yolundaki diğer her şeyi düşürür ve asıl mesele budur:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

İki ayrıntı belirtilmeye değer çünkü sessiz arızalara yol açarlar. Bir temel zincirdeki accept, başka bir zincirdeki drop'u geçersiz kılmaz, bu yüzden bunu mevcut politikayla birleştirin, yanına yüklemeyin. Ve kaynak adresi kişiyi değil cihazı tanımlar; uygulama kimlik doğrulamasını ağ kabulünden ayrı tutun.

Takma adın gerçek adrese dönüştüğü yer

Site A, 10.77.1.20 için bir istek alır, hedefi gerçek uygulamaya yeniden yazar ve kaynağı kendi LAN adresine yeniden yazar, böylece yanıt tünele giden bir yol olmadan dönebilir. İki çeviriyi tek yerde yapmak ağın geri kalanını takma addan habersiz tutar. Aşağıdaki kurallar mekanizmanın tamamıdır:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Ardından site A'nın forward politikası çevrilmiş akışı tünel arabiriminden LAN arabirimine, artı dönüş yönünü kabul etmelidir. forward hook hedefi hedef çevirisinden sonra ve kaynak yeniden yazımından önce görür, bu yüzden kural gerçek uygulamanın adresini belirtir. Bir kural hiçbir şeyle eşleşmiyor gibi göründüğünde bu iki hook'u bu sırayla okuyun. Takma ada karşı yazılmış bir forward kuralı asla eşleşemez, çünkü takma ad o hook'ta artık yoktur.

Site B bunu kendi takma adı ve kendi anahtarıyla yineler. Site A'nın özel anahtarını yeniden kullanmamalıdır, çünkü iki eşin tek bir kimliği paylaşması, görülmesi zor ve bir dosyayı kopyalayarak oluşturulması kolay bir yapılandırma hatasıdır. İki ağ geçidi belgesini değişmesi gereken değerler dışında aynı tutun, böylece incelemede fark öne çıksın. Kopyalanmış dosya bu hatanın olağan kaynağıdır.

Kaynağı yeniden yazmanın bir bedeli vardır. Uygulama ağ geçidini kendi istemcisi olarak görür, bu yüzden günlükleri artık hangi kullanıcının bağlandığını göstermez. Ağ geçidinin denetim izini koruyun ve çevirinin kaldırdığı bir ağ kimliğini telafi etmek için uygulama oturum açmasını zayıflatmayın.

Yayımlanan iki adın da yanıt verdiğini nasıl kanıtlarsınız

Her takma ada bir DNS adı verin ve uygulamayı ve sertifikayı o ad için yapılandırın, çünkü çeviri yönlendirmeleri veya gömülü mutlak URL'leri yeniden yazmaz. Site başına bir ad kullanın, böylece sertifika uyuşmazlığı asla yönlendirme arızasıyla karıştırılmasın.

Gerçek istemciden test edin, hangi sitenin yanıt verdiğini doğrulayın ve yetkisiz bir bağlantı noktasını da test edin. Herhangi bir NAT değişikliğinden sonra yeni bağlantılar kullanın, çünkü kurulmuş durum eski eşlemeyi korur:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

İlk komutta boş veya beklenmeyen bir takma ad, herhangi bir güvenlik duvarı kuralı önem kazanmadan önce eş seçiminin yanlış olduğu anlamına gelir. Takma ad doğruysa ve ad hâlâ başarısız olursa sorun DNS ve sertifikalara taşınmıştır. İki ad da yanıt verdiğinde ve üçüncü bağlantı noktası kapalı kaldığında, tasarım iddia ettiğini yapar: dar biçimde yayımlanmış iki hizmet, birleştirilmiş iki LAN değil.