Sunucu mu istemci mi: çift rollü Pi'de hangi OpenVPN birimi

Bir Pi üzerinde, aynı anda dolaşan kullanıcıları kabul eden ve üst sağlayıcıya ulaşan iki OpenVPN süreci çalışır ve donanım dışında neredeyse hiçbir şeyi paylaşmazlar. Biri gelen tünelleri dinlerken diğeri dışarıya bağlanır. Her biri kendi dizinini okur ve her birinin kendi arıza biçimi vardır. Yanlış olanı yeniden başlatmak, bir istemci düzeltmesinin bunun yerine dinleyiciyi sarsmasıyla bitmesinin en yaygın yoludur.

Birimin adını yüklediği dizinle eşleştirin

Upstream 2.6 iki şablon birimi sunar, [email protected] ve [email protected]. Sunucu şablonu /etc/openvpn/server içinde başlar ve oradan %i.conf yükler. İstemci şablonu /etc/openvpn/client içinde başlar. roaming adlı örnek aynı anda her iki yerde de bulunabilir; hem sunucu hem istemci olarak, birbiriyle ilgisiz iki yapılandırmayla ve aralarında dizeden başka hiçbir bağ olmadan.

Dosya sistemi yerine systemd'ye sorun, çünkü paketleyiciler çalışma dizinini veya ikilinin aldığı bağımsız değişkenleri değiştirebilecek ek dosyalar ekler.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

İlk komut, başarısız olup yüklü kalanlar dahil, oluşturulmuş her birimi listeler. İkincisi birim dosyasını herhangi bir geçersiz kılmayla birlikte yazdırır. Üçüncüsü, soruyu belirleyen iki olguyu görmenin en hızlı yoludur: sürecin başladığı dizin ve ona verilen yapılandırma yolu.

Paket yönüne göre karar verin, arayüz adına göre değil

Bir sunucu örneği dinleyen bir sokete sahiptir ve bağlantıları kabul eder. Şifreli taşıması Pi üzerinde yerel giriş ve yerel çıkıştır; kullanıcılar için ilettiği trafik ise iletme yolunu izler ve başka bir kural kümesine uyar. Bir istemci örneğinin o anlamda dinleyicisi yoktur: bir eşe bağlanır, bu yüzden şifreli taşıması alt katmana doğru yerel çıkıştır.

Bu fark, bir kuralın nereye ait olduğunu söyler. İletme zinciri içindeki bir arayüzle eşleşen kural yalnızca yönlendirmenin zaten seçtiği trafiğe izin verir; yolu asla kendisi seçmez. Dolaşan kullanıcının paketleri yanlış yoldan çıktığında incelenecek zincir forward'dır, output değil.

Teorileştirmeden önce soketlere bakın. udp/1194'e bağlı bir sunucu dinleyen bir soket gösterir. İstemci ise sağlayıcının adresine bir ilişkilendirme gösterir ve dinleyen hiçbir şey yoktur.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Bir örneğin varsayılan yolu diğerinin yanıtlarını yakalayabilir

Üst istemcinin ittiği bir redirect-gateway, makinedeki her şeyle yarışan bir varsayılan yol kurar; buna sunucunun dolaşan kullanıcılara gönderdiği yanıtlar da dahildir. OpenVPN tünelin erişilebilir kalması için kendi eş adresine bir istisna tanır, ancak bu istisna otel ağındaki bir telefon hakkında hiçbir şey söylemez.

Belirti genellikle asimetriktir. El sıkışma tamamlanır, istemci bağlandığını bildirir ve trafik ilk yanıt paketinden sonra ölür. Kaynak tabanlı ilke yönlendirmesi veya sunucu örneğinde --mark ile ayarlanan bir paket işareti iki akışı ayrı tutar; ikisi de tek başına eksiksiz bir kural kümesi değildir ve her ikisi de seçtikleri tabloda geçerli yollara ihtiyaç duyar.

Tünelin durumu yerine yerel kararı test edin, çünkü çekirdek kaynağı ve arayüzü OpenVPN paketi görmeden önce seçer.

ip route get 203.0.113.44
ip rule show

Bir rolü yeniden başlatın ve diğerinin hayatta kaldığını kanıtlayın

Her iki rol de aynı alt katmana bağlı olduğunda sıra önemlidir. Kullanıcı trafiği iletilebilemeden önce üst yolun var olması gerekiyorsa önce istemciyi yeniden başlatın; yalnızca dinleyicisini veya havuzunu değiştiriyorsanız önce sunucuyu yeniden başlatın. Her durumda sonrasında iki birimi de doğrulayın, çünkü başarısız bir yeniden başlatma diğer rolü eskimiş durumla çalışır bırakabilir.

Değişiklikten önce durma koşulunu yazın: üst tünelin kaybı dolaşan kullanıcıları engelliyor mu, yoksa Pi'nin kendi üst bağlantısına mı düşüyor? DNS ve IPv6 da açık bir yanıt gerektirir, çünkü itilen bir çözümleyici onu yararlı kılan yoldan çoğu zaman daha uzun yaşar.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Değişikliği yalnızca üç şey aynı anda doğru olduğunda kabul edin: yeni bir gelen bağlantı tamamlanır, iletilen bir uygulama amaçlanan çıkıştan hedefine ulaşır ve iki süreç hâlâ beklenen eşlerini bildirir. Üçünden biri başarısız olursa yanlış örneği veya yanlış yolu değiştirdiniz ve sonraki adım başka bir şeyi yeniden başlatmak değil, birimi yeniden okumaktır.