Посмотреть туннели в linux

Обновлено: 02.07.2024

Удаленные подключения и объединения сетей остаются в тренде последние полтора года, когда события пандемии заставили пересмотреть многие подходы к работе и вызвали повышенный интерес к различным типам VPN-соединений. Все они имеют свои достоинства и недостатки, поэтому важно выбрать наиболее подходящее из них для решения определенной задачи. Если мы говорим о соединении нескольких площадок, имеющих выделенные IP-адреса, то наибольший интерес здесь представляют GRE и IPIP туннели, как наиболее простые и производительные. Сегодня мы рассмотрим их настройку в среде Linux, в частности в Debian и Ubuntu.

Краткий ликбез для тех, кто никогда не работал с данными протоколами. Это протоколы инкапсуляции, и они очень похожи друг на друга, GRE (Generic Routing Encapsulation - общая инкапсуляция маршрутов) разработан компанией Cisco и предназначен для инкапсуляции протоколов сетевого уровня (L3) в IP-пакеты. IPIP (IP Encapsulation within IP - инкапсуляция IP в IP) - также протокол инкапсуляции, но работает только с IPv4-трафиком. GRE имеет самое широкое распространение и поддержку множеством сетевых устройств и операционных систем, IPIP наиболее прост и имеет минимальные накладные расходы.

Данные протоколы не содержат никаких механизмов аутентификации и защиты данных, поэтому в настоящее время они используются только поверх IPsec и если речь сегодня идет о GRE или IPIP-туннеле, то скорее всего имеется ввиду GRE over IPsec или IPIP over IPSec. Также ни GRE, ни IPIP не используют порты (как и используемый для шифрования полезной нагрузки протокол ESP), поэтому не могут преодолевать NAT, что требует выделенных IP-адресов для каждого узла и ограничивает соединение единственным экземпляром.

Еще одна особенность GRE и IPIP - это протоколы без сохранения состояния соединения (stateless) и понять в каком состоянии находится туннель невозможно. Можно только настроить обе стороны и проверить передачу данных между ними. Но это имеет и свои плюсы - интерфейсы всегда присутствуют в системе, что облегчает настройку маршрутизации, а также отсутствуют проблемы, связанные с необходимостью переподключения и т.п.

В дальнейших примерах мы будем использовать следующую схему, а в качестве узлов будут выступать операционные системы Debian 10 и Ubuntu 20.04:

Сначала мы рассмотрим настройку самих туннелей и только убедившись в их работоспособности перейдем к защите с помощью IPsec.

Настройка туннелей GRE и IPIP в Debian

Для работы с GRE и IPIP туннелями нам потребуется загрузить специальные модули ядра, для этого откроем файл /etc/modules и внесем в него строки:

В Debian, как и во многих других основанных на нем дистрибутивах для настройки сети используется ifupdown, несмотря на то что система управляется systemd. Пока что это общепринятая практика и мы будем ее придерживаться. Поэтому откроем файл настроек /etc/network/interfaces и добавим в него следующую секцию:

Где gre30 - имя интерфейса, его можно выбрать произвольно, можно даже дать осмысленное название, скажем gre-office-zavod.

Важно, не следует использовать имена gre0 и tunl0, они присваиваются автоматически созданным интерфейсам, что приведет к неработоспособности соединения.

Следующая строка указывает на то, что мы создаем туннельное соединение, опции address и netmask задают адрес внутри туннеля с нашей стороны. Обратите внимание, что мы используем сеть /30 (маска 255.255.255.252), потому что туннель - это соединение точка - точка и выделять для него сеть /24 будет расточительством, хотя ничего страшного в этом не будет, поступайте согласно собственной планировке адресного пространства сети.

Опция mode определяет тип туннеля, в нашем случае указано gre, для IPIP следует указать ipip. Внешний адрес нашей стороны туннеля содержится в опции local, endpoint - внешний адрес противоположной стороны.

Еще один важный момент - маршрутизация. С противоположного конца находится сеть 192.168.222.0/24 и нам нужно иметь туда доступ, поэтому в конце секции добавляем еще одну команду:

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

После внесения всех изменений перезапустим сеть командой:

И убедимся, что туннельный интерфейс нормально создался, например, можно использовать команду:

Для разрешения подключения в брандмауэре следует добавить следующие правила:

Они очень просты и в комментариях не нуждаются.

Настройка туннелей GRE и IPIP в Ubuntu

Начиная с Ubuntu 18.04 для управления сетью используется netplan. Это создает свои особенности настройки туннельного интерфейса, но все остальное остается прежним. Вам точно также потребуется предварительно подключить модули ядра, добавив в /etc/modules строки:

И перезагрузить систему, если это нежелательно, временно загрузите модули с помощью modprobe, по одной команде для каждого модуля, например:

Сетевые настройки netplan хранятся в директории /etc/netplan, в силу сложной структуры yaml-файлов с многочисленными отступами сетевую конфигурацию удобнее хранить в отдельных файлах, которые загружаются в алфавитном порядке. Поэтому создадим новый файл конфигурации:

И внесем в него следующее содержимое (не используйте для отступов табуляцию, только два или четыре пробела):

В этот раз мы настраиваем IPIP-туннель, о чем косвенно говорит его имя ipip30 (может быть любым), но тип туннеля задается параметром mode. Опции remote и local задают внешние адреса туннеля с нашей и противоположной стороны, addresses - внутренний адрес с нашей стороны туннеля. Как более современное и продвинутое решение netplan позволяет сразу указать маршрутную информацию в поле routes, где мы указали путь к сети 192.168.111.0/24 через противоположный конец туннеля.

Сохраняем файл конфигурации и генерируем сетевые параметры:

Затем применим конфигурацию в тестовом режиме:

Это очень полезная функция, если в течении двух минут мы не подтвердим новые настройки netpaln вернет все как было. Теперь настраивать сеть на удаленных узлах можно не опасаясь потерять к ним доступ.

Для самых смелых есть возможность применить конфигурацию без тестирования:

В брандмауэре точно также нужно разрешить подключения по протоколам GRE и IPIP:

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

Настройка IPsec для туннелей GRE и IPIP

Для работы с IPsec нам потребуется пакет strongSwan, установим его:

Затем откроем файл настроек /etc/ipsec.conf и добавим в него следующие две секции:

Первая секция sts-base задает общие параметры для соединений site-to-site, т.е. всех GRE и IPIP-туннелей, включая набор шифров, протокол обмена ключами (IKEv2) и режим работы (транспортный). При необходимости любой из этих параметров можно переопределить, указав непосредственно в секции соединения.

Вторая секция gre30 относится к самому соединению и первой строкой загружает параметры из общей секции, а затем уже указывает собственные. Параметры подключения делятся на левые и правые, следует твердо запомнить: левые параметры относятся к локальной системе, а правые - к удаленной. Параметр left задает внешний адрес локальной для IPsec подключения, а параметр leftauth - тип аутентификации с локальной стороны, в нашем случае это psk - предварительный общий ключ. Аналогичные настройки задают внешний адрес противоположной стороны и тип аутентификации удаленной системы.

Третий параметр auto - указывает на тип запуска соединения, в нашем случае используется route, с такой настройкой strongswan производит мониторинг трафика и устанавливает защищенное соедиенение только при наличии целевого трафика между указанными узлами. Таким образом, как только появится трафик от узла left к узлу right - он будет сразу же зашифрован IPsec, а трафик от right к left соотвественно расшифрован.

Сохраним настройки и перейдем к следующему файлу /etc/ipsec.secrets в котором укажем общий ключ для наших узлов:

Общий ключ обеспечивает безопасность соединения, поэтому позаботьтесь о его секретности, а также не используйте в качестве ключа слабые последовательности и словарные фразы.

После того, как вы внесли все указанные выше изменения strongSwan следует перезапустить, в Debian используйте команду:

На другой стороне следует выполнить аналогичные настройки, только поменять местами правую и левую стороны, в нашем случае отличаются только внешние адреса узлов.

После того как вы настроите IPsec на одной стороне связь с другой стороной пропадет и появится только после аналогичной настройки удаленного узла, только теперь наш туннель будет работать с защитой IPsec. Чтобы убедиться в том, что это именно так, можно изучить дамп трафика.

Вот так выглядит незащищенный IPIP - мы видим внешний IP-заголовок, внутренний IP-заголовок и полезную нагрузку (ICMP), все как на ладони:

После включения IPsec картина будет иной, доступны будут только внешние IP-заголовки, остальное содержимое будет надежно зашифровано протоколом ESP, входящим в состав IPsec:

Также следует понимать, что в данном режиме при помощи IPsec будут шифроваться все соединения между узлами, а не только туннели.

Для нормальной работы защищенного соединения потребуется внести в брандмауэр дополнительные разрешающие правила для протоколов IKE и ESP:

Указанные ранее разрешающие правила для протоколов GRE и IPIP более не нужны (так как они находятся теперь внутри IPsec) и их следует убрать.

Особенности настройки туннелей GRE и IPIP между Debian / Ubuntu и Mikrotik

Тему соединений GRE и IPIP для роутеров Mikrotik мы не так давно разбирали в отдельной статье, сегодня же поговорим об особенностях настройки туннелей где с одного конца будет Linux, а с другой RouterOS. Основная проблема кроется в том, что при использовании штатного механизма IPsec для туннельных соединений (и L2TP) политики IPsec создаются динамически, на основе политики по умолчанию и нет никакой возможности это поведение переопределить.

Отсюда следует несколько вариантов. Самый радикальный - не использовать штатные механизмы, а создать отдельное соединение IPsec для нужных узлов и уже поверх него развернуть нужный туннель. Но это требует определенных, причем достаточно глубоких знаний и опыта, в противном случае настроить и отладить такую схему будет затруднительно. Еще один вариант - изменить настройки IPsec по умолчанию, несмотря на то что это несколько проще вам все еще следует четко представлять последствия этого шага, так как изменение настроек по умолчанию может нарушить нормальную работу других служб, использующих IPsес.

Поэтому оставим описанные варианты для опытных пользователей и настроим IPsec так, чтобы была возможность работать с роутерами Mikrotik из коробки. Что нужно учесть в этом случае? Прежде всего протокол обмена ключами - по умолчанию это IKEv1. Затем шифры, их набор существенно отличается от тех, которые мы использовали в настройках выше. Чтобы ознакомиться с ними перейдем в IP - IPsec и изучим данные на закладках Proposals и Profiles:

Таким образом, если отбросить совсем старый и ненадежный 3DES, то для IKE у нас практически не останется выбора: AES-128 - SHA1 - MODP-1024/2048, для ESP выбор немного больше, но только в части алгоритмов шифрования: AES-128/192/256 - SHA1 - MODP-1024. Кроме того, следует учитывать, что многие роутеры Mikrotik имеют достаточно слабый процессор и не поддерживают аппаратное шифрование, поэтому выбор сильных алгоритмов способен привести к высокой нагрузке на CPU и низкой производительности соединения. В большинстве случаев AES-128 будет вполне достаточно.

Вернемся на Linux сервер и добавим в /etc/ipsec.conf секцию для работы с Mikrotik:

Принципиально она ничем не отличается от приведенных выше секций, мы также загружаем в нее параметры из общей секции sts-base, но переопределяем некоторые из них, которые касаются используемых шифров и протокола обмена ключами.

Каких-либо особенностей создания туннельного соединения со стороны Linux-сервера нет, а вот при создании туннеля в RouterOS следует убрать опцию Keepalive, в противном случае Mikrotik не будет считать соединение активным пока не получит пакет с противоположной стороны туннеля.

В остальном настройки ничем не отличаются от соединения через туннели GRE и IPIP двух роутеров Mikrotik, и мы не будем рассматривать их в данной статье более подробно.

Обыные туннели Linux, такие как GRE и IPIP, знакомы каждому админу. Но операционная система не ограничивается ими. Малоизвестные опции классических туннелей и более новые протоколы могут существенно облегчить решение задач. В данной инструкции мы рассмотрим несколько не очень распространенных протоколов и научимся управлять ими с помощью iproute2, стандартного инструмента для работы с сетевым стеком Linux.

Сразу предупрежу, что здесь и далее в качестве условных публичных адресов IPv4 я использую сети 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24, которые в RFC 5737 зарезервированы для примеров и документации.

Dual stack GRE

Для передачи IPv4 поверх IPv4 как правило используют IPIP, для передачи IPv6 поверх IPv4 — SIT, а для передачи IPv6 поверх IPv6 есть IP6IP6, хотя, если честно, такие случаи применения мне неизвестны. Недостаток в том, что для сети с dual stack потребовалось бы больше одного туннеля.

GRE может решить одновременно обе задачи. В Linux достаточно добавить на туннельный интерфейс адреса из обоих протоколов.

Все команды iproute2, которые изменяют настройки, необходимо выполнять с правами root. Большинство команд для просмотра настроек особых прав не требуют, но и тут есть исключения.

$ ip tunnel add tun0 mode gre local 203.0.113.10 remote 198.51.100.20

Стоить напомнить, что туннели Linux создаются в выключенном (down) состоянии. Не забывайте добавлять в скрипты ip link set dev . up .

gretap

Классический GRE инкапсулирует пакеты IP. Но протокол не просто так называется generic routing encapsulation. Он вполне способен передавать и кадры протоколов канального уровня.

В заголовках GRE для протокола инкапсулированного пакета есть отдельное поле, куда пишется EtherType нагрузки, и пакет помещается в полезную нагрузку целиком. А сам GRE — отдельный протокол IP с номером 47. Подробности можно узнать из RFC 2784.

$ ip link add tun0 type gretap local 192.0.2.10 remote 203.0.113.20

Объединим интерфейсы eth2 и tun0 в мост br0 :

Несколько туннелей GRE к одному хосту

Как правило между двумя маршрутизаторами настраивают по одному туннелю. Что, если нужно больше, например для тестов? У GRE есть решение. Вы можете указать «ключ» и создать своего рода кодовое разделение доступа. Если между хостами уже настроен обычный туннель, никаких трудностей не будет.

$ ip tunnel add tun2 mode gre local 198.51.100.10 remote 203.0.113.20 key 1234 $ ip tunnel add tun3 mode gre local 198.51.100.10 remote 203.0.113.25 key 3456

Несмотря на название, к шифрованию данная функция не имеет никакого отношения — «ключ» передается в открытом виде и используется исключительно для идентификации туннелей.

L2TPv3

Для мультиплексирования туннелей лучше использовать другие протоколы. Например, L2TPv3. Этот протокол почти не имеет нечего общего с широко известным L2TP, который часто применяют для клиентских туннелей VPN. Его цель заключается в другом, и он специально спроектирован для провайдерских туннелей. Протокол довольно гибкий и предоставляет большое количество всевозможных настроек. Почитать о нем в деталях вы можете в RFC 3913. Мы рассмотрим самые основные.

В отличие от L2TPv2, он может как работать прямо поверх IP (протокол 115), так и инкапсулироваться в UDP. Первый вариант лучше по производительности, но второй лучше проходит через NAT. Выбор остается за вами.

L2TPv3 использует необычную терминологию. Туннель в L2TPv3 — чисто виртуальная сущность. С каждым туннелем может быть ассоциирована одна или более сессий. У каждого туннеля есть свой идентификатор, есть он и у каждой сессии. Более того, идентификаторы могут не совпадать на обеих сторонах, поэтому в командах нужно указывать оба.

Создание нашего первого туннеля, поверх IP:

$ ip l2tp add tunnel tunnel_id 10 peer_tunnel_id 10 encap ip local 192.0.2.10 remote 203.0.113.20

На этом этапе никаких новых сетевых интерфейсов в нашей системе не появится. В наличие туннеля можно убедиться с помощью команды ip l2tp show tunnel :

Теперь создадим сессию и ассоциируем ее с туннелем:

$ ip l2tp add session tunnel_id 10 session_id 10 peer_session_id 10

После создания сессии в системе появится новый интерфейс. По умолчанию они именуются l2tpethN . Чтобы изменить имя интерфейса, надо добавить к команде опцию name , например name myl2tpsession .

Просмотреть информацию о созданных сессиях можно с помощью команды ip l2tp show session .

L2TPv3 поверх UDP

Команда для создания туннелей поверх UDP отличается опцией encap udp вместо encap ip . Кроме того, необходимо указать порты источника и назначения — они тоже могут быть разными. Опции называются udp_sport и udp_dport .

$ ip l2tp add tunnel tunnel_id 10 peer_tunnel_id 10 udp_sport 9000 udp_dport 9000 encap udp local 192.0.2.10 remote 203.0.113.20

Команды для создания сессий не зависят от типа инкапсуляции.

VXLAN

Если L2TPv3 происходит из «дооблачных» времен, то VXLAN был специально спроектирован с расчетом на виртуальные окружения. Он может работать как в режиме точка — точка, так и в режиме многоадресной рассылки.

VXLAN в режиме точка — точка

Чтобы создать туннель Linux VXLAN в режиме точка — точка, нам потребуется указать физический интерфейс для него, идентификатор виртуальной сети (VNI), адреса источника и приемника и порт UDP. Порт по стандарту — 4789, но можно использовать любой.

$ ip link add name vxlan0 type vxlan id 10 dev eth0 local 192.0.2.10 remote 203.0.113.20 dstport 5000

Значения идентификаторов сетей могут быть в диапазоне от 0 до 16 777 215.

Многоадресный VXLAN

Одноадресный VXLAN мало отличается от L2TPv3 по функциональности, разве что проще в настройке, и в VXLAN точечные туннели — это, скорее, особый случай. Проектировался этот протокол для совсем другой задачи. В виртуальном окружении логическая топология сети не привязана к физической, и виртуальные машины из одной логической сети вполне могут оказаться на разных физических хостах. Для объединения таких машин в одну сеть канального уровня разные компании предложили несколько протоколов, но VXLAN приобрел наибольшую популярность.

Основной режим для него — многоадресный (multicast). Чтобы создать туннель в многоадресном режиме, нужно указать не адрес удаленного хоста, а адрес multicast:

$ ip link add name vxlan0 type vxlan id 20 dev eth0 group 239.0.0.1 dstport 4789

Если хосты расположены в одном сегменте канального уровня, они найдут друг друга по протоколу IGMP. Этот вариант вполне годится для создания независимых виртуальных сетей внутри одного кластера гипервизоров. Если хосты разделены маршрутизируемой сетью, например интернетом, потребуется протокол многоадресной маршрутизации, такой как PIM-SM. Их реализации существуют для Linux, к примеру pimd из пакета FRRouting, но их использование — тема для отдельной статьи.

Нужно отметить, что ряд адресов multicast зарезервирован для вполне конкретных целей и протоколов, например 224.0.0.1 — группа всех маршрутизаторов вообще, а 224.0.0.5 — группа всех маршрутизаторов OSPFv2. Для частного использования выделена сеть 239.0.0.0/8, адреса для своих целей можно смело брать из нее.

В строгом смысле 802.1ad QinQ не является туннелем, но преследует сходную цель — мультиплексирование пользовательских VLAN в одном 802.1q VLAN. Этот протокол нередко применяется провайдерами для предоставления клиентам виртуальных выделенных линий вместо MPLS, если задача только в том, чтобы пробросить несколько клиентских VLAN с одной точки сети с другую.

В отличие от всех описанных протоколов, это протокол исключительно канального уровня и требует поддержки со стороны коммутаторов, которая присутствует не во всех моделях и версиях ОС. Также разные коммутаторы могут требовать разного протокола для провайдерских кадров: либо 802.1ad по стандарту (протокол Ethernet 0x88A8), либо 802.1q (протокол 0x8100).

Некоторые коммутаторы поддерживают QinQ странным образом. К примеру, я видел модели Dell PowerEdge, которые при включении QinQ на одном порте отключали обычный 802.1q VLAN на всех остальных, с очевидными последствиями для пользователей. Всегда проверяй настройки на стенде. Но если все нормально поддерживается, протокол прекрасно решает свою задачу.

Чтобы создать виртуальную выделенную линию, нам надо создать один внешний (провайдерский) VLAN и один или более внутренних (клиентских). Терминировать провайдерские туннели вместе с клиентскими на одном маршрутизаторе приходится не так часто, но иногда бывает нужно.

Если выбрать yes то в файл

/.ssh/known_hosts добавится похожая строка:

|1| abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Обычно файл known_hosts имеет следующий формат (записи идут через пробел)

Это хэш от имени сервера.

Здесь через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.

Сгенерировать пару ключей

Первый шаг - это генерация пары ключей. Обычно это делается на клиентской машине. Например, на вашем ноутбуке.

ssh-keygen -b 4096

sudo ssh-keygen -b 4096

Нужно придумать имя ключа.

Я назову ключ andrei-key101 а сохранять буду в текущую директорию.

Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.

Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls

Важно помнить, что если вы генерируете ключ для другого пользователя нужно позаботиться о правильных правах доступа к этому ключу.

.pub ключ отправляйте на удалённую машину

приватный ключ храните на своём клиенте

Передать ключ на удалённый хост

После того, как ключи созданы нужно передать .pub ключ на удалённый хост.

Сделать это можно несколькими способами начнём с утилиты ssh-copy-id

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i

Введите yes

Теперь на хосте 192.168.0.2 в файле /home/andrei/.ssh/authorized_keys появилась новая запись вида

Знак … заменяет длинные последовательности случайных символов для экономии места.

Проверить ключ можно командой

Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Узнать версию OpenSSH в Linux

Чтобы узнать версию OpenSSH в вашем дистрибутиве Linux выполните

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Выполнить команду из скрипта на удалённом компьютере

Если подключение по ssh происходим из bash-скрипта , и при этом нужно ещё выполнить ряд команд после подключения - достаточно перечислить эти команды через точку с запятой

Если нужно выполнить команду, требующую sudo попробуйте флаг -t

known_hosts

Список известных хостов находится в файле known_hosts

Обычно файл known_hosts имеет следующий формат (записи идут через пробел) ( подробнее )

Примеры алгоритмов: ssh-rsa, ssh-dss, ssh-ed25519, ecdsa-sha2-nistp256 …

Это хэш от имени сервера.

Это алгоритм шифрования

Это публичный ключ хоста

Создать SSH туннель

Туннели обычно создают для перенаправления траффика. SSH tunnel это то же самое что и SSH port forwarding.

На удалённом хосте у вас есть пользователь с именем andrei и вы знаете его пароль.

Сперва нужно определиться с портами на локальном хосте и на удалённом.

Предположим, вы выбрали 9119 для локального и 9200 для удаленного хостов.

То есть вы хотите, чтобы всё, что идёт на localhost:9119 было перенаправлено на 192.168.0.2 : 9200

ssh -L 9119: 192.168.0.2 : 9200 andrei@192.168.0.2

Проверьте ip выполнив

Если вам нужен туннель с поддержкой графического интерфейса X Window System используйте флаг -X

ssh -X -L 9119: 192.168.0.2 : 9200 andrei@192.168.0.2

Демонстрация

Туннель создан, не закрывайте терминал. Откройте два новых терминала или две новые вкладки в старом.

У вас два пустых терминала, оба на локальном хосте. Назовём их 1 и 2.

Из терминала 2 подключимся к удалённому хосту 192.168.0.2 по ssh и будем слушать на порту 9200 с помощью nmap

ssh andrei@192.168.0.2
nmap -l 9200

nmap localhost 9119

Введём любой текст

Откройте терминал 2 там дожен появиться тот же текст

Список всех открытых SSH туннелей

Чтобы получить список туннелей открытых именно ssh выполните

ssh 14695 andrei 3u IPv4 230080 0t0 TCP 192.168.0.1:46356->192.168.0.2:ssh (ESTABLISHED) ssh 14695 andrei 4u IPv6 230103 0t0 TCP [::1]:9119 (LISTEN) ssh 14695 andrei 5u IPv4 230104 0t0 TCP 127.0.0.1:9119 (LISTEN)

Вывод этой команды при практически идентичных условиях почему-то разный.

Ниже пример второго варианта. Если вы знаете почему так получается - напишите в комментариях.

ssh 15151 andrei 3u IPv4 239364 0t0 TCP 192.168.0.1:46464->192.168.0.2:ssh (ESTABLISHED) ssh 15151 andrei 4u IPv6 239380 0t0 TCP [::1]:mxit (LISTEN) ssh 15151 andrei 5u IPv4 239381 0t0 TCP 127.0.0.1:mxit (LISTEN) ssh 15151 andrei 9u IPv6 239428 0t0 TCP [::1]:mxit->[::1]:54306 (ESTABLISHED)

Закрыть все SSH туннели

Чтобы закрыть всё, что связано с ssh можно выполнить

sudo killall ssh sshd

Этот метод хорош только если вы работаете один, например на какой-то виртуальной машине.

Запустить SSH в фоновом режиме

Существует несколько способов запустить ssh соединение в фоновом режиме - то есть освободим текущий терминал.

-L, screen, tmux, nohup

Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него

nohup ssh user@host "cd scripts;python3 my_script.py $ARG1 $ARG2; exit" &

Для чего это было нужно: Python скрипт сначала открывал одно ssh соединение из subprocess там выполнялась команда для запуска мониторинга потребления памяти и больше от этого соединения ничего было не нужно, зато необходимо было выполнять новые соединения с нагрузкой из другого скрипта.

Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти перед ssh нужно было добавить nohup, а в самом конце поставить &

SSH_MSG_USERAUTH_BANNER

Клиенту, подключившемуся к ssh серверу можно показать баннер SSH_MSG_USERAUTH_BANNER

И отредактируйте файл добавив свой баннер

Откройте sshd_config и укажите путь до баннера

Этот баннер будет показан ДО авторизации, то есть во время ввода пароля

Чтобы создать баннер, который будет показан после успешного входа выполните

После редактирования файлов перезапустите sshd

sudo systemctl restart sshd.service

Конвертация сертификатов

Рассмотрим простой пример: вы достали из базы данных сертификат MIIC4jCCAc … A7A6Rpt8V9Q== , но он не отформатирован и не проходит валидацию

Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.

Либо, если вам нужно работать с файлами - сохраните исходный сертифика в фай raw_cert

echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert
cat raw_cert | base64 -d | openssl x509 -inform der > cert
cat cert

-----BEGIN CERTIFICATE-----
MIIC4jC … 7A6Rpt8V9Q==
-----END CERTIFICATE-----

Такого же результата можно было добиться аккуратно добавив -----BEGIN CERTIFICATE----- в начало и -----END CERTIFICATE----- в конец файла, но не всегда всё так просто.

"Если мы видим свет в конце туннеля, то это свет приближающегося поезда" (Роберт Лоуэлл)

Я дам здесь лишь самые основы: расскажу, как создавать туннели, объясню синтаксис команд, приведу примеры обратных туннелей и причины для использования каждого из них. Кратко коснусь файла ssh_config; более подробно он будет рассмотрен в будущем.

Создать SSH-туннель довольно просто. А вот решить, что с ним делать, может оказаться немного труднее. Поэтому я приведу несколько примеров, прежде чем мы вдадимся в детали. Я в свое время немного попутешествовал - это было на прежнем месте работы и до того, как у меня родились дети. В поездках мне доводилось останавливаться в самых странных гостиницах (думаю, вы с такими знакомы), оснащенных еще более странными беспроводными точками доступа. Захотите ли вы в гостинице подключиться к точке доступа, у которой SSID написан с орфографическими ошибками? Или в аэропорту, где вы обнаруживаете сразу несколько открытых точек? Если я нахожусь не дома, я пущу HTTP-трафик через туннель между своим устройством на Android (с root-доступом) и домашним сервером. Если же я работаю на ноутбуке, то открою SSH-туннель и пущу HTTP-трафик через Socks5 с тем, чтобы он весь был зашифрован средствами SSH. Я не доверяю открытым точкам доступа настолько, насколько могу. Что еще добавить? Мне приходилось "заворачивать" в туннели SMTP-трафик, когда я попадал в такие места, где блокировались исходящие SMTP-пакеты. То же самое мне приходилось делать и с POP3, с которого я недавно перешел на IMAPS. Другие примеры SSH-туннелей включают в себя проброс приложений X11 и сеансов VNC. Ранее я также упоминал обратные туннели. Они представляют собой. ну, вы сами понимаете - туннели, направленные в обратную сторону. В этом случае вы подключаетесь откуда-либо, где нет сервера SSH, к внешнему SSH-серверу. Потом, зарегистрировавшись на этом сервере, в том числе и локально, вы можете восстановить это подключение. Какая в этом польза, говорите? Ну, например, VPN-сервер вашей компании "упал" или работает только с VPN-клиентами под Windows, но вам совершенно не хочется тащиться с ноутбуком домой, чтобы проверить, работает ли тот или иной процесс. Придя домой, вы можете установить обратный туннель. В этом случае вам следует подключиться с сервера "Икс" к вашей домашней машине. Прибыв домой, вы восстанавливаете подключение к серверу "Икс", таким образом обходя файервол или VPN, и проверяете работу процесса без необходимости подключения по VPN. Я поступаю так очень редко, так как, на мой взгляд, подключение к серверу минуя файервол или VPN - это "плохое кунг-фу" и может использоваться лишь в самом крайнем случае.

Итак, вы получили несколько примеров SSH-туннелей, а теперь посмотрим, как это все делается.

Перед тем, как мы углубимся в работу на клиенте, немного отредактируем файл sshd_config на сервере. В /etc/ssh/sshd_config я обычно вношу некоторые изменения. Но не забудьте перед началом редактирования сделать его резервную копию на случай, если что-то пойдет наперекосяк.

Не забудьте, что если вы внесли какие-либо изменения в sshd_config, то вам нужно будет перезапустить сервис sshd для того, чтобы эти изменения вступили в силу.

А теперь перейдем к ключам. Нет-нет, не тем ключам, которые у вас отобрал папа, когда вы разбили мамину машину, а к ключам командной строки SSH.

Типичный SSH-туннель без перенаправления X выглядит примерно так:

Здесь ключи означают следующее:

-N - не выполнять команд на удаленной машине
-p 22 - подключаться на внешний порт 22. Я обычно использую другой внешний порт, чтобы избавиться от атак "кулхацкеров" на мой SSH-сервер
bob@mylinuxserver.xxx - имя_пользователя@имя_сервера (или IP-адрес)
-L 2110:localhost:110 - информация о привязке портов. Означает следующее: порт_клиента:имя_сервера:порт_сервера. В данном примере мы перенаправляем 110 порт сервера на 2110 порт вашей машины

Хотите еще немного примеров?

Проброс POP3 и SMTP через SSH:

Проброс Google Talk через SSH (ключ -g позволяет удаленным машинам подключаться к проброшенным локальным портам):

Практически все, что передается в виде простого текста, можно обезопасить с помощью SSH-туннелей

После подключения настройте свой браузер или другую программу, способную использовать прокси на адрес localhost:5222. Таким образом будет создан динамический проброс порта и весь трафик пойдет через SSH-сервер, одновременно шифруясь и обходя фильтрование по содержимому

Перенаправление сеансов X и VNC

Припоминаете, что вы добавили " X11Forwarding yes " в sshd_config? Это-то и позволяет пробрасывать сеансы X.

При пробросе сеансов VNC будьте внимательны. Если на клиенте, с котрого вы подключаете туннель, работает VNC-сервер, скажем, на порту 5900, удостоверьтесь, что вы не указали этот порт в качестве перенаправляемого, иначе вы подключитесь к самому себе. Вообще же VNC пробрасывается точно так же, как и любой другой сервис:

Обратные SSH-туннели

Ну, вот и настало время для моей любимой разновидности SSH-туннелей. Разумеется, получать доступ к какому-либо сервису через SSH - это здорово, "гонять" веб-трафик по зашифрованным SSH-туннелям - тоже, но самое приятное удивление можно испытать от обратных туннелей. Как я уже говорил ранее, ими приходится пользоваться в ситуации, когда имеется машина без SSH-сервера, а вы испытываете необходимость получить к ней доступ в дальнейшем (через несколько минут, часов или дней), но при этом не хотите или не можете воспользоваться VPN. Вам следует соединиться с SSH-сервером с этой машины, а затем установить обратный SSH-туннель, подключившись к этому соединению. Для чего я это применяю? Время от времени - для того, чтобы поработать с удаленным сервером или просто для того, чтобы помочь друзьям и родственникам по VNC через SSH. В последнем случае они запускают Putty с сохраненными настройками сеанса и подключаются к моему SSH-серверу от имени пользователя, не имеющего никаких прав. После создания туннеля я могу зайти по VNC на их машины. И все, им не нужно настраивать файервол или разбираться с LogMeIn или другими подобными сайтами.

Итак, для создания обратного SSH-туннеля необходимо выполнить следущие действия:

На клиентской машине:

На стороне сервера:

И вот вам обратный туннель! Вуаля!

Заключение

Ну, вот вы и получили начальные знания в области SSH-туннелей. Не забывайте, что это лишь азы, на самом же деле область применения этих туннелей ограничена лишь вашим воображением. Позднее я опишу настройку файла ssh_config на стороне клиента для сохранения индивидуальных параметров соединений. Но об этом - в следующий раз.

Читайте также: