VPN'iniz yalnızca oturum açtıktan sonra çalışıyor çünkü anahtarlık
Oturumunuzda çalışan bir profil, açılış zamanı hizmeti değildir. Tüneli hangi sahibin başlattığını, sırrın nerede yaşadığını ve gerçek olayı nasıl test edeceğinizi görün.
Komut oturum açtığınızda çalışır, bu yüzden onu bir başlangıç betiğine koyup eve gidersiniz. Ertesi sabah makine çevrimiçidir, tünel değildir. Efsane, çalışan bir çağrının çalışan bir hizmet olduğudur. Pratikte fark genellikle iki şeyden biridir: profil sistem yerine kullanıcı oturumunuza aittir ya da sır, ancak oturum açtıktan sonra var olan bir şey tarafından açılır. İkisi de manuel testte kusursuz çalışır ve tam da kimsenin bakmadığı anda başarısız olur.
Oturum açma neden çalışmasını sağlar
Grafik oturum açma bir oturum veri yolu ve bir sır hizmeti aracısı başlatır, ve birçok masaüstü odaklı istemci profilin parolasını veya özel anahtarın parola ifadesini orada saklar. Oturum açtıktan sonra kullanıcınız olarak çalışan bir etkinleştirme, o aracıdan sırrı isteyebilir ve başarılı olabilir. Aynı etkinleştirmeyi yürüten açılış biriminin oturumu, veri yolu ve aracısı yoktur, bu yüzden arama başarısız olur veya kimsenin görmediği bir istemde bloke olur.
Aynı profili oturum açmadan önce ve sonra çalıştırın, tek bir yapılandırmadan iki farklı sonuç alırsınız. Bu, bozuk bir tünelin değil, kimlik bilgilerine bağımlılığın imzasıdır ve bir terminaldeki manuel testin göründüğünden neden daha az kanıtladığını açıklar. Tünel iyi; sırrını açan şey eksik.
Tüneli hangi sahibin başlatacağına karar verin
Desteklenen iki kalıp vardır ve bunları karıştırmak bunun başarısız olmasının diğer yoludur. NetworkManager sistem kapsamlı bir bağlantıyı etkinleştirebilir; bu, makine ağını zaten orada merkezileştirdiğinde uygundur. Alternatif olarak, özel bir systemd birimi VPN'i doğrudan çalıştırır ve arayüzün sahibi kendisidir.
systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0
İki sahibi aynı yapılandırmaya karşı çalıştırmayın. NetworkManager arayüzü yönetiyorsa ve bir birim de onu kaldırıyorsa, rotalar ve DNS için çekişirler ve ortaya çıkan durum kimin son bitirdiğine bağlıdır.
Sırrı hizmetin okuyabileceği yere koyun
Arka plan hizmeti bir isteme yanıt veremez. Sertifika parolaları, hesap parolaları ve başvurulan kimlik doğrulama dosyaları, birimin insan olmadan ulaşabileceği, hizmeti çalıştıran hesaba ait ve diğer herkes için okunamaz bir depolama düzeni gerektirir.
Cazip kısa yol, izin hatası kaybolana kadar dosyayı herkesin okuyabileceği hale getirmektir. Bu, açılış başarısızlığını uzun süreli bir kimlik bilgisi ifşasıyla değiştirir ve kimsenin geri dönüp bakmadığı türden bir değişikliktir. Dağıtımın zaten güvendiği mekanizmayı kullanın: kısıtlı bir kimlik bilgisi dosyası, dosya izinleriyle korunan şifrelenmemiş bir anahtar veya kendi sır deposuna sahip sistem kapsamlı bir bağlantı.
Gerçekten olan olayı test edin
Hizmeti oturum açtıktan sonra manuel başlatmak neredeyse hiçbir şeyi test etmez. Yeniden başlatın veya grafik oturum açmayı bir döngü için devre dışı bırakın ve birimin kendi kendine kalkmasını izleyin. Kimlik bilgisi kullanılabilirliğini, ağ hazırlığını ve birim sırasını birlikte çalıştıran tek test budur. Aynı zamanda kullanıcının bildirdiği hatayı yeniden üreten testtir; manuel başlatma bunu asla yapmaz.
systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager
Sıra, kimlik bilgileri kadar önemlidir. Temel üst bağlantı yapılandırılmadan önce başlayan bir birim pes eder ve bazı dağıtımlar bağlantıyı bekleyip beklemedikleri konusunda farklılık gösterir. Birim açılışta arıza bildirip otuz saniye sonra elle başlatıldığında başarılı olursa, sır sorunu değil sıra sorunu bulmuşsunuz demektir.
Yalnızca arayüzü değil rotaları ve DNS'i doğrulayın
Var olan bir arayüz çalışan bir tünel değildir. Gözetimsiz bir başlatmadan sonra, bir adı kontrol etmeden önce rotaları, çözücü durumunu ve adrese göre bir hedefi kontrol edin. Ardından tünelin var olma nedenini oluşturan uygulamayı kontrol edin.
ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'
Adres çalışıyor ve ad çalışmıyorsa, kalan sorun tünel değil DNS politikasıdır. Hizmeti hangi sahibin başlattığını ve sırrın nerede yaşadığını not edin, çünkü bu makineyi bir sonraki yeniden başlatacak kişinin her iki bilgiye de ihtiyacı olacak.