Porniți un client VPN prin SSH? Fixați mai întâi propria rută
Un client cu tunel complet rescrie tabela care transportă răspunsul SSH. Fixați o rută de gazdă prin vechea poartă de acces sau rulați clientul în propriul spațiu de nume.
Vă conectați prin SSH la un host de compilare, porniți acolo clientul VPN și sesiunea nu mai răspunde. Nimic nu s-a prăbușit și nimic nu pare configurat greșit în sensul evident. Clientul a instalat o rută implicită, așa că răspunsurile către stația dumneavoastră de lucru ies acum prin tunel, unde adresa stației dumneavoastră de lucru nu este rutabilă. Partea interesantă este că acest rezultat era previzibil, iar corecția este o singură rută scrisă înainte ca clientul să pornească. Să presupunem un server cu o singură placă de rețea, o poartă de acces 192.0.2.254 și un administrator care se conectează din 203.0.113.9.
Înregistrați calea înainte de a începe
ip route show default numește poarta de acces și interfața curente, în timp ce ip route get 203.0.113.9 arată ce interfață și ce adresă sursă ar folosi nucleul pentru sesiunea dumneavoastră. Păstrați ambele ieșiri. După ce tunelul urcă, acele două comenzi ar trebui să descrie în continuare calea fizică, iar dacă descriu tunelul în schimb, sesiunea trăiește deja pe timp împrumutat.
Contează conexiunea deja stabilită, așa că nu validați doar cu o autentificare nouă. O sesiune nouă poate reuși scurt datorită unei stări pe care cea veche nu o mai are.
Fixați adresa în configurația clientului însuși
O rută adăugată manual dispare la repornire și concurează cu actualizările de tabel ale clientului însuși, așa că puneți excepția acolo unde tabela este gestionată. În OpenVPN cuvântul-cheie net_gateway se rezolvă la poarta de acces care exista înainte de tunel, așa că route 203.0.113.9 255.255.255.255 net_gateway păstrează exact o adresă în afara ei. WireGuard are nevoie de o altă abordare pentru că wg-quick gestionează singur rutele: setați Table = off și adăugați excepția în PostUp, cu un PostDown corespunzător care o elimină. Ambele forme exprimă aceeași intenție și ambele limitează excepția la o singură adresă în loc să slăbească tunelul pentru tot.
Pentru IPv6 aceeași idee ia un prefix de o singură gazdă, iar cazul transportului împachetat merită reținut: dacă conexiunea exterioară a tunelului însuși trăiește la o adresă fixă, acea adresă trebuie să rămână în afara tunelului pe care îl transportă, altfel clientul își direcționează propriul transport în el însuși.
Sau scoateți tabela principală din ecuație
Când mai multe servicii de pe gazdă trebuie să își păstreze calea normală, opriți editarea tabelei principale și dați clientului a lui. Un spațiu de nume de rețea cu o pereche veth face asta curat: ruta implicită a clientului trăiește într-un alt stiv și doar procesele pornite în interiorul lui folosesc tunelul. Rutarea bazată pe politici ajunge într-un loc similar pentru o destinație, trimițând traficul potrivit către o tabelă dedicată a cărei rută implicită indică încă poarta de acces fizică. Oricare dintre abordări lasă tabela principală a gazdei fără o rută implicită nouă, și aceasta este proprietatea care ține SSH să răspundă.
Ambele sunt mai multă mecanizare decât o singură rută de gazdă, și ambele merită când mai mult de un lucru de pe mașină trebuie să supraviețuiască tunelului.
Presupuneți că fixarea poate eșua
O rută legată de adresa dumneavoastră publică actuală se strică în momentul în care furnizorul o realocă. Un server la distanță are atunci nevoie de o cale care nu depinde de acea adresă: o consolă, o a doua interfață de administrare sau un host de salt care rămâne în afara tunelului.
Două măsuri de siguranță costă zece minute. Un watchdog care oprește clientul dacă o autentificare de confirmare nu apare în câteva minute transformă o blocare într-o întârziere, iar o a doua sesiune SSH ținută deschisă în timpul schimbării dovedește că excepția funcționează cât timp tunelul este sus. Doar keepalive nu ajută aici, pentru că calea a dispărut, nu este inactivă; ele fac doar moartea mai ușor de observat.
Verificați în ordinea care contează
Conectați tunelul, confirmați că ruta către adresa dumneavoastră iese încă prin poarta de acces fizică, apoi deschideți o sesiune nouă. Dacă sesiunea nouă funcționează și cea veche moare totuși, cauza este urmărirea conexiunilor sau un firewall cu stare, nu rutarea, ceea ce este o altă corecție.
Scrieți adresa fixată și comanda care a dovedit-o în jurnalul modificărilor. Următoarea persoană care va porni un client pe acea gazdă va avea nevoie de ambele, iar adresa s-ar putea să se fi schimbat până atunci.