Helyi SSH-átirányítás vagy teljes VPN egy Mac-képernyőhöz?

Egy Mac képernyőjét kell látnod a saját gépedről, a Mac olyan hoszt mögött van, amelyre már tudsz SSH-zni, és a kérdés az, hogy ez megérdemel-e egy VPN-t. Általában nem. Egyetlen helyi átirányítás egy TCP-portot visz át a már meglévő SSH-munkameneten, és egy képernyőhöz egy hoszton ez kisebb és jobban ellenőrizhető elrendezés, mint egy egész hálózat átirányítása.

Három feltétel dönti el, és bármelyikük a felügyelt VPN felé tolhat.

Három feltétel dönti el

Az első a hatókör: egy szolgáltatás egy hoszton, vagy több hoszt és több port. A második az, hogy a bástya és a cél közötti minden ugrás már megbízható-e, mert az SSH csak azt a szakaszt védi, amelyet lezár. A harmadik az, hogy kinek kell támogatnia az elrendezést azután, hogy megépítetted, mert a kézzel épített alagút általában túléli azt a személyt, aki értette. Nevezd meg ezt a személyt, mielőtt elkezded, és írd le a parancsot olyan helyre, ahol megtalálja. A dokumentálatlan átirányítás későbbi kezdődátumú jövőbeli incidens.

Ha a válaszok „egy”, „igen” és „én, egyelőre”, az átirányítás a megfelelő eszköz. Ha bármelyik válasz megváltozik, egy támogatott távoli hozzáférési terv egy év alatt olcsóbb, mint a dokumentálatlan alagutat követő incidensvizsgálat.

Egy portot irányíts át, ne a hálózatot

A helyi átirányítás egy figyelőt nyit a gépeden, és minden kapcsolatot az SSH-kiszolgálón keresztül továbbít egy cél felé, amelyet az a kiszolgáló elér. Egy Machez, amelynek képernyőmegosztó szolgáltatása a TCP 5900-on figyel, és egy bástyához, amely fel tudja oldani a mac.corp.example nevet, a parancs rövid és szándékosan szűk. Minden benne lévő kapcsoló azért van, hogy az elrendezés kicsi maradjon: nincs héj, nincs figyelő minden interfészen, nincs daemon. Olvasd hatókör-nyilatkozatként, nem receptként.

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

A figyelő 127.0.0.1-hez kötése távol tartja minden más interfésztől. Ez nem formaság: a minden interfészhez kötött átirányítás nyílt relévé teszi a laptopodat a vállalati hálózat felé bárki számára, aki ugyanazon a kávézói Wi-Fi-n van. Ha a port már használatban van, válassz másik magas portot, és frissítsd a nézegetőt; ne állíts le egy kapcsolódó szolgáltatást, hogy a példa illeszkedjen.

A bástyán lévő fióknak is engedélyre van szüksége, hogy arra a célra továbbítson. Egyes megerősített SSH-konfigurációk teljesen kikapcsolják a portátirányítást, mások pedig permit-listen vagy permit-open direktívával korlátozzák. Olvasd el a kiszolgáló szabályzatát, mielőtt azt feltételeznéd, hogy az elutasított csatorna rossz jelszót jelent.

Mit titkosít az SSH, és hol áll meg

Az SSH-munkamenet védi a forgalmat a Mac-edtől a bástyáig, az átirányítás pedig anélkül viszi a VNC-protokollt a munkamenet belsejében, hogy értené. Amint a kapcsolat elhagyja a bástyát a cél felé, már nem az SSH-munkamenetedben van. Bármilyen védelem is van azon az utolsó ugráson, az a célprotokollhoz és a magánhálózat saját ellenőrzéseihez tartozik.

Ezért egy egyszerű utolsó VNC-ugrást nem szabad végponttól végpontig titkosítottnak leírni csak azért, mert az első ugrás SSH-t használt. Írd le a szakaszokat őszintén: erős az ügyféltől a bástyáig, utána pedig az, amit a cél támogat. Ha a követelmény az, hogy a teljes útvonalat egyetlen mechanizmus titkosítsa, az átirányítás nem felel meg neki.

A célon való hitelesítés megint külön kérdés. Az SSH-fiók nem ad macOS-bejelentkezést, és a képernyőmegosztó szolgáltatás továbbra is a saját hitelesítő adatait kéri, és továbbra is a saját hozzáférési listáját alkalmazza. Egy helyi figyelő, amely elfogad egy kapcsolatot, semmit nem bizonyít arról, hogy a távoli szolgáltatás beengedi-e a munkamenetet.

Mikor a teljes VPN a helyes döntés

Válaszd a VPN-t, ha a feladat egynél több portot igényel: az Apple Remote Desktop felügyeleti és jelentési funkciói további TCP- és UDP-forgalmat használnak, amelyet egyetlen TCP-átirányítás nem visz át. Az átirányítás nem a teljes termék részleges megvalósítása; más, kisebb eszköz.

Válaszd akkor, ha több rendszergazda csatlakozik változó helyekről, mert egy felügyelt profil útvonalakat, hitelesítő adatokat és szabályzatot oszt ki anélkül, hogy mindenki parancssort találna ki. Válaszd akkor, ha az auditnyomnak meg kell mutatnia, ki mihez csatlakozott, mert a felhasználónkénti SSH-munkamenet és a megosztott helyi átirányítás nagyon különböző nyilvántartásokat hagy.

Válaszd végül akkor, ha a célhálózat egyáltalán nem érhető el laptopról a szervezet saját kapuja nélkül. A személyes átirányítás tervezésénél fogva megkerüli ezt a kaput, és éppen ezért tartozik változásnyilvántartásba, nem héjtörténetbe.

Hagyd, hogy az átirányítás hangosan meghiúsuljon

Használd az ExitOnForwardFailure=yes beállítást, hogy egy sikertelen kötés leállítsa a munkamenetet, ahelyett hogy egy csatlakozottnak látszó, semmit nem továbbító héjat hagyna hátra. Tartsd bekapcsolva a hosztkulcs-ellenőrzést, és a jelszó helyett részesítsd előnyben a kulcsot vagy az ügynököt. Utána teszteld a pontos URL-t, amelyet a nézegető használni fog, mert egy működő SSH-munkamenet és egy működő képernyőkapcsolat két különböző eredmény.

A macOS natív ügyfeléhez a nézegető helyi URL-en keresztül érhető el: open "vnc://127.0.0.1:15900". Ha az ablak megnyílik, és a távoli hoszt elutasítja a hitelesítést, az alagút rendben van, és a probléma a célon van. Ha az ablak soha nem nyílik meg, a probléma a figyelőben vagy a portban van.

Állítsd le a munkamenetet, amikor kész vagy, és jegyezd fel a portot, a bástyát, a célt és a fiók szabályzatát. Egy átirányítás, amelyet senki nem dokumentált, hat hónappal később megkülönböztethetetlen egy hátsó ajtótól, és ez a legerősebb érv amellett, hogy kicsi, elnevezett és ideiglenes maradjon.