Kaug-SSH üle VPN-i: mida tunnel ei tee
VPN muudab SSH-serveri kättesaadavaks ja ei midagi enamat. Kolm tingimust otsustavad, kas see sobib, ja tõrkeetapp näitab, milline kiht on süüdi.
VPN annab SSH-serverile privaatse tee ja kõrvaldab vajaduse avaliku kuulaja järele pordil 22. See ei autendi hosti, ei autoriseeri kasutajat ega otsusta, millised kontod võivad sisse logida. See jääb SSH ülesandeks. Kas VPN on õige viis serverini jõudmiseks, sõltub kolmest tingimusest, ja tunnel on vaid üks võimalikest vastustest.
Mida tunnel muudab ja mida SSH ikka otsustab
Tunnel muudab kättesaadavust: millistele aadressidele pääseb ja kust. See ei muuda seda, mis juhtub pärast TCP-ühenduse saabumist, kus server esitab hostivõtme ja küsib kasutaja identiteeti.
Hoidke kaks kihti eraldi nii peas kui ka dokumentatsioonis. VPN-i sisselogimine tõestab, kes tohib võrku kasutada. See ei ütle midagi selle kohta, millised kontod sihtmärgil on, ja see ei ole luba igasse kättesaadavasse masinasse sisse logida.
Tõrkerežiimid on samuti eraldi, ja just see teeb eraldamise intsidendi ajal kasulikuks.
Kolm tingimust, mis määravad juurdepääsumudeli
Esiteks, kas server peab olema kättesaadav väljaspool teie võrku olevatele inimestele? Kui ei, siis privaatne tee pluss bastion või mesh on väiksem disain. Teiseks, kas kliendipopulatsioon suudab VPN-kliendi tegelikult käivitada, sealhulgas need, kes on piirangutega hallatavatel seadmetel?
Kolmandaks, kas vajate juhtimist teenuse kaupa või kasutaja kaupa? VPN annab võrguulatuse; SSH annab konto juurdepääsu. Kui nõue on, et töövõtja jõuab ühte hosti ja mitte kuhugi mujale, on see autoriseerimisnõue ja tunnel üksi ei saa seda väljendada.
Vastake neile kolmele ja mudel valib end ise. Jätke need vahele ja lõpuks paljastate SSH avalikult, et vältida kliendi kasutuselevõttu.
Kinnitage privaatne tee enne, kui SSH-i süüdistate
Ühendage heakskiidetud VPN-iga ja kasutage sihtmärgi dokumenteeritud privaatset nime või aadressi. Seejärel kontrollige valitud marsruuti, lüüsi luba ja tagasiteed kliendini. Nimi, mis laheneb õigesti, ei ole tõestus, et aadress võtab kavandatud tunneli, sest kattuvad kohalikud ja kaugprefiksid võivad saata päringu hoopis mujale. See erinevus tasub runbooki kirjutada.
Kui ühendus kunagi ei saabu, kinnitage, et server kuulab liidesel, mida ootate ja et selle hosti tulemüür lubab allikat, mida see tegelikult näeb. Lüüsi NAT võib selle allika ümber kirjutada, seega kliendi tunneliaadressi jaoks kirjutatud lubatud loend ei pruugi kunagi sobida.
See lahknevus on kõige levinum ise tekitatud SSH-tõrge üle VPN-i.
Lugege tõrkeetappi, mitte kombineeritud viga
Kolm etappi tekitavad kolm erinevat sõnumit, ja ainult üks neist puudutab mandaate.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Kasutage täpset viga ja serveri enda logi, mitte ärge lähtestage korraga nii VPN- kui ka SSH-mandaate. Mõlema lähtestamine on viis, kuidas viieminutilisest diagnoosist saab kahepäevane identiteediintsident.
Üksikasjalik väljund näitab, millise etapini jõudsid:
ssh -vv [email protected]Hoidke hostivõtmed ja autoriseerimine puutumatuna
Valideerige hostivõti kavandatud usaldusväärse protsessi kaudu, eriti pärast serveri vahetamist. Ootamatu muutunud võtme hoiatus on ainus sõnum, mida ei tohi kõrvale jätta ainult sellepärast, et VPN-ühendus loodi, sest privaatne tunnel ei tee sihtmärgist masinat, mida arvate. Kontrollige sõrmejälge allika vastu, mida usaldate ühendusest sõltumatult.
Serveri poolel kinnitage, et konto on autoriseeritud ja et konfigureeritud autentimismeetod on pakutav. Olemasolev, kuid ignoreeritud võti on tavaliselt õiguste või konfiguratsiooni probleem, mitte võrgu oma.
Piirake teenuse juurdepääs vajalike identiteetidega ja hoidke võrgumuudatuste jaoks autoriseeritud taastetee.