SSH pe o a doua cale privată în timp ce VPN-ul rămâne activ

O mașină ajunge la alta printr-un VPN, iar acum cineva vrea același shell pe rețeaua privată a unui furnizor. Ruta există, pingul reușește, iar SSH tot refuză. Cauza obișnuită este că demonul nu a ascultat niciodată pe adresa nouă, așa că nu există nimic cu care să se conecteze. Aceasta este o problemă de legare a adresei înainte de a fi o problemă de firewall.

De ce o rută nouă nu creează un ascultător nou

Un socket de ascultare este creat de un proces care numește adresele pe care va accepta conexiuni. O rută le spune doar pachetelor unde să călătorească; nu creează un ascultător la destinație. Când sshd este configurat cu un singur ListenAddress, conexiunile către orice altă adresă locală sunt refuzate chiar dacă interfața este activă. Același lucru este valabil pentru o unitate socket care deține portul, motiv pentru care prima verificare este întotdeauna ceea ce ascultă efectiv.

Comparați cele două căi după adresa de destinație, nu după numele interfeței. Un client se conectează la o adresă, iar acea adresă trebuie să fie legată înainte ca vreo regulă de firewall să conteze.

Enumerați adresele și ascultătorii

Înainte de a edita ceva, notați adresele de pe gazdă și socketurile care există acum.

ip -br addr
ss -ltnp | grep ':22'

Lista de adrese arată care adresă privată este reală și pe ce interfață, în timp ce lista de socketuri arată dacă ceva este legat de ea. Un ascultător pe 0.0.0.0:22 acceptă deja fiecare adresă, așa că o legare nouă nu adaugă nimic. Un ascultător pe o singură adresă specifică explică imediat refuzul. Dacă portul aparține unei unități socket, nu demonului, configurația demonului nu este întreaga poveste.

Adăugați legarea și păstrați-o pe cea veche

OpenSSH acceptă mai multe intrări ListenAddress, așa că calea VPN poate rămâne în timp ce se adaugă cea privată. Testați fișierul înainte de a-l reîncărca.

sshd -t
systemctl reload sshd

Un test de configurare eșuat lasă demonul în execuție neatins, și exact asta doriți în timp ce sunteți conectat prin calea pe care o editați. Păstrați intrarea existentă, adăugați noua adresă locală și confirmați că serviciul se reîncarcă fără a întrerupe sesiunea curentă. Pe instalările activate prin socket, adăugați adresa la unitatea socket în schimb și reîncărcați acea unitate. Apoi citiți din nou lista ascultătorilor, deoarece o legare care nu a apărut niciodată înseamnă că a fost editat componenta greșită.

Verificați sesiunea nouă înainte de a o închide pe cea veche

Conectați-vă la adresa nouă în timp ce sesiunea originală este încă deschisă, folosind ieșirea detaliată pentru a vedea ce adresă și ce cheie au fost folosite. Păstrați sesiunea originală deschisă până când verificarea reușește de două ori.

ssh -v [email protected]

Citiți liniile de depanare pentru adresa de destinație și cheia de gazdă prezentată. Confirmați amprenta cheii de gazdă față de o valoare în care aveți deja încredere, în loc să acceptați o cheie necunoscută pentru că rețeaua este descrisă ca privată. Noua destinație are nevoie de propria intrare known_hosts, iar acest lucru este de așteptat. Vechea sesiune de administrare ar trebui închisă doar când calea privată funcționează.

SSH protejează transportul, dar nu face două rețele echivalente de la sine. Decideți dacă încrederea tranzitului privat corespunde datelor înainte de a vă baza pe ea.