Yeniden başlatmadan sonra SSH dinlemiyor: VPN adresi geç geliyor

Kurulum sırasında SSH'ı tünel adresine bağlarsınız, çalışır, ve bir sonraki yeniden başlatmadan sonra biri servisi elle yeniden başlatana kadar kimse giriş yapamaz. Kimlik bilgileri sorun değildir. Daemon çekirdekten henüz var olmayan bir adres istedi, bağlama başarısız oldu ve mesaj önyükleme günlüğünde kayboldu. Kimlik doğrulama sorunu gibi görünen şey aslında bir başlatma sırası sorunudur.

Bağlama hatası gerçekte ne söylüyor

Dinleyen bir soket, o anda var olan bir adres üzerinde oluşturulmalıdır. VPN arayüzü daha sonra ortaya çıktığında, yalnızca tünel adresine bağlanacak şekilde yapılandırılmış bir daemonun tutunacak bir şeyi yoktur. Yapılandırma sözdizimsel olarak geçerli kalır; ortam yalnızca hazır değildi. Elle başlatmadan beri çalışan bir servis önyükleme yolundan asla geçmez, bu yüzden arıza yalnızca bir sonraki yeniden başlatmada ortaya çıkar. Başarısız bağlamanın zaman damgasını adres atamasının zaman damgasıyla karşılaştırın, sıra belirginleşir.

Yapılandırma geçerliliği ve çalışma zamanı hazırlığı ayrı özelliklerdir. İkisini de test edin, çünkü biri hiçbir şey söylemeden başarısız olur.

Bağlantı noktasını hangi süreç sahipleniyor

Daemon her zaman dinleyiciyi oluşturan bileşen değildir. Soket etkinleştirmesi bu sorumluluğu bir birime taşır ve o zaman daemonu yeniden başlatmak hiçbir şeyi değiştirmez.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

Soket listesi hangi sürecin bağlantı noktasını hangi adreste tuttuğunu gösterirken, birim dökümü bir soket biriminin olup olmadığını gösterir. Etkinleştirme işin içindeyse adres soket birimine aittir ve daemon dosyası yetkili değildir. Bağlama hatasını belirtiden çıkarmak yerine gerçek hatayı önyükleme günlüğünden okuyun. Soket biriminin olmaması yalnızca daemonun doğrudan bağlandığı klasik düzeni ifade eder.

Hazırlığı açık hale getirin, uyku değil

Sabit gecikme, hızlı donanımı ve yavaş ağları aynı şekilde ele alan bir tahmindir. Bunun yerine bağımlılığı ifade edin: adresi bekleyin, sonra başlatın.

ip -4 addr show dev tun0
systemctl edit ssh.service

Adres görünene kadar yinelenen bir ExecStartPre komutu ekleyin veya birimi arayüze sahip olan belirli ağ hedefinden sonra sıralayın. Her iki yaklaşım da bağımlılığı bir sonraki yöneticinin okuyabileceği bir yere kaydeder. Döngünün bir zaman aşımına ihtiyacı vardır, aksi halde başarısız bir VPN arıza bildirmek yerine asılı kalan bir birim bırakır. Ardından daemonun tünel adresini bağladığını ve normal arayüzün filtre kurallarınız altında kaldığını doğrulayın.

Temiz bir önyükleme ve yeniden bağlanmayı test edin

Her şey çevrimiçi olduktan sonra elle yeniden başlatma, önyükleme sırası hakkında hiçbir şey kanıtlamaz. Tünel otomatik olarak açılacak şekilde yapılandırılmış halde makineyi yeniden başlatın ve dinleyicinin müdahale olmadan ortaya çıkıp çıkmadığını izleyin.

systemctl status ssh.service
ss -ltnp 'sport = :22'

Sonra tüneli düşürün ve yeniden kurun, çünkü yeniden bağlanma adresi değiştirebilir ve sabit kodlanmış bir bağlama bunu izlemez. Test sırasında bant dışı bir kurtarma yolu tutun, böylece kötü bir sıra değişikliği sizi ana makineden kilitleyemesin.

Başarı ölçütü, belgelenmiş bağımlılığı altında ortaya çıkan bir dinleyicidir; birinin yeniden başlatmayı hatırladığı bir dinleyici değil.