ifconfig-noexec nu îți salvează sesiunea SSH: ce face de fapt

Într-un fir de forum, ifconfig-noexec este oferit ca soluția care ține în viață o sesiune SSH când urcă un tunel. Raționamentul sună plauzibil până când verifici ce atinge de fapt opțiunea. Îl împiedică pe OpenVPN să configureze adresa interfeței tunelului și predă acele valori unor scripturi; despre unde ajung răspunsurile la conexiunea ta de administrare nu spune nimic. A crede contrariul produce un tunel fără adresă utilizabilă și o sesiune SSH care tot moare.

Ce deleagă de fapt opțiunea

Implicit, clientul ridică dispozitivul tunelului și atribuie adresele locală și la distanță pe care i le-a dat serverul. Cu ifconfig-noexec setat, pasul este omis, iar valorile negociate sunt exportate în mediul scripturilor pentru ca altceva să le poată aplica.

Proprietatea se mută. În locul ei nu se inventează nimic.

Așadar, întrebarea la care răspunde opțiunea este cine configurează interfața, iar întrebarea la care nu răspunde este cum găsesc pachetele drumul înapoi la tine. Ține cele două separate, altfel petreci o seară întreagă editând rute ca să compensezi o interfață fără adresă.

Trei opțiuni asemănătoare cu sarcini diferite

Familia este ușor de confundat pentru că numele diferă printr-un singur cuvânt, iar simptomele se suprapun. Citește ce suprimă fiecare înainte de a alege vreuna.

Acestea sunt alternative de înțeles separat, nu un set de lipit la un loc. Suprimarea configurării adresei nu suprimă modificările de rută, regulile de firewall sau opțiunile împinse care transportă DNS. Un script delegat este și liber să schimbe rute, ceea ce este o decizie pe care o predai în loc să o eviți.

Dacă un client de la furnizor înfășoară motorul, folosește integrarea lui acceptată în loc să arunci o directivă de nivel jos într-un profil și să speri că învelișul o respectă. Învelișurile regenerează adesea profilul la conectare, așa că o modificare manuală dispare fără eroare. Verifică unde își ține clientul setările înainte de a petrece o seară pe fișier. Asta se aplică fiecărui rând din tabel, nu doar celui pentru care ai venit.

Sesiunea SSH pe care voiai să o protejezi

O conexiune SSH are o adresă sursă, o adresă destinație și o cale de răspuns. Pe un server care tocmai a instalat implicitul de tunel complet, răspunsul către adresa ta publică se potrivește cu tunelul, iar gateway-ul VPN îl aruncă.

Nimic din configurarea adreselor interfeței tunelului nu schimbă asta.

Ceea ce rezolvă este o rută mai specifică pentru adresa ta de administrare prin gateway-ul dinaintea tunelului, sau o regulă de politică ce dirijează acel trafic, plus setările de filtrare pe care le aplică gazda ta. Cele două probleme apar uneori împreună, și așa una este luată drept leacul celeilalte. Testează-le separat: ridică tunelul fără opțiune, uită-te la adresa interfeței și la calea de răspuns, apoi decide care dintre cele două este într-adevăr stricată.

Ce trebuie să preia un script delegat

Dacă vrei într-adevăr ca alt proprietar să configureze interfața, enumeră munca: aplică adresa locală și pe cea de la distanță, ridică dispozitivul, restaurează sau elimină adresarea la demontare și fă la fel din nou după o reconectare. Valorile dintr-o sesiune reușită nu trebuie codificate fix, pentru că serverul poate da altă pereche data viitoare.

Variabilele de mediu exportate de client sunt singura intrare acceptată pentru acea muncă.

env | grep -E '^ifconfig_|^route_'

În interiorul unui script route-up acele variabile sunt disponibile; dintr-o sarcină cron sau un shell manual nu sunt. Confirmă ce hook de ciclu de viață folosește versiunea ta și confirmă că hook-ul rulează cu privilegii suficiente pentru a schimba interfața, fiindcă clientul poate fi coborât deja la un utilizator fără privilegii.

Testează întregul ciclu de viață, nu o singură sesiune

Ridică tunelul, verifică adresa pe dispozitiv, apoi reconectează-te și verifică din nou. O configurație care merge o dată și eșuează la a doua încercare înseamnă de obicei că pasul delegat rulează doar la prima conectare.

Apoi testează ambele criterii de acceptare împreună: o conexiune SSH nouă prin calea de administrare dorită funcționează, iar o aplicație permisă folosește corect tunelul.

O sesiune SSH veche care supraviețuiește din întâmplare în timp ce tunelul nu are adresă nu este un succes, și exact aceasta este starea pe care o produce opțiunea când nimeni nu preia munca. Verifică mai întâi adresa interfeței, apoi calea de răspuns a administrării, apoi aplicația. Dacă două din trei sunt greșite, opțiunea a mutat munca fără să îi dea un proprietar.