Site-to-site VPN’ye ikinci bir alt ağ eklemek: iki yol
Politika tabanlı tüneller iki tarafta eşleşen seçiciler ister; rota tabanlı olanlar bir rota ister. Doğru yolu seçin ve önce dönüş rotasını düzeltin.
Çalışan bir site-to-site tüneline ikinci bir alt ağ eklemek bir tasarımda beş dakika, diğerinde neredeyse bütün öğleden sonrayı alır. Tünel adını verdiğiniz önekler için rota kuruyorsa bir rota eklersiniz ve trafik onu izler. Tek bir sabit seçici çifti üzerinde anlaşıyorsa, yeni önek iki taraf eşleşen bir çift üzerinde anlaşana kadar korumasız kalır. Üç şey belirler: her tarafın yapılandırmasının gerçekte ne tanımladığı, anlaşılan trafiğin en küçük eşleşen çifte daralıp daralmadığı ve yeni aralığın dönüş rotasının kime ait olduğu.
Durum etiketini değil, çekirdeği okuyun
Bağlantı bildiren bir tünel en az bir alt ilişki kurmuştur, ama sandığınız olmayabilir. Linux ta çekirdek neyin uygulandığını gösterir: ip xfrm policy seçici çiftlerini listeler ve swanctl --list-sas (veya eski ipsec statusall) tarafların ne üzerinde anlaştığını, her yöndeki trafik seçicileri dahil gösterir. Yeni önek ikisinde de yoksa, yapılandırma dosyası ne derse desin korumasızdır.
Rota tablosuyla karşılaştırın. Rota tabanlı bir düzende tünel aygıtı korunan önekler için sonraki atlamadır. Politika tabanlı bir düzende uzak alt ağ için özel bir rota genellikle yoktur, yalnızca varsayılan rota vardır, çünkü trafiği tablo değil politika seçer.
Politika tabanlı: iki taraf da yeni öneği listelemeli
strongSwan terimleriyle seçici alt yapılandırmanın local_ts ve remote_ts alanlarında, leftsubnet ve rightsubnet ardıllarında yaşar. Yeni önek iki tarafta ayna gibi görünmelidir: A sitesinin yerel dediğine B sitesi uzak der. Uyuşmazlık nadiren temiz bir hata verir. Taraflar kesişime daralır, eski önek çalışmaya devam eder ve yalnızca yeni olan sessizce başarısız olur.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy
pfSense veya OPNsense te bu, yeni yerel alt ağı yeni uzak alt ağla eşleştiren ikinci bir Phase 2 girdisi ve ardından uygulama demektir. Eski girdiyi koruyun; değiştirmek özgün alt ağı eklemek yerine taşır. Var olan bir Phase 2 0.0.0.0/0 gibi bir üst ağı veya özetlenmiş aralığı zaten kapsıyorsa, yanına daha dar bir girdi eklemeyin: çakışan seçiciler rakip politikalar kurar ve değerlendirme sırası kazananı belirler.
IKEv1 her alt ağ çiftini kendi Phase 2 si yapar ve her değişimde tek çift alan taraf gerisini bırakır. IKEv2 tek bir alt ilişkide birkaç seçici çifti taşıyabilir, ama yalnızca iki uygulama da kabul ederse. swanctl --list-sas listesi gerçektir; yazdığınız şey bir istektir.
Rota tabanlı: rota politikanın kendisidir
Bir XFRM arayüzü veya VTI aygıtı trafiği rota tablosuna göre taşır. Yeni öneği iki sitede aygıta yönlendirirsiniz ve arayüzün dönüşümüne bağlı durum uygulanır. Eşitlenecek seçici çifti yoktur, bu yüzden bu tasarım alt ağlar çoğaldıkça daha iyi ölçeklenir. strongSwan yönlendirme kılavuzu çekirdek tarafını ayrıntılı anlatır.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10
WireGuard daha ileri gider. AllowedIPs hem kripto izin listesidir hem de wg-quick üzerinden rota tablosu girdisidir. Öneği yalnızca bir tarafa eklerseniz el sıkışma, giden paketler ve sessizlik elde edersiniz, çünkü uzak taraf kaynağı kendi listesinde olmayan paketleri atar. wg set biçimi tüm listeyi değiştirir, bu yüzden önceden çalışan önekleri yeniden yazın, yoksa onları kesersiniz:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0
İkinci komut wg-quick yerine wg set kullandıysanız isteğe bağlı değildir. Çekirdek yeni listeyi hemen kabul eder, ama hiçbir şey ona rota eklemez, bu yüzden yerelde üretilen trafik hâlâ varsayılan ağ geçidinden çıkar. Yeni bir WireGuard alt ağının tünel ana bilgisayarından çalışıp dizüstü bilgisayardan çalışmamasının en yaygın nedeni budur.
Dönüş yolu tünelden daha sık başarısız olur
Yeni uzak alt ağdaki ana bilgisayarlar yanıtları VPN ağ geçidinden geri göndermelidir. O ağ geçidi onların varsayılan yönlendiricisi değilse yanıt LAN yönlendiricisine gider, o da ya atar ya da özel kaynak adresiyle internete iletir. Ağ geçidinden değil, uzak taraftaki bir ana bilgisayardan test edin: Linux ta ip route get 10.30.20.15 veya PowerShell de Find-NetRoute -RemoteIPAddress 10.30.20.15 ana bilgisayarın gerçekte kullanacağı sonraki atlamayı gösterir. Yanıt tünelin uç noktası değilse, oraya yeni önek için statik rota ekleyin.
Dönüş rotası olmayan sitede kaynak NAT geçerli bir alternatiftir ve birçok hub-and-spoke kurulumunun her sunucuya dokunmaktan kaçınma yoludur. Hedef tarafındaki ağ geçidinde de yeni öneğe uygulayın:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE
Bedel gerçektir. Uzak günlükler tek tek kaynak adresleri göstermeyi bırakır ve özgün alt ağa bağlı güvenlik duvarı kuralları ağ geçidi için tek kurala iner. Bunu rota eksik olduğu için değil, bilerek seçin.
Güvenlik duvarları dönüş yolunun diğer yarısıdır. Bölge tabanlı aygıtlar var olan tünel arayüzünün bölgesini yeni alt ağa otomatik genişletmez ve eski önek için yazılmış kural eşleşmez. IPsec i suçlamadan önce yeni alt ağı bölgeye veya iki yönlü kural çiftine ekleyin.
Üç soruyla karar verin, sonra trafikle doğrulayın
Kısa sürüm: tarafın yapılandırması önekleri adlandırıyor mu (politika tabanlı), yoksa trafik bir arayüze mi yönleniyor (rota tabanlı)? İki uç da yeni öneği listeliyor mu? Yeni alt ağdan özgün kaynak aralığına dönüş yolu var mı?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Doğrulama, çoğu değişikliğin çok erken kapatıldığı yerdir. Ağ geçidinden ping az şey kanıtlar, çünkü ağ geçidi kendinden gönderir ve genellikle bir ana bilgisayardan farklı politikaya uyar. Yeni alt ağdaki bir ana bilgisayardan ping atın, sonra değişikliği tetikleyen uygulamayı çalıştırın ve durum simgesine değil sayaclara bakın.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show
Politika tabanlı bir tünelde ip xfrm state sayaçları iki yönde de artmalıdır; düz sayaçlar paketin yönlendirildiği ama seçilmediği anlamına gelir. WireGuard da wg show taraf başına aktarımı bildirir ve sıfır alınan baytla el sıkışma uzak tarafın listesine veya onun dönüş rotasına işaret eder.
Öneği, tarafın seçicisini veya rotasını, dönüş yolu kararını ve güvenlik duvarı girdisini tünel envanterinin geri kalanıyla birlikte kaydederek bitirin. Sonra bir ağ geçidini yeniden başlatın ve yeniden test edin: elle eklenen rota kaybolur ve sonraki kişi bunu yeniden keşfetmek zorunda kalmamalıdır.