VPN sunucusu ve istemcisi olarak pfSense: iki yol, tek yönlendirici

Tek bir cihaz aynı anda iki yöne bakabilir: dolaşan kullanıcılar içeri bağlanır ve aynı kutu, seçilen trafik başka bir ağdan çıksın diye dışarıdaki bir çıkış sağlayıcısına bağlanır. İki hizmeti açmak dakikalar sürer; birlikte yaşamaları bir tasarım gerektirir, çünkü ikinci rol birincinin dayandığı yönlendirme tablosunu yeniden yazar. Üç koşul düzenin işleyip işlemediğini belirler: gelen hizmetin kendi dönüş yolunu koruyup korumadığı, giden tünelin hâlâ eşine ulaşıp ulaşmadığı ve iletmek istediğiniz trafiğin çıkış için seçilip seçilmediği. Birini yanlış yapın, ikisi de bağlı olduğunu bildiren ama aralarında yararlı hiçbir şey geçmeyen iki tünel elde edersiniz. Aşağıdaki denetimler her koşulu arızaların genellikle göründüğü sırayla ortaya koyar.

Herhangi bir ayara dokunmadan önce iki rolü adlandırın

Her örnek için dört olguyu yazın: uzak eşi, kimlik doğrulama malzemesi, dağıttığı adres havuzu ve arkasındaki ağlar. İki örnek cihaz üzerinde ayrı nesnelerdir ve notlarınızda da ayrı kalmalıdır. Sonradan gelen neredeyse her şaşırtıcı belirti, değerlerinin karışmasından kaynaklanır; iki örneğin tek bir not setini paylaşması, yanlış havuzun yanlış alana düşmesinin yoludur.

Gelen hizmet, giden tünelin adresleriyle ya da cihazın yönlendirdiği herhangi bir özel ağla çakışmayan bir tünel ağına ihtiyaç duyar. Çakışma, iki rolde birden belirti üreten tek hatadır ve kâğıt üzerinde yakalamak çok daha ucuzdur. Hizmetlerden birini yapılandırmadan önce iki havuzu ve yönlendirilen her özel ağı tek bir yerde karşılaştırın.

Paylaşılan donanım, paylaşılan kimlik bilgileri anlamına gelmez ve uzaktan erişim havuzundan gelen bir istemci sertifikası çıkış sağlayıcısına karşı kullanılabilir olmamalıdır. Ayrı malzeme, iptali de tüm filo için bir olay yerine yerel bir karara dönüştürür.

Sunucunun yanıtlarını WAN yolunda tutun

Cihazın kendi ürettiği yanıtlar, dikkatsiz bir varsayılan rotanın ilk kurbanıdır. Dolaşan bir kullanıcının kapsüllenmiş paketi geldiğinde, yanıt yerelde doğan trafiktir ve o kullanıcının girdiği arayüzden çıkmalıdır. Giden istemci onu yakalayan bir varsayılan rota kurmuşsa, yanıt yanlış tünele girer ve hizmet hâlâ sağlıklı görünürken oturum takılır.

Bunu çözen tek bir onay kutusu yoktur, çünkü karar giden istemcinin hangi trafiği yakalayabileceğiyle ilgilidir. Ya hiç rota çekmeyin ve yalnızca seçtiğinizi yönlendirin, ya rotaları çekin ve cihazın kendi hizmetlerini ayakta tutan istisnaları ekleyin. Seçimi örneğin yanına yazın, yoksa sıradaki kişi diğerini varsayar.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Yönlendirme tablosunu en uzun eşleşmeye göre okuyun, bir şeyi yapılandırdığınız sıraya göre değil. Soru, çıkış eşinin adresi için hangi kaydın kazandığı ve gelen hizmetin yanıtı için hangi kaydın kazandığıdır; bu iki yanıt farklı olabilir.

Giden tünelin kendi uç noktasını yemesine izin vermeyin

Giden istemci, tüneli kurmak için eşinin genel adresine ulaşmak zorundadır. O adres kendisi tünele yönlendiriliyorsa istemci kendi kuyruğunu kovalar: taşıma asla yükselmez ya da yükselip rota kurulduğu anda düşer. Günlük, yönlendirme arızasından çok kimlik doğrulama zaman aşımı gibi görünür; bu yüzden rota ilk denetimi hak eder.

Rotayı kimlik bilgilerinden önce ve tünel yükseldikten sonra bir kez daha denetleyin, çünkü bir kayıt açılışta doğru, bir dakika sonra yanlış olabilir. Eşin adresi her zamanki WAN yolunu göstermeli, asla tünel aygıtını göstermemelidir. Taşıma kararlı hale geldiğinde ilginç soru iletilen trafiğe geçer ve sıradaki karar odur.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Hangi kullanıcıların çıkışı alacağını seçin

Kaynak ilkesi, trafiğin cihaza girdiği girişe aittir, bu yüzden uzaktan erişim havuzunu ya da içindeki daha dar kimlikleri seçin. Asla çıkışa gönderilmemesi gereken özel hedefleri ve yönetim istisnalarını koruyun ve bu kuralları geniş olanın önüne koyun. Çıkış yolunun sonra kendi çevirisine ya da yönlendirilmiş bir dönüş düzenine ihtiyacı vardır; bu çoğu tasarımda havuzu kapsayan çıkış arayüzünde giden NAT anlamına gelir. Çeviri bir çıkış seçmez; yalnızca zaten çıkmış olanı yeniden yazar, bu yüzden ilgisiz bir WAN üzerindeki NAT kuralı seçimi hiç değiştirmez.

Uzak ucun bu tasarımdan iletilen trafiğe izin verdiğini doğrulayın, çünkü bazı sağlayıcılar izin verir bazıları vermez. Fark, bağlanan ama hiçbir şey taşımayan bir tünel olarak görünür; bunu yerel bir arıza diye okumak kolaydır. Üç akışı ayrı ayrı test edin, çünkü bağımsız olarak başarısız olurlar ve üçte ikisi yarım kurulmuş bir tasarımdır.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

İlk komut dolaşan kullanıcının dış bağlantısıdır ve istemci başlatma dizisinin tamamlandığını bildirdiğinde çalışır. İkincisi, o bağlı dizüstü bilgisayardan çalıştırılır ve WAN adresiniz yerine çıkış sağlayıcısının adresini bildirmelidir. Üçüncüsü cihazda havuzdan bir adrese bağlı olarak çalışır ve hiçbir uzak kullanıcıyı işe karıştırmadan iletilen trafik için kaynak ilkesini test eder. Bunun yerine WAN'dan yanıt verirse ilke eşleşmemiştir ve hiçbir NAT düzenlemesi seçim sorununu düzeltmez.

Çıkış başarısız olduğunda ne olacağına karar verin

Arıza davranışını olmadan önce yazın: giden tünel düştüğünde kullanıcılar olağan WAN'a mı döner yoksa çıkış geri gelene kadar bloke mi edilir? İki yanıt da savunulabilir ve cihaz sizin yerinize seçmez. Kaldırılmış bir rota ya da ölü bir ağ geçidini gösteren ilke otomatik olarak tamamen bloke bir sonuç üretmez. Blokaj istiyorsanız ilke bunu açıkça söylemeli ve çıkışı kaldırarak test edilmelidir, üzerine düşünerek değil. Geri dönüş istiyorsanız bunu kullanıcılara duyurun, çünkü sessizce olağan yolu seçen trafik tam olarak birinin kapsandığını sandığı trafiktir.

İstemci örneğini devre dışı bırakın, bağlı bir kullanıcının hâlâ neye ulaştığına bakın, sonra yeniden başlatın. Zaman aşımına uğrayan istek istediğiniz tam blokaj sonucudur; WAN adresiyle yanıt veren istek belgelemediğiniz geri dönüştür. Denetimi IPv6 ve DNS için yineleyin, çünkü IPv4 için yazılmış bir ilke AAAA trafiği hakkında hiçbir şey söylemez ve herhangi bir tünelin ittiği bir çözümleyici sorgunun gerçekten çıktığı yerden yanıt verir.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate'in yönlendirilmiş OpenVPN tarifi kaynak ilkesinin, arayüz atamasının ve giden çevirinin nasıl bir araya geldiğini gösterir ve siteden siteye kapsamı bütünüyle kopyalanmaması gereken kısımdır. Size söylemeyeceği şey, yukarıdaki üç koşuldan hangisinin kendi tasarımınız tarafından çoktan kırıldığıdır.