Tek bir Linux ana bilgisayarında iki OpenVPN tüneli: yol kimin?

İki profil bağlı ve biri diğerine yönelik trafiği sessizce taşıyor. Bir Linux ana bilgisayarı iki OpenVPN istemciyi aynı anda zorlanmadan çalıştırabilir. Yapamadığı şey hangi sürecin hangi öneki talep edebileceğine sizin yerinize karar vermektir. Bu karar ikinci tünel açılmadan önce verilmelidir, bir kaynak yanıt vermeyi bıraktıktan sonra değil.

İkinci bağlantının yapması gereken işle başlayın

Bir profille erişilebilen bir ofis ve başka bir profille erişilebilen bir laboratuvar, iki tünelin de açık olmasını ve hiçbirinin her şeyi talep etmemesini gerektirir. İkinci profilden çıkması gereken tek bir inatçı uygulama, ikinci bir varsayılan rota yerine ilke kuralına ihtiyaç duyar. Yedek bağlantı aynı anda yalnızca bir tünel çalışmasını gerektirir, bu yüzden yedek makineyle birlikte başlamamalıdır.

Bunlar üç farklı yapılandırmadır ve karıştırılırlar çünkü üçü de aynı şekilde başlar: ikinci bir profil ve başarılı bir bağlantı. Önce amaçlanan düzeni yazın, sonra ona doğru yapılandırın. Niyet hakkında bir cümle bir saatlik paket yakalamayı kurtarır.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

İlk komut çalışan örnekleri listeler, yöneticinin dışında elle başlatılanlar dahil. İkincisi mevcut varsayılan talebi yazdırır ve bu daha sonra açıklamanız gereken durumdur.

Çakışan havuzlar yönlendirmeden önce kırılır

İki sunucu aynı 10.8.0.0/24 içinden adresleri memnuniyetle dağıtır. İstemci o zaman tek bir önek içinde iki arayüz tutar ve hangi hedefin hangisine ait olduğunu söyleyen hiçbir şey yoktur; ortaya çıkan davranış yönlendirme arızası gibi görünür ama aslında numaralandırma arızasıdır. Bir havuzu yeniden numaralandırmak bir yapılandırma düzenlemesine mal olur; sonraki her yönlendirme çözümü bir hafta sonuna mal olur. Bir rota eklemeden önce havuzu kontrol edin.

Yerel LAN'a da bakın. Bir tünelin de açığa çıkardığı 192.168.1.0/24 numaralı ev LAN'ı aynı belirsizliği üretir ve belirti, bağlantı hiç kurulmazken çözülen bir ana bilgisayar adıdır. Bu, rotaları yazdırana kadar ad çözümleme arızası gibi görünür.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

İstemciye dokunmadan önce iki çıktıyı iki sunucu yapılandırmasıyla karşılaştırın. Önekler çakışıyorsa durun ve yeniden numaralandırın, çünkü hiçbir yeniden başlatma onları ayırmaz.

Her profile kendi birimini ve her öneke bir sahip verin

Her profilin kendi örnek adı ve kendi yapılandırma dosyası vardır, bu yüzden office adlı örnek office.conf dosyasını yüklerken lab adlı örnek lab.conf dosyasını yükler. Bu eşlemeyi dizin listesine güvenmek yerine hizmet yöneticisi aracılığıyla doğrulayın, çünkü bir drop-in hangi dosyanın yüklendiğini değiştirebilir. Eşlemeyi yanlış yapmak, çalışmayan profili ayarladığınız anlamına gelir.

Sonra rotaları kimin kurduğuna karar verin. Sunucular uyumsuz kümeler ittiğinde ya itmeyi reddedin ve önekleri kendiniz listeleyin ya da bir profilin varsayılanı korumasına izin verip diğerini ilke kurallarıyla yönlendirin. İkisi de varsayılan kuran iki süreç sessiz bir kazananla ve kararın yazılı kaydı olmadan biter.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Birincisi birimi argümanlarını değiştiren herhangi bir geçersiz kılmayla gösterir. İkincisi profilin itilen rotaları kabul edip etmediğini gösterir ve bu, sonraki her şeyi belirleyen anahtardır.

İşaretler yanıtları geldikleri arayüzde tutar

Her tünel farklı kaynaklara hizmet ettiğinde bir yanıt yanlış bağlantıdan çıkabilir ve bağlantı ilk paketten sonra ölür. Dayanan desen, gelen paketleri giriş arayüzüne göre işaretlemek, bu işareti yanıtta geri yüklemek ve her işarete kendi varsayılan ağ geçidi olan bir tablo vermektir.

Gevşek ters yol filtrelemesi genellikle etkilenen arayüzler için gevşetilmelidir, çünkü yanıt ana tablonun asla seçmeyeceği bir bağlantıdan meşru olarak gelir. İşaretleri dar tutun ki tünellerin kendi şifreli trafiğini asla yakalamasınlar, bu tüneli kendi içinden gönderirdi.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Başka bir kural eklemeden önce mevcut kuralları okuyun. Yinelenen öncelikler ve unutulan tablolar, bir işaret ilkesinin hiç etkisi yokmuş gibi görünmesinin olağan nedenidir.

Bir bağlantıyı durdurarak yalıtımı kanıtlayın

İki tünel açıkken her arayüzün adresini, her tünelin arkasındaki bir ana bilgisayara giden rotayı ve ilgisiz bir hedefin izlediği yolu kaydedin. Tek bir tablo okumak yerine çekirdeğe aramayı sorun, çünkü tek bir tablo son kararı asla göstermez.

Sonra bir örneği durdurun ve diğeri devam ederken arayüzünün ve rotalarının kaybolmasını izleyin. Hayatta kalanda bir kopma, ikisinin hâlâ kimsenin ayırmadığı bir aygıt adını, rotayı veya güvenlik duvarı kuralını paylaştığı anlamına gelir.

Durmuş profili geri getirin ve aynı kontrolleri yineleyin. Bir tünel yalnızca yeniden başlatmadan sonraki ilk başlatmada hayatta kalıyorsa, yönlendirme tasarımına değil yaşam döngüsü kusuruna bakıyorsunuz.