Păstrați SSH local când gazda folosește un VPN de ieșire

Un mic server Linux folosește un VPN de ieșire pentru aplicația pe care o găzduiește, iar administratorul vrea în continuare să ajungă la el prin SSH de la biroul alăturat. Este o cerință rezonabilă și de obicei nu are nevoie nici de redirecționare de porturi, nici de adresa furnizorului, nici de o gaură în tunel. Ce îi trebuie este o cale de administrare proiectată intenționat, nu moștenită din ceea ce a făcut clientul VPN cu tabela de rutare.

Pașii de mai jos presupun că administratorul este în același LAN.Administrarea la distanță este altă problemă cu alt răspuns.

Legați SSH de adresa pe care o folosesc administratorii

Începeți cu listenerul.ss -ltnp | grep :22 arată de ce este legat sshd, iar un listener pe 0.0.0.0 acceptă conexiuni de pe fiecare interfață, inclusiv tunelul. Legarea de adresa LAN este mai îngustă și face intenția vizibilă:ListenAddress 192.168.10.20 în sshd_config, urmat de un test de configurare și o reîncărcare. O greșeală de tastare în acea adresă este mai vizibilă decât un metacaracter, pentru că sshd refuză să pornească atunci când adresa nu există.

Păstrați verificarea cheii de gazdă și autentificarea pe utilizator exact așa cum sunt. „Este doar rețeaua locală“ nu este o metodă de autentificare, iar un canal de administrare care sare peste verificarea cheii pentru că ruta este scurtă este un canal de administrare care așteaptă abuzul. O rezervare DHCP sau o adresă statică face ținta previzibilă fără a o transforma în identitatea publică a serverului.

Țineți ruta LAN în afara tunelului

O gazdă cu o adresă în 192.168.10.0/24 are o rută conectată pentru acel prefix, iar o rută mai specifică învinge ruta implicită a VPN în aceeași tabelă. De aceea SSH-ul local continuă adesea să funcționeze singur când tunelul urcă. Verificați în loc să presupuneți:ip route get 192.168.10.50 numește interfața și adresa sursă pe care le-ar folosi nucleul, iar răspunsul ar trebui să fie dispozitivul LAN, nu tunelul. Repetați verificarea și de pe mașina administratorului, pentru că tabela ei decide dacă pachetele ajung vreodată. Două gazde pe același cablu pot să nu fie de acord cu privire la ce direcție este accesibilă.

Presupunerea se rupe în două locuri. O regulă de rutare bazată pe politică poate trimite traficul către o tabelă a cărei rută implicită indică în tunel înainte ca tabela principală să fie consultată. Un client VPN cu funcție de blocare sau kill switch poate bloca și traficul care nu intră în tunel, indiferent de ce spune tabela de rutare.

VLAN-urile de administrare rutate sunt celălalt caz. Dacă administratorul stă pe 192.168.50.0/24 în spatele routerului local, serverul are nevoie de o rută explicită pentru acel prefix prin 192.168.10.1, iar acea rută trebuie să supraviețuiască unei reconectări. Țineți excepția specifică pentru prefixul de administrare; o excepție largă pentru intervalele private anulează scopul tunelului.

Faceți excepția din firewall la fel de îngustă ca regula

Dacă gazda rulează un firewall, permiteți SSH doar de la sursa de administrare și doar pe interfața LAN. O regulă care permite portul 22 de oriunde este mai largă decât cerința și mai greu de justificat într-o revizuire. Pe o gazdă nftables regula aparține lanțului de intrare cu interfața și sursa potrivite; pe o gazdă iptables echivalentul este o pereche de potriviri pe -i și -s. Comentați regula cu grupul de administratori căruia îi servește, ca următorul audit să nu trebuiască să ghicească de ce portul 22 este deschis.

Verificați și filtrul propriu al clientului VPN. Unii clienți instalează reguli care aruncă traficul local prin proiectare, iar o regulă de firewall corectă peste o aruncare la nivel de client nu schimbă nimic. Citiți configurația clientului înainte de a edita firewall-ul gazdei, pentru că două filtre în serie produc o defecțiune care nu seamănă cu niciunul dintre ele.

Testați ambele stări

Rulați testul de două ori: o dată cu tunelul conectat și o dată cu el deconectat. În fiecare stare, confirmați listenerul, ruta și o autentificare SSH reală de pe mașina administratorului. O cale care funcționează doar cât timp tunelul este sus nu este o cale de administrare locală; este o coincidență.

Apoi reporniți tunelul în timp ce o sesiune SSH este deschisă. O sesiune care supraviețuiește dovedește că rutarea este stabilă; o sesiune care cade vă spune că clientul rescrie rute sau filtre la reconectare, ceea ce merită știut înainte de un incident, nu în timpul lui.

Notați adresa sursă de la care ați testat, pentru că o regulă scrisă pentru 192.168.10.50 eșuează în tăcere când laptopul administratorului se mută în altă subrețea.

Scrieți calea de recuperare în runbook

Decideți acum ce se întâmplă dacă VPN-ul de ieșire strică calea locală. Accesul la consolă, o a doua adresă de administrare sau o procedură documentată de oprire a clientului sunt toate răspunsuri legitime, și oricare dintre ele este mai bună decât descoperirea problemei în momentul în care trebuie să vă conectați. Dacă serverul este la distanță, calea locală nu există, iar proiectarea corectă este o rută de acces la distanță aprobată separat sau un bastion, nu un port public expus.

Țineți cele două roluri separate în documentație: SSH local pentru administratorul aflat în apropiere și tunelul de ieșire pentru traficul aplicației. Când acele roluri sunt scrise, o schimbare viitoare în oricare dintre ele are un loc evident unde să fie verificată, iar următoarea persoană nu trebuie să redescopere de ce un server cu VPN încă răspunde la adresa sa LAN.