Uygun bir VPN istemci adres havuzu nasıl planlanır
Havuzu sunucu alanında seçin, ardından istemcinin gerçekte aldığı adresi okuyun, yanıtı geriye doğru izleyin ve aralık, kip, yol ile DNS kapsamını kaydedin.
VPN sunucusundaki havuz alanından başlayın, elektronik tablodan değil. Oraya yazdığınız her şey, sonradan bağlanan her istemci için iç adres alanı olur ve bu alan o istemcilerin ulaştığı LAN ile, arkasındaki yönlendirilmiş sitelerle ve istemcinin evinde zaten sahip olduğu adresle birlikte var olmalıdır. Havuz kaydedilir kaydedilmez bir istemci bağlayın, çünkü o ilk bağlantı değerin pratikte çalışıp çalışmadığını söyler. Oradan anlatım dışa doğru ilerler: istemcinin aldığı adres, bir yanıtın izlediği yol ve geride bıraktığınız kayıt.
Herhangi bir istemci bağlanmadan önce havuz alanından başlayın
Her ürün bunu farklı gösterir, bu yüzden adresleri gerçekten atayan nesneyi bulun. OpenVPN'de sıradaki boş adresi veren sunucu tarafı havuz yönergesi vardır, IKEv2 geçidinde eş yapılandırmasına bağlı bir havuz bölümü vardır ve WireGuard'da ikisi de yoktur çünkü her eş kendi adresini kendi yapılandırma dosyasında taşır. Havuz yönergesi ile eş başına adres birbirinin yerine geçmez ve yanlış olanı düzenlemek anlatının geri kalanını boşa harcar.
Alanı elde ettikten sonra zaten var olan aralıkları listeleyin: ofis LAN'ı, her yönlendirilmiş site, bulut VPC'si ve hizmette kalan başka her havuz. Çakışma, ana bilgisayar numaralarının tanıdık görünüp görünmemesiyle değil, önek aritmetiğiyle kararlaştırılır, bu yüzden toplamı bu aralıkların her biriyle karşılaştırın. İkisi de 10.x gibi görünen iki aralık, toplamları kesişmediğinde zararsız, kesiştiğinde destek olayıdır.
Ardından adresin kimin bağlandığının mı yoksa ne zaman bağlandıklarının mı işlevi olduğuna karar verin. Dinamik atama boş olanı verir, kimliğe göre atama ise sabit bir adresi bir kimlik bilgisine bağlar. Seçimi yazın, çünkü yeniden bağlanmanın sonra nasıl görünmesi gerektiğini değiştirir.
İstemcinin gerçekte aldığı adresi okuyun
Bir istemci bağlayın ve havuzun vaat ettiğini değil, tünelin bildirdiğini okuyun. İstemci iç adresini bağlantı durumunda gösterir ve Linux'ta arayüz onu doğrudan taşır.
Bu adresi kaydettiğiniz aralıkla karşılaştırın. Aralığın dışındaysa, düzenlediğinizden farklı bir atama yoluna bakıyorsunuz. Önek uzunluğunu da denetleyin, çünkü /32 taşıyan bir istemcinin bağlantı üzerinde eşi yoktur ve her hedefi varsayılan yolundan gönderir.
ip -4 addr show tun0
ip route get 192.168.50.20
Aynı aralığı kullanan bir ev yönlendiricisinden bağlanan istemci bağlanır ve ardından neredeyse hiçbir yere ulaşamaz. İstemci bu önek için yerel yolunu korur, böylece tünel adresi arkasındaki ağla çakışır ve trafik yanlış arayüzden çıkar. Bu durum sunucuda onarılamaz; belgelenmiş çare, ev ağını yeniden numaralandırmak veya çakışmaların seyrek kalması için yeterince uzak bir havuz aralığı seçmektir. Hem hatayı hem çareyi kaydedin, çünkü yardım masası onunla yeniden karşılaşacaktır.
Aynı istemciyi yeniden bağlayın ve adresi izleyin. Dinamik havuz aynı değeri ya da farklı bir değeri döndürebilir ve ikisi de doğrudur; kimliğe göre havuz ise adresi değiştiriyorsa bağı onurlandırmıyordur. Bu denetim saniyeler sürer ve ilk bölümde kaydettiğiniz kipin yürürlükteki kip olup olmadığına karar verir.
Yanıtı hizmetten geriye doğru izleyin
Havuz yalnızca yanıtlar ona geri dönebildiğinde çalışır. LAN'daki bir hizmet iç adrese yanıt verir, bu yüzden geçidinin havuz için bir yola ya da hizmetin önünde bir çeviriye ihtiyacı vardır. İstek tünelden gelip yanıt farklı bir yoldan çıktığında, durum tutan bir güvenlik duvarı ya da ters yol denetimi onu düşürür ve istemci bağlanan sonra da asılı kalan bir hizmet görür. Havuzu yönlendirme tasarımına, ana bilgisayar başına yol eklemek yerine özetlenebilir tek bir blok olarak koyun.
Çeviri, sistemin geri kalanının gördüğünü değiştirir. Kaynak yeniden yazıldığında, ana bilgisayar güvenlik duvarındaki ve uygulama günlüğündeki adres çevrilmiş olandır, bu yüzden havuz adresine karşı yazılmış bir kural hiçbir şeyle eşleşmez ve bir günlük satırı bir istemciye kadar izlenemez. strongSwan'ın iletme belgeleri bir IKEv2 geçidi için o yolun sunucu tarafındaki yarısını kapsar. DNS aynı kısıtı taşır, çünkü istemcinin ulaşamadığı bir adrese çözülen ad daha sonra ve başka bir yerde başarısız olur.
İki istemci, sonra bir iptal
İki istemciyi aynı anda bağlayın ve iki adresi de okuyun. Farklı, kullanılabilir ve havuzun içinde olmalılar ve her biri kendisi için amaçlanan hizmete ulaşmalıdır. Yinelenen adres dağıtan bir havuz genellikle ilk tek istemci testinde değil burada ortaya çıkar.
Diğer istemci bağlı kalırken bir kimlik bilgisini iptal edin, sonra hizmeti hayatta kalan istemciden deneyin. Diğer oturumu bozan bir iptal, paylaşılan duruma işaret eder; çoğunlukla tek bir kimlik bilgisi veya cihazlar arasında yeniden kullanılan tek bir adres. İptal edilen istemciyi yeniden bağlayın ve serbest kalan adresin verilmesi yerine reddedildiğini doğrulayın.
Reddedilmesi gereken bir hedefle bitirin. Her şeye ulaşan istemci bağlanmıştır, sınanmamıştır.
Dört değeri bir sonraki değişikliğin onları bulacağı yere yazın
Kayıt kısadır: havuz aralığı ve öneki, atama kipi, dönüş yolu ya da kullanımdaki çeviri ve o hedefler için yanıt veren DNS kapsamı. Bunu bilete değil sunucu yapılandırmasının yanına koyun ve tarih atın. Dördünden birini sonradan değiştiren, diğer üçünü önünde görmelidir, çünkü havuz boyutunun değişmesi yolu bozar, yolun değişmesi DNS yanıtını bozar.
Sahiplik notunu onunla birlikte tutun: tünel aralığı VPN sunucusuna aittir ve LAN'ın DHCP kapsamında yapılan bir rezervasyon tünelin içindeki bir istemci için hiçbir şey ayırmaz. O tek satır, birinin bir rezervasyon ekleyip tünel adresinin onu izlemesini beklediği en yaygın yeniden çalışmayı önler.