Отдалечен SSH през VPN: какво тунелът не прави

VPN дава на SSH сървъра частен път и премахва нуждата от публичен слушател на порт 22. Той не удостоверява хоста, не оторизира потребителя и не решава кои акаунти могат да влизат. Това остава работа на SSH. Дали VPN е правилният начин да се стигне до сървъра зависи от три условия, а тунелът е само един от възможните отговори.

Какво променя тунелът и какво SSH все още решава

Тунелът променя достъпността: кои адреси могат да бъдат достигнати и откъде. Той не променя какво се случва, след като TCP връзката пристигне, където сървърът представя ключ на хоста и иска идентичност на потребителя.

Дръжте двата слоя отделно в главата си и в документацията. Влизането във VPN доказва кой може да използва мрежата. То не казва нищо за това какви акаунти съществуват на целта и не е разрешение да се влиза на всяка достижима машина.

Режимите на отказ също са отделни и именно това прави разделението полезно по време на инцидент.

Три условия, които определят модела на достъп

Първо, трябва ли сървърът да е достъпен за хора извън вашата мрежа? Ако не, частен път плюс бастион или мрежа е по-малкият дизайн. Второ, може ли клиентската популация действително да стартира VPN клиента, включително тези на управлявани устройства с ограничения?

Трето, нужен ли ви е контрол за услуга или контрол за потребител? VPN дава мрежов достъп; SSH дава достъп до акаунт. Ако изискването е изпълнител да достига един хост и нищо друго, това е изискване за оторизация и само тунелът не може да го изрази.

Отговорете на тези три и моделът се избира сам. Пропуснете ги и накрая излагате SSH публично, за да избегнете разгръщането на клиента.

Потвърдете частния път, преди да обвинявате SSH

Свържете одобрения VPN и използвайте документираното частно име или адрес на целта. След това проверете избрания маршрут, разрешението на шлюза и обратния път към клиента. Име, което се резолвва правилно, не е доказателство, че адресът поема предвидения тунел, защото припокриващи се локални и отдалечени префикси могат да изпратят заявката съвсем другаде. Това разграничение си заслужава да бъде записано в runbook.

Ако връзката никога не пристигне, потвърдете, че сървърът слуша на интерфейса, който очаквате и че хост-фаерволът му разрешава източника, който той действително вижда. NAT на шлюза може да пренапише този източник, така че списък с разрешения, написан за тунелния адрес на клиента, може никога да не съвпадне.

Това несъответствие е най-честата самостоятелно причинена SSH повреда през VPN.

Четете етапа на отказа, не комбинираната грешка

Три етапа дават три различни съобщения и само едно от тях е за идентификационни данни.

Използвайте точната грешка и собствения лог на сървъра, вместо да нулирате едновременно и VPN, и SSH идентификационни данни. Нулирането и на двете е начинът, по който петминутна диагностика се превръща в инцидент с идентичността за два дни.

Подробният изход показва до кой етап сте стигнали:

ssh -vv [email protected]

Пазете ключовете на хоста и оторизацията непокътнати

Валидирайте ключа на хоста чрез предвидения доверен процес, особено след подмяна на сървъра. Неочаквано предупреждение за променен ключ е единственото съобщение, което не бива да пренебрегвате само защото VPN се е свързал, защото частен тунел не прави дестинацията машината, която мислите. Проверете отпечатъка срещу източник, на който вярвате независимо от връзката.

От страна на сървъра потвърдете, че акаунтът е оторизиран и че методът за удостоверяване, който сте конфигурирали, е предлаганият. Ключ, който присъства, но се игнорира, обикновено е проблем с разрешения или конфигурация, а не с мрежата.

Ограничете достъпа до услугите до необходимите идентичности и запазете оторизиран път за възстановяване при мрежови промени.