Távoli SSH VPN-en át: amit az alagút nem tesz meg

A VPN privát útvonalat ad egy SSH-kiszolgálónak, és megszünteti a nyilvános figyelő szükségességét a 22-es porton. Nem hitelesíti a gazdagépet, nem engedélyezi a felhasználót, és nem dönti el, mely fiókok jelentkezhetnek be. Ez az SSH feladata marad. Hogy a VPN a megfelelő mód-e a kiszolgáló elérésére, három feltételtől függ, és az alagút csak egy a lehetséges válaszok közül.

Mit változtat az alagút, és mit dönt el továbbra is az SSH

Az alagút megváltoztatja az elérhetőséget: mely címek érhetők el, és honnan. Nem változtatja meg azt, ami a TCP-kapcsolat megérkezése után történik, ahol a kiszolgáló gazdagépkulcsot mutat be és felhasználói identitást kér.

Tartsa külön a két réteget a fejében és a dokumentációjában. A VPN-bejelentkezés bizonyítja, ki használhatja a hálózatot. Nem mond semmit arról, milyen fiókok léteznek a célon, és nem engedély arra, hogy minden elérhető gépre bejelentkezzen.

A hiba módjai is elkülönülnek, és ez teszi hasznossá az elkülönítést egy incidens során.

Három feltétel, amely meghatározza a hozzáférési modellt

Először, el kell érhetőnek lennie a kiszolgálónak a hálózatán kívüli emberek számára? Ha nem, egy privát útvonal plusz egy bástya vagy egy háló a kisebb tervezés. Másodszor, az ügyfélpopuláció ténylegesen futtatni tudja-e a VPN-klienst, beleértve azokat is, akik korlátozásokkal rendelkező kezelt eszközökön vannak?

Harmadszor, szolgáltatásonkénti vagy felhasználónkénti vezérlésre van szüksége? A VPN hálózati elérést ad; az SSH fiókhozzáférést ad. Ha a követelmény az, hogy egy vállalkozó egy gazdagépet érjen el és semmi mást, az engedélyezési követelmény, és az alagút önmagában nem tudja kifejezni.

Válaszoljon erre a háromra, és a modell magát választja ki. Ha kihagyja őket, végül nyilvánosan teszi elérhetővé az SSH-t, hogy elkerülje az ügyfél bevezetését.

Erősítse meg a privát útvonalat, mielőtt az SSH-t hibáztatná

Csatlakozzon a jóváhagyott VPN-hez, és használja a cél dokumentált privát nevét vagy címét. Ezután ellenőrizze a kiválasztott útvonalat, az átjáró engedélyét és a visszavezető utat az ügyfélhez. Egy helyesen feloldódó név nem bizonyítja, hogy a cím a szánt alagutat veszi, mert az átfedő helyi és távoli előtagok teljesen máshová küldhetik a kérést. Ez a különbség megér egy bejegyzést a runbookban.

Ha a kapcsolat soha nem érkezik meg, erősítse meg, hogy a kiszolgáló a várt interfészen figyel és hogy a gazdagép tűzfala engedélyezi a forrást, amelyet valóban lát. Az átjáró NAT-ja átírhatja ezt a forrást, ezért az ügyfél alagútcíméhez írt engedélyezési lista soha nem illeszkedhet.

Ez az eltérés a leggyakoribb saját okozású SSH-hiba VPN-en keresztül.

A hiba szakaszát olvassa, ne a kombinált hibát

Három szakasz három különböző üzenetet produkál, és csak az egyikük szól a hitelesítő adatokról.

Használja a pontos hibát és magát a kiszolgálónaplót ahelyett, hogy egyszerre állítaná vissza a VPN- és SSH-hitelesítő adatokat. Mindkettő visszaállítása az, ahogyan egy ötperces diagnózis kétnapos identitásincidenssé válik.

A részletes kimenet megmutatja, melyik szakaszig jutott:

ssh -vv [email protected]

Tartsa érintetlenül a gazdagépkulcsokat és az engedélyezést

Érvényesítse a gazdagépkulcsot a szánt megbízható folyamaton keresztül, különösen a kiszolgáló cseréje után. A váratlan megváltozott kulcs figyelmeztetés az egyetlen üzenet, amelyet nem szabad elvetni csak azért, mert a VPN csatlakozott, mert egy privát alagút nem teszi a célt azzá a géppé, amelyre gondol. Ellenőrizze az ujjlenyomatot egy olyan forráshoz képest, amelyben a kapcsolattól függetlenül megbízik.

A kiszolgáló oldalán erősítse meg, hogy a fiók engedélyezett, és hogy a beállított hitelesítési módszer az, amelyet kínálnak. A jelen lévő, de figyelmen kívül hagyott kulcs általában engedélyezési vagy konfigurációs probléma, nem hálózati.

Korlátozza a szolgáltatáshozzáférést a szükséges identitásokra, és tartson fenn engedélyezett helyreállítási útvonalat a hálózati változtatásokhoz.