SSH yenidən başlatmadan sonra dinləmir: VPN ünvanı gecikir
Tunel ünvanına bağlanan xidmət həmin ünvana bağlanma anında ehtiyac duyur. Açarları redaktə etməzdən əvvəl dinləyicinin sahibini, yükləmə sırasını və bağlanma xətasını yoxlayın.
Quraşdırma zamanı SSH-ı tunel ünvanına bağlayırsınız, işləyir, və növbəti yenidən başlatmadan sonra kimsə xidməti əl ilə yenidən başlatmayana qədər heç kim daxil ola bilmir. Etibarnamələr problem deyil. Demon nüvədən hələ mövcud olmayan ünvan istədi, bağlanma alınmadı və mesaj yükləmə jurnalında ötüb keçdi. Autentifikasiya problemi kimi görünən şey əslində başlama sırası problemidir.
Bağlanma xətası əslində nə deyir
Dinləmə soketi həmin anda mövcud olan ünvanda yaradılmalıdır. VPN interfeysi sonra qalxdıqda, yalnız tunel ünvanına bağlanmaq üçün konfiqurasiya edilmiş demonun bağlana biləcəyi heç nə olmur. Konfiqurasiya sintaktik cəhətdən etibarlı qalır; sadəcə mühit hazır deyildi. Əl ilə başlatmadan bəri işləyən xidmət heç vaxt yükləmə yolunu sınamır, buna görə də nasazlıq yalnız növbəti yenidən başlatmada görünür. Bağlanma uğursuzluğunun vaxt möhürünü ünvan təyininin vaxt möhürü ilə müqayisə edin və sıra aydın olacaq.
Konfiqurasiya etibarlılığı və işləmə hazırlığı ayrı xüsusiyyətlərdir. Hər ikisini yoxlayın, çünki biri heç nə demədən uğursuz olur.
Portu hansı proses saxlayır
Demon həmişə dinləyicini yaradan komponent deyil. Soket aktivasiyası bu məsuliyyəti vahidə keçirir və sonra demonu yenidən başlatmaq heç nəyi dəyişmir.
ss -ltnp 'sport = :22'
systemctl cat ssh.socketSoket siyahısı portu hansı prosesin və hansı ünvanda saxladığını göstərir, vahid çıxarışı isə ümumiyyətlə soket vahidinin olub-olmadığını göstərir. Aktivasiya işə düşdükdə ünvan soket vahidinə aid olur və demon faylı səlahiyyətli deyil. Həqiqi bağlanma xətası üçün yükləmə jurnalını oxuyun, onu simptomdan çıxarmayın. Soket vahidinin olmaması sadəcə klassik düzən deməkdir, burada demon birbaşa bağlanır.
Hazırlığı açıq et, yuxu yox
Sabit gecikmə sürətli aparatı və yavaş şəbəkələri eyni cür qiymətləndirən bir təxmindir. Bunun əvəzinə asılılığı ifadə edin: ünvanı gözləyin, sonra başlayın.
ip -4 addr show dev tun0
systemctl edit ssh.serviceÜnvan görünənə qədər təkrarlanan ExecStartPre əmri əlavə edin və ya vahidi interfeysə sahib olan xüsusi şəbəkə hədəfindən sonra sıralayın. Hər iki yanaşma asılılığı növbəti administratorun oxuya biləcəyi yerdə qeyd edir. Döngəyə taymaut lazımdır, əks halda uğursuz VPN nasazlıq bildirmək əvəzinə asılı qalan vahid buraxır. Sonra demonun tunel ünvanına bağlandığını, adi interfeysin isə filtr qaydalarınızla idarə olunduğunu təsdiqləyin.
Təmiz yükləməni və yenidən qoşulmanı yoxlayın
Hər şey onlayn olduqdan sonra əl ilə yenidən başlatma yükləmə sırası haqqında heç nə sübut etmir. Tunel avtomatik qalxmaq üçün konfiqurasiya edilmiş halda maşını yenidən başladın və dinləyicinin müdaxiləsiz görünməsini izləyin.
systemctl status ssh.service
ss -ltnp 'sport = :22'Sonra tuneli qoparın və yenidən qurun, çünki yenidən qoşulma ünvanı dəyişə bilər və sərt kodlanmış bağlanma onu izləməyəcək. Sınaq zamanı bantdan kənar bərpa yolu saxlayın ki, pis sıra dəyişikliyi sizi hostdan kilidləməsin.
Uğur meyarı sənədləşdirilmiş asılılığı altında görünən dinləyicidir, kimsənin yenidən başlatmağı xatırladığı biri deyil.