Redirecționare SSH locală sau VPN complet pentru un singur ecran Mac?

Trebuie să vedeți ecranul unui Mac de pe mașina dumneavoastră, Macul stă în spatele unui gazdă la care vă puteți deja conecta prin SSH, iar întrebarea este dacă merită un VPN. De obicei nu. O singură redirecționare locală transportă un port TCP prin sesiunea SSH pe care o aveți deja, iar pentru un singur ecran pe un singur gazdă este o aranjare mai mică și mai ușor de auditat decât rutarea unei întregi rețele.

Trei condiții o decid, iar oricare dintre ele vă poate împinge spre VPN-ul administrat.

Trei condiții o decid

Prima este sfera: un serviciu pe un singur gazdă, sau mai multe gazde și mai multe porturi. A doua este dacă fiecare salt dintre bastion și țintă este deja de încredere, deoarece SSH protejează doar segmentul pe care îl încheie. A treia este cine trebuie să susțină aranjarea după ce o construiți, fiindcă un tunel făcut manual tinde să supraviețuiască persoanei care l-a înțeles. Numiți acea persoană înainte de a începe, și scrieți comanda într-un loc unde o poate găsi. O redirecționare nedocumentată este un incident viitor cu data de început amânată.

Dacă răspunsurile sunt „unul”, „da” și „eu, deocamdată”, redirecționarea este instrumentul potrivit. Dacă se schimbă orice răspuns, un design de acces la distanță cu suport costă mai puțin pe un an decât analiza incidentului care urmează unui tunel nedocumentat.

Redirecționați un port, nu rețeaua

O redirecționare locală deschide un ascultător pe mașina dumneavoastră și transmite fiecare conexiune prin serverul SSH către o destinație pe care acel server o poate atinge. Pentru un Mac al cărui serviciu de partajare a ecranului ascultă pe TCP 5900, și un bastion care poate rezolva mac.corp.example, comanda este scurtă și intenționat de îngustă. Fiecare opțiune din ea există pentru a menține aranjarea mică: fără shell, fără ascultător pe toate interfețele, fără daemon. Citiți-o ca pe o declarație de sferă, nu ca pe o rețetă.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Legarea ascultătorului la 127.0.0.1 îl ține departe de orice altă interfață. Aceasta nu este o formalitate: o redirecționare legată la toate interfețele vă transformă laptopul într-un releu deschis în rețeaua corporativă pentru oricine din aceeași cafenea cu Wi-Fi. Dacă portul este deja folosit, alegeți alt port înalt și actualizați vizualizatorul; nu opriți un serviciu nelegat pentru ca exemplul să se potrivească.

Contul de pe bastion are nevoie și el de permisiunea de a redirecționa către acea destinație. Unele configurații SSH întărite dezactivează complet redirecționarea porturilor, iar altele o restricționează cu o directivă permit-listen sau permit-open. Citiți politica serverului înainte de a presupune că un canal refuzat înseamnă că parola a fost greșită.

Ce criptează SSH și unde se oprește

Sesiunea SSH protejează traficul de la Macul dumneavoastră până la bastion, iar redirecționarea transportă protocolul VNC în interiorul acelei sesiuni fără să îl înțeleagă. Odată ce conexiunea părăsește bastionul spre țintă, nu mai este în interiorul sesiunii dumneavoastră SSH. Orice protecție există pe acel ultim salt aparține protocolului țintei și controalelor proprii ale rețelei private.

De aceea un ultim salt VNC simplu nu trebuie descris ca criptat cap la cap doar pentru că primul salt a folosit SSH. Descrieți segmentele sincer: puternic de la client la bastion, și apoi ce susține ținta. Dacă cerința este ca întreaga cale să fie criptată de un singur mecanism, redirecționarea nu o îndeplinește.

Autentificarea la țintă este din nou o chestiune separată. Contul SSH nu acordă o autentificare în macOS, iar serviciul de partajare a ecranului cere în continuare propriile credențiale și aplică în continuare propria listă de acces. Un ascultător local care acceptă o conexiune nu dovedește nimic despre dacă serviciul de la distanță va admite sesiunea.

Când VPN-ul complet este alegerea corectă

Alegeți VPN-ul când sarcina are nevoie de mai mult de un port: funcțiile de administrare și raportare ale Apple Remote Desktop folosesc trafic TCP și UDP suplimentar pe care o singură redirecționare TCP nu îl transportă. Redirecționarea nu este o implementare parțială a întregului produs; este un alt instrument, mai mic.

Alegeți-l când mai mulți administratori se conectează din locuri schimbătoare, fiindcă un profil administrat distribuie rute, credențiale și politică fără ca fiecare persoană să inventeze o linie de comandă. Alegeți-l când urma de audit trebuie să arate cine s-a conectat la ce, deoarece o sesiune SSH per utilizator și o redirecționare locală partajată lasă înregistrări foarte diferite.

Alegeți-l, în final, când rețeaua țintă nu ar trebui să fie deloc accesibilă de pe un laptop fără poarta proprie a organizației. O redirecționare personală ocolește acea poartă prin proiectare, și exact de aceea îi aparține unui registru de modificări și nu unei istorii de shell.

Faceți redirecționarea să eșueze zgomotos

Folosiți ExitOnForwardFailure=yes ca o legare eșuată să oprească sesiunea în loc să lase un shell care pare conectat și nu redirecționează nimic. Țineți activă verificarea cheii gazdei, și preferați o cheie sau un agent în locul unei parole. Apoi testați URL-ul exact pe care îl va folosi vizualizatorul, pentru că o sesiune SSH funcțională și o conexiune de ecran funcțională sunt două rezultate diferite.

Pentru clientul nativ pe macOS, vizualizatorul este atins printr-un URL local: open "vnc://127.0.0.1:15900". Dacă fereastra se deschide și gazda de la distanță refuză autentificarea, tunelul este în regulă și problema este la țintă. Dacă fereastra nu se deschide niciodată, problema este ascultătorul sau portul.

Opriți sesiunea când terminați, și notați portul, bastionul, ținta și politica contului. O redirecționare pe care nimeni nu a documentat-o este de nedistins de o ușă din spate șase luni mai târziu, și acesta este cel mai puternic argument pentru a o ține mică, numită și temporară.