Nuotolinis SSH per VPN: ko tunelis nedaro
VPN padaro SSH serverį pasiekiamą ir nieko daugiau. Trys sąlygos nusprendžia, ar jis tinka, o gedimo etapas parodo, kuris sluoksnis kaltas.
VPN suteikia SSH serveriui privatų kelią ir pašalina viešo klausytojo prie 22 prievado poreikį. Jis neautentifikuoja pagrindinio kompiuterio, neautorizuoja naudotojo ir nenusprendžia, kurios paskyros gali prisijungti. Tai lieka SSH darbu. Ar VPN yra tinkamas būdas pasiekti serverį, priklauso nuo trijų sąlygų, o tunelis yra tik vienas iš galimų atsakymų.
Ką tunelis keičia ir ką SSH vis dar sprendžia
Tunelis keičia pasiekiamumą: kuriuos adresus galima pasiekti ir iš kur. Jis nekeičia to, kas vyksta po to, kai atvyksta TCP ryšys, kur serveris pateikia pagrindinio kompiuterio raktą ir prašo naudotojo tapatybės.
Laikykite du sluoksnius atskirai savo galvoje ir dokumentacijoje. Prisijungimas prie VPN įrodo, kas gali naudotis tinklu. Tai nieko nesako apie tai, kokios paskyros egzistuoja tiksle, ir tai nėra leidimas prisijungti prie kiekvienos pasiekiamos mašinos.
Gedimo režimai taip pat atskiri, ir būtent tai daro atskyrimą naudingą incidento metu.
Trys sąlygos, lemiančios prieigos modelį
Pirma, ar serveris turi būti pasiekiamas žmonėms už jūsų tinklo ribų? Jei ne, privatus kelias ir bastionas ar tinklas yra mažesnis dizainas. Antra, ar klientų populiacija iš tikrųjų gali paleisti VPN klientą, įskaitant tuos, kurie yra valdomuose įrenginiuose su apribojimais?
Trečia, ar jums reikia kontrolės pagal paslaugą, ar kontrolės pagal naudotoją? VPN suteikia tinklo pasiekiamumą; SSH suteikia paskyros prieigą. Jei reikalavimas yra, kad rangovas pasiektų vieną pagrindinį kompiuterį ir nieko daugiau, tai yra autorizacijos reikalavimas, ir vien tunelis to negali išreikšti.
Atsakykite į šiuos tris ir modelis pasirenka pats. Praleiskite juos ir galiausiai viešai atskleisite SSH, kad išvengtumėte kliento diegimo.
Patvirtinkite privatų kelią prieš kaltinant SSH
Prisijunkite prie patvirtinto VPN ir naudokite dokumentuotą privatų tikslo pavadinimą arba adresą. Tada patikrinkite pasirinktą maršrutą, šliuzo leidimą ir grįžimo kelią iki kliento. Teisingai išsprendžiamas pavadinimas nėra įrodymas, kad adresas eina numatytu tuneliu, nes persidengiantys vietiniai ir nuotoliniai prefiksai gali nusiųsti užklausą visai kitur. Šis skirtumas vertas įrašo runbooke.
Jei ryšys niekada neatvyksta, patvirtinkite, kad serveris klausosi sąsajos, kurios tikitės ir kad jo pagrindinio kompiuterio užkarda leidžia šaltinį, kurį jis iš tikrųjų mato. Šliuzo NAT gali perrašyti tą šaltinį, todėl kliento tunelio adresui parašytas leidimų sąrašas gali niekada neatsitikti.
Tas neatitikimas yra dažniausia savo sukelta SSH gedimas per VPN.
Skaitykite gedimo etapą, o ne sujungtą klaidą
Trys etapai sukuria tris skirtingus pranešimus, ir tik vienas iš jų apie prisijungimo duomenis.
| 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 |
Naudokite tikslią klaidą ir paties serverio žurnalą, o ne iš naujo nustatykite abu VPN ir SSH prisijungimo duomenis vienu metu. Abiejų nustatymas iš naujo yra būdas, kuriuo penkių minučių diagnozė tampa dviejų dienų tapatybės incidentu.
Išsamus išvestis parodo, kurį etapą pasiekėte:
ssh -vv [email protected]Išsaugokite pagrindinio kompiuterio raktus ir autorizaciją
Patikrinkite pagrindinio kompiuterio raktą numatytu patikimu procesu, ypač pakeitus serverį. Netikėtas pasikeitusio rakto įspėjimas yra vienintelis pranešimas, kurio neturėtumėte atmesti vien todėl, kad VPN prisijungė, nes privatus tunelis nepadaro paskirties tos mašinos, kurią manote. Patikrinkite pirštų atspaudą šaltinyje, kuriuo pasitikite nepriklausomai nuo ryšio.
Serverio pusėje patvirtinkite, kad paskyra autorizuota ir kad jūsų sukonfigūruotas autentifikavimo metodas yra siūlomas. Raktas, kuris yra, bet ignoruojamas, paprastai yra teisių arba konfigūracijos problema, o ne tinklo.
Apribokite paslaugų prieigą reikiamoms tapatybėms ir palaikykite autorizuotą atkūrimo kelią tinklo pakeitimams.