Attālināta SSH caur VPN: ko tunelis nedara

VPN piešķir SSH serverim privātu ceļu un novērš vajadzību pēc publiska klausītāja portā 22. Tas neautentificē resursdatoru, neautorizē lietotāju un neizlemj, kuri konti var pierakstīties. Tas paliek SSH darbs. Vai VPN ir pareizais veids, kā sasniegt serveri, ir atkarīgs no trim nosacījumiem, un tunelis ir tikai viena no iespējamām atbildēm.

Ko tunelis maina un ko SSH joprojām izlemj

Tunelis maina sasniedzamību: kuras adreses var sasniegt un no kurienes. Tas nemaina to, kas notiek pēc TCP savienojuma ierašanās, kur serveris uzrāda resursdatora atslēgu un pieprasa lietotāja identitāti.

Turiet abus slāņus atsevišķi gan galvā, gan dokumentācijā. VPN pieteikšanās pierāda, kas drīkst izmantot tīklu. Tā neko nepasaka par to, kādi konti pastāv mērķī, un tā nav atļauja pierakstīties ikvienā sasniedzamā mašīnā.

Arī kļūmes režīmi ir atsevišķi, un tas ir tas, kas padara atdalīšanu noderīgu incidenta laikā.

Trīs nosacījumi, kas nosaka piekļuves modeli

Pirmkārt, vai serverim jābūt sasniedzamam cilvēkiem ārpus jūsu tīkla? Ja nē, privāts ceļš plus bastions vai tīkls ir mazākais dizains. Otrkārt, vai klientu populācija patiešām var palaist VPN klientu, tostarp tos, kas atrodas pārvaldītās ierīcēs ar ierobežojumiem?

Treškārt, vai jums ir nepieciešama kontrole pa pakalpojumiem vai kontrole pa lietotājiem? VPN piešķir tīkla sasniedzamību; SSH piešķir konta piekļuvi. Ja prasība ir, lai darbuzņēmējs sasniegtu vienu resursdatoru un neko citu, tā ir autorizācijas prasība, un tunelis vien to nevar izteikt.

Atbildiet uz šiem trim, un modelis izvēlas pats. Izlaidiet tos, un jūs beigās publiski atklāsit SSH, lai izvairītos no klienta ieviešanas.

Pirms vainot SSH, pārliecinieties par privāto ceļu

Pieslēdzieties apstiprinātajam VPN un izmantojiet dokumentēto mērķa privāto nosaukumu vai adresi. Pēc tam pārbaudiet izvēlēto maršrutu, vārtejas atļauju un atgriešanās ceļu līdz klientam. Pareizi atrisināts nosaukums nav pierādījums, ka adrese izmanto paredzēto tuneli, jo pārklājošies vietējie un attālinātie prefiksi var nosūtīt pieprasījumu pavisam citur. Šī atšķirība ir tā vērta, lai to ierakstītu runbookā.

Ja savienojums nekad neierodas, pārliecinieties, ka serveris klausās saskarnē, kuru gaidāt un ka tā resursdatora ugunsmūris atļauj avotu, ko tas patiešām redz. Vārtejas NAT var pārrakstīt šo avotu, tāpēc klienta tuneļa adresei rakstītais atļauto saraksts var nekad nesakrist.

Šī neatbilstība ir visbiežākā paša radītā SSH kļūme VPN ietvaros.

Lasiet kļūmes posmu, nevis apvienoto kļūdu

Trīs posmi rada trīs dažādus ziņojumus, un tikai viens no tiem ir par akreditācijas datiem.

Izmantojiet precīzo kļūdu un paša servera žurnālu, nevis vienlaikus atiestatiet gan VPN, gan SSH akreditācijas datus. Abu atiestatīšana ir veids, kā piecu minūšu diagnostika kļūst par divu dienu identitātes incidentu.

Detalizētā izvade parāda, kuru posmu jūs sasniedzāt:

ssh -vv [email protected]

Saglabājiet resursdatora atslēgas un autorizāciju

Validējiet resursdatora atslēgu paredzētajā uzticamajā procesā, jo īpaši pēc servera nomaiņas. Negaidīts brīdinājums par mainītu atslēgu ir vienīgais ziņojums, ko nedrīkst ignorēt tikai tāpēc, ka VPN ir pieslēdzies, jo privāts tunelis nepadara galamērķi par to mašīnu, ko jūs domājat. Pārbaudiet nospiedumu pret avotu, kuram uzticaties neatkarīgi no savienojuma.

Servera pusē pārliecinieties, ka konts ir autorizēts un ka jūsu konfigurētā autentifikācijas metode ir tā, kas tiek piedāvāta. Atslēga, kas ir, bet tiek ignorēta, parasti ir atļauju vai konfigurācijas problēma, nevis tīkla.

Ierobežojiet pakalpojumu piekļuvi nepieciešamajām identitātēm un saglabājiet autorizētu atkopšanas ceļu tīkla izmaiņām.