Arayüz ayakta ama wg-quick başarısız oldu: şimdi ne yapmalı
Başarısız bir birim yarım yapılandırılmış bir tünel bırakabilir. Başarısız olan ilk adımı okuyun, temizleyeceğinize mi yoksa onaracağınıza mı karar verin ve ardından bir istekle kanıtlayın.
Birim kırmızı, arayüz var ve tünel büyük ölçüde çalışıyor; bu, mümkün olan en kafa karıştırıcı bileşim. Kurulum bir sıradır: önce arayüz oluşturulur, sonra adresler, rotalar, çözümleyici ayarları ve varsa kanca komutları gelir. Dördüncü adımdaki hata ilk üçünü yerinde bırakır, yani arayüz adı başlatmanın başladığının kanıtıdır, bittiğinin değil. Tek bir ek bilgi bu karışıklığı önlerdi: başarısız olan adım.
Kısmi durum normal hatadır
Bu davranışı bozulma saymak yerine beklemek gerekir. Arayüz kurulumun en ucuz parçasıdır ve geride bırakılması en kolay olanıdır; makineyi yarı çalışır gösteren parça da odur.
Henüz var olmayan şey, başarısız adımdan sonra gelen her şeydir. Hata çözümleyici aşamasında olduysa, adresler ve rotalar vardır, DNS yoktur. Bir rotaysa, tünelin bir adresi vardır ve içinden geçen bir yol yoktur.
Sonuç, bazı testlere yanıt veren bazılarında başarısız olan bir makinedir; bu yüzden insanlar hizmetin titrediği sonucuna varır, oysa hizmet hiçbir zaman başarıyla başlamamıştır. Hiç bitmemiş bir hizmet titreyemez. Yalnızca aynı nedenden tekrar tekrar başarısız olabilir.
Başarısız olan ilk adımı bulun
Yalnızca güncel durumu değil, birimin günlüğünü okuyun ve başarısız çalıştırmanın başından okuyun. Son satır çıkış kodunu söyler; ilk hata neyin onarılacağını söyler.
Bu komutlar birimin durumunu, o birimin önyükleme günlüğünü ve tünelin canlı durumunu yazdırır:
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0Çözümleyici hatası, zaten var olan bir rota, sıfırdan farklı kodla çıkan bir kanca ve yapılandırma ayrıştırma hatası o pencerede görünür ve her biri kendi bileşenini adlandırır. Yalnızca arayüz durumundan tahmin yürütmek tüm bu bilgiyi yok sayar.
Onarımı belirleyen üç koşul
Temizliyor musunuz, yerinde mi onarıyorsunuz yoksa birimi önyükleme yolundan mı çıkarıyorsunuz, buna karar verin ve herhangi bir şey yazmadan önce karar verin.
Arayüz bozuk ama yapılandırma doğruysa temizleyin ve yeniden başlayın. Yapılandırma yanlışsa düzeltin ve yine de önce temizleyin, çünkü kısmi durumun üzerinde ikinci bir yönetici başlatmak bir arayüz için iki sahip üretir. Hata, makinede olmayan bir çözümleyici yardımcısı gibi eksik bir sistem bileşeniyse, birimi şikâyet etmeyi bırakana kadar düzenlemek yerine bağımlılığı bilerek kurun veya kaldırın.
Bu üç durum, gizemli kırmızı bir birim gibi görünen şeylerin çoğunu kapsar. Ayırt edici soru, aynı hatanın temiz durumlu bir makinede de oluşup oluşmayacağıdır ve yanıt genellikle ilk hata satırından gelir.
Yeniden denemeden önce temizleyin
Var olan durumun üzerinde yeniden deneme yeni bir nedenle başarısız olabilir ve asıl nedeni gizleyebilir. Arayüzü onu oluşturan aynı araçla indirin, ardından hiçbir şeyin kalmadığını doğrulayın.
İlgisiz arayüzleri silmeyin ve ana makinenin ağ yığınını sıfırlamayın. İkisi de küçük bir nesneyi onarmak için büyük eylemlerdir ve tek bir başarısız tüneli, diğer bağlantıları yeniden kurulması gereken bir makineye dönüştürürler. Doğru kapsam bir arayüz ve ona sahip olan birimdir. Daha geniş her şey, olmadan önce yazılmış bir gerekçe ister.
Birimi değil tüneli kanıtlayın
Yeşil birim, başlatma dizisinin sıfırla çıktığı anlamına gelir. Bir paketin karşı tarafa ulaştığı anlamına gelmez, çözümleyicinin istediğiniz gibi ayarlandığı anlamına da gelmez.
Tünelden bir istek gönderin ve onu üreten durumu okuyun:
systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.netYanıtsız bir el sıkışma yine de tünelin oluştuğunu ve karşı tarafın sessiz olduğunu söyler; bu, hiç başlamamış bir birimden farklı bir sorundur. Birim durumunu, el sıkışmayı ve isteğin sonucunu tek bir kayıtta tutun, çünkü bunlar birbirinden bağımsız olarak başarısız olur ve sistemi yalnızca birleşimleri tanımlar.