Tek OpenVPN merkezi, üç LAN: adres planı ve iroute dosyaları

Üç özel LAN, hiçbir sahanın diğerlerinin iç yapısını bilmesi gerekmeden tek bir merkezde buluşabilir ve tüm tasarım dört kısa yapılandırma kararına dayanır. Bunu çalıştıran şey egzotik bir protokol özelliği değil, kimsenin tahmin etmesi gerekmeyen bir adres planı ve hangi şubenin hangi öneke sahip olduğunu merkeze söyleyen istemci başına yollardır. Bunlardan biri yanlışsa tünel yine de açılır ve hatayı şaşırtıcı yapan tam olarak budur.

Adımları sırayla izleyin. Her adım önceki adımın planına bağlıdır ve hiçbiri yeni bir sertifika otoritesi gerektirmez.

Kimsenin tahmin etmesi gerekmeyen bir planla başlayın

Bir yapılandırma dosyasına dokunmadan önce dört ayrık önek yazın: merkezin kendi LAN'ı, her şubenin LAN'ı ve dolaşan istemcilere verilen havuz. Ayrıklık, geri kalan her şeyi basit tutan şeydir, çünkü çakışan aralıklar yönlendirmeyi hiçbir istemci başına yapılandırmanın onaramayacağı en uzun eşleşme bulmacasına çevirir. Ardından her LAN için hangi makinenin varsayılan ağ geçidi olduğunu doğrulayın, çünkü kendi LAN'ının ağ geçidi olmayan bir şube yönlendiricisinin uzak yolları tamamen başka bir yere kurması gerekir. Son olarak her şubeyi tanımlayan kimliği doğrulanmış adları sabitleyin, çünkü o adlar istemci başına dosyaların arandığı anahtarlardır.

Örnek bir plan havuzu üç LAN'dan epeyce uzak tutar. Sizinki farklı olacak ve tek katı kural iki aralığın çakışmamasıdır.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Merkezin çekirdeğine şubelerin nerede olduğunu söyleyin

Merkez her şube için iki bilgiye ihtiyaç duyar: öneki tünel aygıtına gönderen bir çekirdek yolu, ve bir iroute girdisi, yani hangi istemcinin ona sahip olduğunu OpenVPN sürecine söyleyen girdi. Yalnızca çekirdek yolu paketleri tünele ulaştırır ve orada durur, çünkü arka plan süreci hangi eşin onları alması gerektiğine hâlâ karar vermelidir. Yalnızca iroute girdisi bu paketleri çekirdekte izlenecek bir yol olmadan bırakır. İki satır da arka plan sürecinin gerçekte yüklediği yapılandırmaya aittir ve başka bir şeyde hata ayıklamadan önce bunu doğrulamakta yarar vardır.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Çekirdeğin kuralların uygulama noktası olması gerektiğinde client-to-client kapalı kalsın. Bu seçenek eşler arasındaki trafiği arka plan sürecinin içinde iletir, bu da pratiktir ve aynı zamanda iletme kurallarınızın akışı hiç görmediği anlamına gelir. Aşağıdaki her şey çekirdeğin şubeler arasındaki her paketi gördüğünü varsayar.

Her şubeye ihtiyacı olan yolları verin

Her şube diğer şubelere ve merkezin LAN'ına yollar gerektirir, kendi bağlı LAN'ı için bir yol gerektirmez. Uzak önekleri her yönlendiriciye yapıştırmak yerine merkezden itin, böylece dördüncü saha daha sonra dört düzenleme yerine istemci başına tek yeni dosya demek olur. İstemci başına dosya ayrıca iroute satırını taşır, bu da sahipliği ve duyuruyu aynı yerde tutar. Dizini ve dosyalarını sunucunun yetki modeline göre okunabilir yapın, yoksa arama bir ileti olmadan başarısız olur.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Dördüncü saha aynı deseni izler: ayrı bir kimliği doğrulanmış ad, sahip olunan bir önek, merkezde bir çekirdek yolu, bir iroute girdisi ve yalnızca ona ulaşmasına izin verilen sahalara duyurular.

Bitmiş demeden önce iki yönde de test edin

Üç yönlendiricinin hepsinde IPv4 iletmeyi açın, ardından güvenlik duvarının amaçlanan akışlara iki yönde de izin verdiğini doğrulayın, çünkü tek yönlü bir test bozuk bir dönüş yoluyla herkesin beklediğinden daha sık geçer. Sahalar arasında kaynak adres çevirisi gerekmez ve özgün kaynağı korumak her şubenin bir isteğe kendi politikasını uygulamasına izin veren tam olarak odur.

Bir şube LAN'ındaki bir ana bilgisayardan diğerindeki bir hizmete test edin, sonra yönü ters çevirin, sonra bir şubeden merkezin LAN'ına test edin. Bu üç sonuç farklı kanıtlardır ve hiçbiri diğerlerini gerektirmez. Şube yönlendiricisi kendi LAN'ının varsayılan ağ geçidi değilse, uzak önekleri gerçek ağ geçidine kurun ve tünel istemcilerinin o LAN'a bağlantı başlatması gerektiğinde havuzu da ekleyin.

Planı, istemci başına dosyaları ve güvenlik duvarı kurallarını tek bir belge olarak kaydedin, çünkü bir sonraki saha eklemesi bunlara göre değerlendirilecektir.

Tasarım bir arada durur çünkü her katmanın tek bir işi vardır: plan önekleri benzersiz tutar, çekirdek yolu paketleri taşır, iroute sahibi adlandırır ve güvenlik duvarı neye izin verildiğine karar verir. Bir şey bozulduğunda o liste aynı zamanda kontrol sırasıdır.