Tek Pi, İki OpenVPN Örneği: Her Birim Neyi Okur
Tek bir Pi üzerindeki iki OpenVPN arka plan süreci farklı yapılandırma dosyaları okur ve farklı kancalardan çıkar. Her örneği eşleyin, ardından yük yolunu ayrı ayrı sınayın.
Bir profile dokunmadan önce OpenVPN süreçlerini sayın. Gezici kullanıcıları kabul ederken bir yandan da üst akış hizmetine bağlanan bir Pi iki arka plan süreci çalıştırır ve her biri, yazdığınız örnek adının seçtiği yapılandırma dosyasını okur. Paketin şablonları ardından her sürece kendi çalışma dizinini, kendi çalışma zamanı durum dosyasını ve kendi tünel aygıtını verir. Bu ayrımı yanlış yaparsanız, çalışan sürecin hiç açmadığı bir dosyadaki doğru ayarı değiştirerek bir akşam geçirirsiniz.
Her örnek adı kendi dosyasını seçer
OpenVPN 2.6 ile gelen birim dosyalarında, başlatma argümanları @ işaretinden sonraki metinle doldurulan bir örnek yer tutucusu taşır. Sunucu şablonu sunucu yapılandırma dizininden çalışır ve argümanını oradaki %i.conf ile çözerken istemci şablonu aynısını istemci dizininden yapar. Yani [email protected] sunucu dizinindeki admits.conf dosyasını okur ve [email protected] istemci dizinindeki uplink.conf dosyasını okur; bu adların hiçbirinin diğer dizinde bir anlamı yoktur.
Paketin üst akış varsayılanlarını koruduğunu varsaymak yerine eşlemeyi makinede doğrulayın. Dağıtımın drop-in dosyası çalışma dizinini veya yapılandırma argümanını tümüyle değiştirebilir.
systemctl cat [email protected]
systemctl cat [email protected]O çıktıdaki WorkingDirectory satırını ve yapılandırma argümanını okuyun, çünkü hangi dosyanın yükleneceğine yalnızca etkin birim karar verir. ExecStart içine --config ekleyen bir drop-in, şablon yolu doğru görünse bile şablonu yener. Yerel bir geçersiz kılmanın devrede olup olmadığını bilmek istediğinizde parça ve drop-in yollarını sorun. İki rol de tek bir dosyaya çözülürse, aynı anda hem sunucu hem istemci olmaya çalışan tek bir süreciniz olur ve o dosyadaki sonraki seçenek sessizce kazanır.
Yerel taşıma ve iletilen yük farklı kancalara çarpar
Sunucunun her gezici kullanıcıyla kurduğu şifreli bağlantı Pi'nin kendi üzerinde üretilir, bu yüzden dış yanıtları yerel çıkış kancasından çıkar. İstemcinin üst akış eşine bağlantısı da yerel olarak üretilen bir çıktıdır, uzak bir ağa ulaşsa bile. İletilen yük üçüncü kategoridir ve çekirdek onu ancak paket için bir çıkış aygıtı seçtikten sonra eşler.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
forward zinciri içinde bir çıkış arayüzüyle eşleşen bir kural, yönlendirmenin zaten o arayüze atadığı pakete izin verebilir veya onu düşürebilir, ama arayüzü hiçbir zaman seçmez. Bir ana makine bir tüneli bitirip diğerini başlattığında, kullanıcı yükünü üst akış tüneline gönderen politika ile Pi'nin kendi şifreli yanıtlarını koruyan politika iki ayrı karardır. Tesadüfen aynı fiziksel NIC üzerine düşerler, bu yüzden karıştırılırlar.
Bu ayrım yaygın bir yarım hatayı açıklar. Kullanıcılar bağlanır, el sıkışma tamamlanır ve trafikleri yine de yanlış yoldan çıkar, çünkü el sıkışma yereldi ve yük forward idi ve ikisinden yalnızca biri sınanmıştı.
İçe aktarılan bir yol kullanıcılarınıza giden yanıtları yutabilir
İstemci profilinin güvenlik ayarı, üst akışın Pi'nin yönlendirme tablosuna neyi itebileceğini belirler ve geniş bir yeniden yönlendirme, çalışan çift rollü bir ana makineyi bozuk bir ana makineye çeviren seçenektir. İtilen yol, gezici kullanıcıların genel adreslerini kapsıyorsa, sunucunun onlara doğru ürettiği yanıtlar underlay üzerinden çıkmak yerine yeni yolu izleyip üst akış tüneline girebilir. İnsanlar genellikle sağlayıcıya giden tünelin hâlâ çalıştığını doğrular ve orada durur, çünkü o trafik tünelin kendi taşımasıdır ve geri kalan her şey yanlış davranırken akmaya devam eder.
Kaynak veya mark tabanlı politika, iki akışı ayrı tutmanın yoludur. OpenVPN'in Linux mark seçeneği, sürecin kendi şifreli paketlerini bir güvenlik duvarı markıyla damgalar; bir yönlendirme kuralı bunu daha sonra ayrı bir tabloya gönderebilir. Sunucunun dış yanıtları her zaman tek bir underlay adresinden çıktığında kaynak adresler de aynı ölçüde iyi çalışır. Her iki yaklaşım da seçtiği tabloda geçerli yollar ve sağlayıcının uç noktası için bir istisna gerektirir, yoksa tünelin kendisi artık yükselmez.
Herhangi bir kural yazmadan önce çekirdeğe bir yanıtın gerçekte hangi yolu izleyeceğini sorun. Aşağıdaki adresler Pi'nin underlay adresi ve bir gezici kullanıcının genel adresi için yer tutuculardır.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Ayrımı doğrulayın, sonra rolleri tek tek durdurun
Üç akışı ayrı ayrı sınayın, çünkü çalışan bir el sıkışma diğer ikisi hakkında hiçbir şey kanıtlamaz. Yeni bir gelen bağlantı kabul edin, izin verilen bir uygulamayı üst akış çıkışından gönderin ve iki sürecin de kendi eşlerine hâlâ ulaştığını doğrulayın.
Sonra istemci rolünü durdurun ve sunucu rolünün neyi koruduğuna bakın. Tek bir örneğe yönelikken ikisine birden uygulanmış bir yol veya mark kuralını bulmanın en ucuz yolu budur.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerGörmek istediğiniz şey, istemci rolü kapalıyken dinleyicinin hâlâ bağlı olması, tünel aygıtının hâlâ bulunması ve günlüğün yeni hatalardan arınmış olmasıdır. İstemciyi durdurmak sunucunun mevcut kullanıcılara yanıtlarını da kesiyorsa, iki rol yalnızca birine ait olması gereken bir şeyi paylaşıyor demektir. Her değişikliğin hangi örneğe, hangi yapılandırma dosyasına ve hangi akış sahibine dokunduğunu kaydedin, yoksa bu ana makinede bir sonraki hata ayıklayan kişi aynı keşfi sıfırdan tekrarlar.