Reenviament SSH local o VPN complet per a una pantalla de Mac?

Necessites veure la pantalla d’un Mac des de la teva pròpia màquina, el Mac és darrere d’un amfitrió al qual ja pots connectar per SSH, i la pregunta és si això es mereix una VPN. Normalment no. Un sol reenviament local transporta un port TCP a través de la sessió SSH que ja tens, i per a una pantalla en un sol amfitrió és una disposició més petita i més auditable que encaminar tota una xarxa.

Tres condicions ho decideixen, i qualsevol d’elles et pot empènyer cap a la VPN gestionada.

Tres condicions ho decideixen

La primera és l’abast: un servei en un sol amfitrió, o diversos amfitrions i diversos ports. La segona és si cada salt entre el bastió i l’objectiu ja és de confiança, perquè SSH només protegeix el segment que acaba. La tercera és qui ha de mantenir la disposició després que la construeixis, ja que un túnel fet a mà sol sobreviure a la persona que el va entendre. Anomena aquesta persona abans de començar i escriu la comanda en un lloc on la pugui trobar. Un reenviament sense documentar és un incident futur amb una data d’inici ajornada.

Si les respostes són «un», «sí» i «jo, de moment», el reenviament és l’eina correcta. Si qualsevol resposta canvia, un disseny d’accés remot amb suport surt més barat al llarg d’un any que la revisió de l’incident que segueix un túnel sense documentar.

Reenvia un port, no la xarxa

Un reenviament local obre un oient a la teva màquina i retransmet cada connexió a través del servidor SSH cap a una destinació que aquell servidor pugui assolir. Per a un Mac el servei de compartició de pantalla del qual escolta a TCP 5900, i un bastió que pot resoldre mac.corp.example, la comanda és curta i deliberadament estreta. Cada opció que conté existeix per mantenir la disposició petita: sense shell, sense oient a totes les interfícies, sense dimoni. Llegeix-la com una declaració d’abast, no com una recepta.

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

Enllaçar l’oient a 127.0.0.1 el manté fora de qualsevol altra interfície. Això no és una formalitat: un reenviament enllaçat a totes les interfícies converteix el teu portàtil en un relé obert cap a la xarxa corporativa per a qualsevol persona al mateix Wi-Fi del cafè. Si el port ja s’utilitza, tria un altre port alt i actualitza el visor; no aturis un servei no relacionat per fer encaixar l’exemple.

El compte del bastió també necessita permís per reenviar cap a aquesta destinació. Algunes configuracions SSH endurides desactiven del tot el reenviament de ports, i algunes el restringeixen amb una directiva permit-listen o permit-open. Llegeix la política del servidor abans de suposar que un canal rebutjat significa que la contrasenya era incorrecta.

Què xifra SSH i on s’atura

La sessió SSH protegeix el trànsit del teu Mac fins al bastió, i el reenviament porta el protocol VNC dins d’aquesta sessió sense entendre’l. Un cop la connexió surt del bastió cap a l’objectiu, ja no és dins de la teva sessió SSH. Qualsevol protecció que existeixi en aquest últim salt pertany al protocol de l’objectiu i als controls propis de la xarxa privada.

Per això un últim salt VNC simple no s’ha de descriure com a xifrat d’extrem a extrem només perquè el primer salt va fer servir SSH. Descriu els segments amb honestedat: fort del client al bastió, i el que l’objectiu admeti després. Si el requisit és que tot el camí estigui xifrat per un sol mecanisme, el reenviament no el compleix.

L’autenticació a l’objectiu torna a ser una altra cosa. El compte SSH no atorga un inici de sessió a macOS, i el servei de compartició de pantalla encara demana les seves pròpies credencials i encara aplica la seva pròpia llista d’accés. Un oient local que accepta una connexió no demostra res sobre si el servei remot admetrà la sessió.

Quan la VPN completa és la decisió correcta

Tria la VPN quan la tasca necessita més d’un port: les funcions de gestió i informes d’Apple Remote Desktop utilitzen trànsit TCP i UDP addicional que un sol reenviament TCP no pot portar. Un reenviament no és una implementació parcial de tot el producte; és una eina diferent i més petita.

Tria-la quan diversos administradors es connecten des de llocs canviants, perquè un perfil gestionat distribueix rutes, credencials i política sense que cada persona hagi d’inventar una línia de comandes. Tria-la quan el registre d’auditoria ha de mostrar qui es va connectar a què, ja que una sessió SSH per usuari i un reenviament local compartit deixen registres molt diferents.

Tria-la, finalment, quan la xarxa objectiu no ha de ser abastable des d’un portàtil sense la porta pròpia de l’organització. Un reenviament personal evita aquesta porta per disseny, i és exactament per això que pertany a un registre de canvis i no a un historial de shell.

Fes que el reenviament falli sorollosament

Fes servir ExitOnForwardFailure=yes perquè un enllaç fallit aturi la sessió en lloc de deixar un shell que sembla connectat i no reenvia res. Mantén activa la verificació de clau d’amfitrió i prefereix una clau o un agent a una contrasenya. Després prova l’URL exacta que farà servir el visor, perquè una sessió SSH funcional i una connexió de pantalla funcional són dos resultats diferents.

Per al client natiu a macOS, s’arriba al visor a través d’una URL local: open "vnc://127.0.0.1:15900". Si la finestra s’obre i l’amfitrió remot rebutja l’autenticació, el túnel està bé i el problema és a l’objectiu. Si la finestra no s’obre mai, el problema és l’oient o el port.

Atura la sessió quan hagis acabat, i anota el port, el bastió, l’objectiu i la política del compte. Un reenviament que ningú no ha documentat és indistingible d’una porta del darrere sis mesos després, i aquest és l’argument més fort per mantenir-lo petit, amb nom i temporal.