SSH nuk dëgjon pas rinisjes: adresa VPN vjen vonë

Gjatë konfigurimit e lidhni SSH me adresën e tunelit, funksionon, dhe pas rinisjes tjetër askush nuk mund të hyjë derisa dikush ta rinisë shërbimin me dorë. Kredencialet nuk janë problemi. Daemoni i kërkoi kernelit një adresë që nuk ekzistonte ende, lidhja dështoi dhe mesazhi kaloi tutje në regjistrin e nisjes. Ajo që duket si problem vërtetimi është problem i rendit të nisjes.

Çfarë thotë në të vërtetë gabimi i lidhjes

Një socket dëgjues duhet të krijohet në një adresë që ekziston në atë moment. Kur ndërfaqja VPN shfaqet më vonë, një daemon i konfiguruar për t'u lidhur vetëm me adresën e tunelit nuk ka ku të kapet. Konfigurimi mbetet sintaksisht i vlefshëm; mjedisi thjesht nuk ishte gati. Një shërbim që punon që nga një nisje manuale nuk e kalon kurrë rrugën e nisjes, prandaj defekti shfaqet vetëm në rinisjen tjetër. Krahasoni vulën kohore të lidhjes së dështuar me vulën kohore të caktimit të adresës, dhe rendi bëhet i qartë.

Vlefshmëria e konfigurimit dhe gatishmëria në kohë ekzekutimi janë veti të veçanta. Testoni të dyja, sepse njëra prej tyre dështon pa thënë asgjë.

Cili proces zotëron portën

Daemoni nuk është gjithmonë komponenti që krijon dëgjuesin. Aktivizimi i socket-it e zhvendos atë përgjegjësi te një njësi, dhe atëherë rinisja e daemonit nuk ndryshon asgjë.

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

Lista e socket-ëve tregon cili proces mban portën dhe në cilën adresë, ndërsa dump-i i njësisë tregon nëse ekziston fare një njësi socket. Kur aktivizimi është në lojë, adresa i përket njësisë socket dhe skedari i daemonit nuk është autoritar. Lexoni regjistrin e nisjes për gabimin e vërtetë të lidhjes në vend që ta nxirrni nga simptoma. Mungesa e një njësie socket thjesht do të thotë rregullimi klasik, ku daemoni lidhet drejtpërdrejt.

Bëni gatishmërinë të qartë, jo gjumë

Një vonesë fikse është një hamendësim që i trajton njësoj harduerin e shpejtë dhe rrjetet e ngadalta. Në vend të kësaj shprehni varësinë: prisni adresën, pastaj nisni.

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

Shtoni një komandë ExecStartPre që përsëritet derisa adresa të shfaqet, ose rendisni njësinë pas objektivit specifik të rrjetit të cilit i përket ndërfaqja. Të dyja qasjet e regjistrojnë varësinë diku ku administratori tjetër mund ta lexojë. Cikli ka nevojë për një afat kohor, përndryshe një VPN i dështuar lë një njësi që varet në vend që të raportojë një defekt. Pastaj konfirmoni që daemoni lidh adresën e tunelit ndërsa ndërfaqja e zakonshme mbetet nën rregullat tuaja të filtrimit.

Testoni një nisje të pastër dhe një rilidhje

Një rinisje manuale pasi gjithçka është online nuk provon asgjë për rendin e nisjes. Rinisni makinën me tunelin e konfiguruar të ngrihet automatikisht dhe vëzhgoni nëse dëgjuesi shfaqet pa ndërhyrje.

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

Pastaj hidhni dhe rivendosni tunelin, sepse një rilidhje mund të ndryshojë adresën dhe një lidhje e koduar fort nuk do ta ndjekë. Gjatë testimit mbani një rrugë rikuperimi jashtë brezit, në mënyrë që një ndryshim i keq rendi të mos ju bllokojë jashtë hostit.

Kriteri i suksesit është një dëgjues që shfaqet nën varësinë e tij të dokumentuar, jo një që dikush kujtoi ta rinisë.