Создание туннеля внутрь сети поверх SSH-сессии

Не знаю, как вам, а мне лично данная фича SSH оказалась очень полезна, хотя я только недавно взял её на вооружение. Если кто-то ещё не знал, что так можно – прошу читать и просвещаться. Надеюсь, кому-то тоже пригодится.

Суть туннелирования

Суть в том, что мы можем создать разновидность туннеля внутри созданной SSH-сессии и трафик будет передаваться в шифрованном виде как будто в трубе. Принцип возможно понятен будет из картинки (честно стыреной с Интернета):

Удалённый клиент устанавливает соединение с SSH-сервером на границе корпоративной сети. Затем он, по установленному соединению, может обращаться к внутренним узлам сети так, как если бы он был этим самым SSH-сервером. Здесь можно увидеть параллели VPN и NAT-технологий. Давайте подумаем над сценариями использования:

Сценарий 1. Устранение неполадок внутри сети удалённо

Как-то раз я столкнулся с тем, что в сети что-то пошло не так с гипервизором VMWare ESXi, а я при этом находился дома. Разумеется, в целях безопасности, доступ к консоли гипервизора был организован только с внутренних узлов сети. У меня было несколько вариантов:

1. Скорее бежать на работу. Было чрезвычайно ранее время и я очень не хотел этого делать.
2. Подключиться удалённо к шлюзу, совмещающему функции межсетевого экрана, добавить правило форвардинга в файрволл, пробросить себя дальше вглубь сети. Но это создаст некую “дверь” в защите, которую потом желательно бы не забыть убрать.
3. Подключиться удалённо к шлюзу и внутри этой сессии прыгнуть со шлюза дальше, прописав правило туннелирования. Делается это так:
   В конфигурации PuTTY в разделе “Connection -> SSH -> Tunnels” добавим незанятый порт источник и адрес гипервизора:порт назначения, тип выберем “Local” и нажмём кнопку “Add”.
   PuTTY начнёт прослушивать этот локальный порт, в этом нетрудно убедиться выполнив команду netstat -abn с правами Администратора:
   Теперь откроем в браузере адрес 127.0.0.1:12345 и …. попадём на страничку гипервизора:
   Когда решим все проблемы – просто разрываем SSH-сессию и всё, никаких изменений в межсетевом экране подправлять не придётся. При желании можно прокинуть не один порт, а несколько. И не на один сервис, а на разные, хоть на RDP, хоть на веб, хоть на SSH до внутреннего оборудования.

Сценарий 2. Защита административных интерфейсов.

Чтобы не городить с множеством файрволлов, можно сделать вот какую тему:

1. Поднять один SSH-сервер в сети, защитить его как следует – файрволл, PortKnocking, авторизация по ключам – не важно, главное, чтобы он был один. Один сервер защитить всегда проще;
2. Для всего остального “админского” царства задать доступ только с этого адреса. Не нужно прописывать все айпишники админов, если их несколько. Только один адрес для управления. Можно даже экзотический порт, чтоб наверняка;
3. С целью администрирования подключаться по SSH на этот сервер, затем через туннель нырять дальше, куда хочешь. Хочешь – на циску, хочешь – на гипервизор, хочешь – на другой сервер по RDP.
   
   Читать подробнее:   Многовкладочный PuTTy - помощник сисадмина

Главное, что этот стартовый сервер может быть нормально защищён (SSH), а также будет вести логи – кто откуда к нему цеплялся и куда прыгал.

Эти сценарии не единственно возможные, можно придумывать различные комбинации и вариации! Но без сомнения, данный инструмент в копилке админа будет наверняка нужным!

Вам так же понравится:

Меняется ли MAC или IP адрес при передачи пакета по сети? Spanning Tree Protocol и VLAN сети Создание локальных сетей организаций Создание сложных сайтов Создание загрузочной флешки на Windows Как происходит передача данных в локальной сети (TCP/IP)