Vzdialené SSH cez VPN: čo tunel nerobí
VPN sprístupní SSH server a nič viac. O tom, či sa hodí, rozhodujú tri podmienky a fáza zlyhania ukazuje, ktorá vrstva je na vine.
VPN dá SSH serveru súkromnú cestu a odstráni potrebu verejného poslucháča na porte 22. Neoveruje identitu hostiteľa, neautorizuje používateľa ani nerozhoduje, ktoré účty sa môžu prihlásiť. To zostáva úlohou SSH. Či je VPN správny spôsob, ako sa dostať k serveru, závisí od troch podmienok a tunel je len jednou z možných odpovedí.
Čo tunel mení a čo SSH stále rozhoduje
Tunel mení dosiahnuteľnosť: ktoré adresy sa dajú dosiahnuť a odkiaľ. Nemeni to, čo sa deje po nadviazaní TCP spojenia, keď server predloží kľúč hostiteľa a požiada o identitu používateľa.
Držte obe vrstvy oddelene v hlave aj v dokumentácii. Prihlásenie do VPN dokazuje, kto smie používať sieť. Nehovorí nič o tom, aké účty existujú na cieli, a nie je povolením prihlásiť sa na každý dosiahnuteľný stroj.
Spôsoby zlyhania sú tiež oddelené a práve preto je oddelenie užitočné počas incidentu.
Tri podmienky, ktoré rozhodujú o modeli prístupu
Po prvé, musí byť server dosiahnuteľný pre ľudí mimo vašej siete? Ak nie, súkromná cesta plus bastion alebo mesh je menší návrh. Po druhé, dokáže skupina klientov skutočne spustiť VPN klienta, vrátane tých na spravovaných zariadeniach s obmedzeniami?
Po tretie, potrebujete kontrolu po službe alebo po používateľovi? VPN udeľuje sieťový dosah; SSH udeľuje prístup k účtu. Ak je požiadavkou, aby dodávateľ dosiahol jedného hostiteľa a nič iné, je to požiadavka na autorizáciu a samotný tunel ju nevyjadrí.
Odpovedzte na tie tri a model sa vyberie sám. Ak ich preskočíte, skončíte s verejne vystaveným SSH, len aby ste sa vyhli nasadeniu klienta.
Potvrďte súkromnú cestu, kým obviníte SSH
Pripojte sa k schválenému VPN a použite zdokumentované súkromné meno alebo adresu cieľa. Potom skontrolujte vybranú trasu, povolenie brány a spätnú cestu ku klientovi. Meno, ktoré sa správne prekladá, nie je dôkazom, že adresa ide zamýšľaným tunelom, pretože prekrývajúce sa lokálne a vzdialené prefixy môžu požiadavku poslať úplne inam. Tento rozdiel stojí za zapísanie do runbooku.
Ak spojenie nikdy nevznikne, potvrďte, že server načúva na rozhraní, ktoré očakávate, a že jeho firewall hostiteľa povoľuje zdroj, ktorý skutočne vidí. NAT brány môže tento zdroj prepísať, takže zoznam povolených napísaný pre tunelovú adresu klienta nemusí nikdy sedieť.
Tento nesúlad je najčastejšia samovoľne spôsobená porucha SSH cez VPN.
Čítajte fázu zlyhania, nie zlúčenú chybu
Tri fázy vytvárajú tri rôzne hlásenia a iba jedno z nich sa týka prihlasovacích údajov.
| 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 |
Použite presnú chybu a vlastný log servera namiesto resetovania prihlasovacích údajov VPN aj SSH naraz. Resetovanie oboch je spôsob, akým sa z päťminútovej diagnostiky stane dvojdňový incident s identitou.
Podrobný výstup ukazuje, do ktorej fázy ste sa dostali:
ssh -vv [email protected]Zachovajte kľúče hostiteľa a autorizáciu nezmenené
Overte kľúč hostiteľa zamýšľaným dôveryhodným procesom, najmä po výmene servera. Neočakávané varovanie o zmene kľúča je práve tá správa, ktorú nesmiete odbiť len preto, že sa VPN pripojila, pretože súkromný tunel nerobí z cieľa stroj, ktorý si myslíte, že to je. Skontrolujte odtlačok voči zdroju, ktorému dôverujete nezávisle od spojenia.
Na strane servera potvrďte, že účet je autorizovaný a že sa ponúka práve metóda overenia, ktorú ste nastavili. Kľúč, ktorý existuje, ale ignoruje sa, je zvyčajne problém oprávnení alebo konfigurácie, nie siete.
Obmedzte prístup k službe na potrebné identity a udržiavajte autorizovanú cestu obnovy pre zmeny v sieti.