По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
SSH туннели один из самых часто используемых методов связи среди системных и сетевых администраторов. В данном руководстве расскажем о такой функции как переброс порта SSH. Это используется для безопасной передачи данных между двумя и более системами.
Что такое переброс порта SSH?
Коротко, переброс порта SSH даёт возможность создавать туннель между несколькими системами, а затем настроить эти системы так, чтобы трафик они гнали через этот туннель. Именно по такой логике работает VPN или SOCKS Proxy.
Есть несколько разных методов переброса: переброс локального порта, переброс удалённого порта или динамический переброс. Для начала дадим пояснение каждому из них.
Локальный переброс порта позволяет получать доступ ко внешним ресурсам из локальной сети и работать в удаленной системе, как если бы они находились в одной локальной сети. По такому принципу работает Remote Access VPN.
Переброс удаленного порта дает возможность удалённой системе получать доступ к вашей локальной сети.
Динамический переброс создает SOCKS прокси сервер. После этого настраиваем приложения так, чтобы они использовали это туннель для передачи данных. Чаще всего такой переброс используется для доступа к ресурсам, который по той или иной причине заблокированы для данной страны.
Для чего нужен переброс порта SSH?
Допустим у вас есть какое-то приложение, которые передаёт данные в открытом виде или через нешифрованный протокол. Ввиду того, что SSH создает шифрованное соединение, то вы с легкостью можете настроить программу так, чтобы трафик её шёл через этот туннель.
Он так же часто используется для доступа к внутренним ресурсам извне. Приблизительно это напоминает Site-to-Site VPN, где нужно указывать какой именно трафик нужно заворачивать в туннель.
Сколько сессий можно устанавливать?
Теоретически, можно создавать столько сессий, сколько нам захочется. В сети используется 65 535 различных портов, и мы можем перебрасывать любой из этих портов.
Но при перебросе порта нужно учитывать, что некоторые из них зарезервированы за конкретными сервисами. Например, HTTP использует 80 порт. Значит, переброс на порт 80 возможен только если нужно переадресовать веб трафик.
Порт, который перебрасывается на локальном хосте может не совпадать с портом удаленной системы. Мы легко можем перебросить локальный порт 8080 на порт 80 на удаленной машине. Иными словами, если мы напишем IP адрес нашей машины и порт 8080, то запрос пойдет на 80 порт удалённой системы.
Если вам не критично какой порт использовать на своем хосте, лучше выбрать что-то из диапазона 2000-10000, так как все порты ниже 2000 зарезервированы.
Переброс локального порта
Локальная пересылка представляет собой переброс порта из клиентской системы на сервер. Он позволяет настроить порт в системе таким образом, чтобы все соединения на этот порт проходили через туннель SSH.
Для переадресации локального порта используется ключ L. Общий синтаксис команды таков:
$ ssh -L local_port:remote_ip:remote_port user@hostname.com
$ ssh -L 8080:www.example1.com:80 example2.com
Данной командой мы говорим системе, что все запросы на 8080 порт example1.com переадресовывать на example2.com. Это часто используется когда нужно организовать доступ извне на внутренний ресурсы компании.
Тестирование работы переадресованного порта
Чтобы проверить, работает ли переадресация должным образом можно воспользоваться утилитой netcat. На машине, где была запущена команда переадресации нужно ввести команду netcat в следующем виде:
$ nc -v remote_ip port_number
Если переадресация работает и трафик проходит, то утилита вернёт "Успех!". В противном случае выдаст ошибку об истечении времени ожидания.
Если что-то не работает, нужно убедиться, что подключение к удаленному порту по SSH работает корректно и запросы не блокируются межсетевым экраном.
Создание постоянного туннеля (Autossh)
Для создания туннеля, который будет активен постоянно используется так называемая утилита Autossh. Единственно требование это необходимость настройки между двумя системами аутентификацию по публичным ключам, чтобы не получать запросы на ввод пароля при каждом обрыве и восстановлении соединения.
По умолчанию, Autossh не установлен. Чтобы установить эту утилиту введем команду ниже.
$ sudo apt-get install autossh
Синтаксис утилиты autossh почти похож на синтаксис ssh:
$ autossh -L 80:example1.com:80 example2.com
Переброс удалённого порта
Переброс порта с удалённой машины используется в тех случаях, если нужно предоставить доступ на свой хост. Допусти у нас установлен веб сервер и нам нужно, чтобы друзья могли пользоваться им. Для этого нужно ввести команду показанную ниже:
$ ssh -R 8080:localhost:80 geek@likegeeks.com
А общий синтаксис команды выглядит так:
$ ssh -R remote_port:local_ip:local_port user@hostname.com
Динамическая переадресация портов
Динамическая переадресация портов позволит ssh функционировать как прокси-сервер. Вместо переброса трафика на специфический порт, здесь трафик будет идти через на диапазон портов.
Если вы когда-нибудь пользовались прокси сервером для посещения заблокированного сайта или просмотра контента, недоступного в вашем регионе, вероятнее всего вы пользовались SOCKS сервером.
Динамическая переадресация также обеспечивает некоторую приватность. Она затрудняет логирование и анализ трафика, так как трафик проходит через промежуточный сервер. Для настройки динамической переадресации используется следующая команда:
$ ssh -D local_port user@hostname.com
Таким образом, если нужно весь трафик идущий на порт 1234 направить на SSH сервер, нужно ввести команду:
$ ssh -D 1234 geek@likegeeks.com
После установления соединения, мы можем указать в приложениях, например, браузере, пропускать трафик через туннель.
Множественная переадресация
Иногда приходится перебрасывать несколько внутренних портов на несколько внешних. Допустим у нас на одном и том же сервере крутятся и веб сервер и oracale. В таком случае мы можем указать несколько условий переадресации ставя перед каждым из них ключ L для локальной переадресации и R для внешней.
$ ssh -L local_port_1:remote_ip:remote_port_1 -L local_port_2:remote_ip:remote_port2 user@hostname.com
$ ssh -L 8080:192.168.1.1:80 -L 4430:192.168.1.1:1521 user@hostname.com
$ ssh -R remote_port1:local_ip:local_port1 remote_port2:local_ip:local_port2 user@hostname.com
Просмотр списка туннелей
Чтобы просмотреть сколько SSH туннелей активны на данный момент можно прибегнуть к помощи команды lsof:
$ lsof -i | egrep '<ssh>'
Как видим, на нашей системе сейчас активно три подключения. Чтобы вместо имени хоста показать IP адрес к команде нужно добавить ключ n.
$ lsof -i -n | egrep '<ssh>'
Ограничение переадресации портов
По умолчанию, переброс портов SSH активен для всех. Но если нужно ограничить переадресацию портов в целях безопасности, то нужно отредактировать файл sshd_config.
$ sudo vi /etc/ssh/sshd_config
Здесь есть несколько опций, позволяющих ограничивать создание SSH туннелей.
PermitOpen позволяет прописать адреса, для которых можно включить переадресацию портов. Тут можно указать конкретный IP адреса или название хоста:
PermitOpen host:port
PermitOpen IPv4_addr:port
PermitOpen [IPv6_addr]:port
AllowTCPForwarding данная опция включает или отключает переадресацию портов для SSH. Так же можно указать какой тип переадресации допускается на этом хосте.
AllowTCPForwarding yes #default setting
AllowTCPForwarding no #prevent all SSH port forwarding
AllowTCPForwarding local #allow only local SSH port forwarding
AllowTCPForwarding remote #allow only remote SSH port forwarding
Для подробной информации можно вызвать руководство по файлу sshd_config:
$ man sshd_config
Уменьшение задержки
Проблема с переадресацией портов на SSH это возможность увеличения задержки. При работе с текстовой информацией э то не критично. Проблема даёт о себе знать если по сети идёт много трафика, а SSH сервер настрое как SOCKS сервер, то есть на нём настроена динамический переброс портов.
Это происходит по той причине, что SSH туннели по сути это TCP туннель поверх TCP. Это не очень эффективный метод передачи данных.
Для решения проблемы можно настроить VPN, но если по какой-то причине предпочитаете SSH туннели, то существует программа sshuttle, которая устраняет проблему. На Ubuntu или других дистрибутивах семейства Debian программу можно установить командой
$ sudo apt-get install sshuttle
Если же программы нет в репозиториях дистрибутива, то можно взять ее с GitHub:
$ git clone https://github.com/sshuttle/sshuttle.git
$ cd sshuttle
$ ./setup.py install
Настройка туннеля в sshuttle отличается от SSH. Чтобы завернуть весь трафик в туннель нужно ввести следующую команду:
$ sudo sshuttle -r user@remote_ip -x remote_ip 0/0 vv
Прервать соединение можно комбинацией клавиш Ctrl+C. Чтобы запустить sshuttle как демон, нужно добавить ключ D.
Чтобы убедиться что туннель поднят и в глобальной сети показывается другой IP, в терминале можно ввести команду:
$ curl ipinfo.io
Или же просто открыть любой другой сайт, который покажет белый IP и местоположение.
Бизнес процессы в CRM – системе Битрикс24 позволяют упростить жизнь рядовым сотрудникам, автоматизируя различные сферы деятельности. В статье мы хотим рассказать о цикличном бизнес процессе, который будет запускать до тех пор, пока сделка находится в статусе «Дожатие»
Сценарий
Предположим, мы сконвертировали лида в сделку, выставили предложение и ждем реакции от клиента. В таком случае, с клиентом необходимо периодически связываться, уточняя, как у него обстоят дела, не решился ли он на покупку нашей услуги/товара.
Чтобы ответственный менеджер не забыл про нашего клиента, мы хотим чтобы ему периодически (раз в три дня) приходили напоминания на почту о том, что данная сделка все еще находится на этапе «Дожатие» и с клиентом необходимо связаться. Это плоский, и весьма тривиальный бизнес процесс, но надо заметить, весьма эффективный. Как только менеджер сменит статус сделки на любой другой, или сконвертирует ее, сообщения приходить перестанут.
Битрикс24 бесплатно!
Реализация
Переходим к настройке бизнес процессов. В разделе CRM →
Настройки → Автоматизация → Бизнес-процессы и нажимаем Добавить шаблон:
Во вкладке «Основное» даем название для бизнес – процесса, даем небольшое описание и снимаем галочки с параметров автоматического запуска, как показано ниже:
Нажимаем «Сохранить». Переносим в рабочее поле необходимые элементы. В разделе «Конструкции», переносим элемент «Цикл». Нажатием на значок шестеренки этого элемента производим следующие настройки:
Заголовок - название для элемента
Тип условия - установите «Поле документа»
Поле документа - указываем «Стадия сделки»
Условие - выставляем «Равно»
Значение - этап сделки под название «Дожатие»
Условно говоря, наш цикл, будет выполняться до тех пор, пока статус сделки будет равен «Дожатие». Как только он будет изменен, бизнес процесс будет закончен. Добавляем элементы «Почтовое сообщение» и «Уведомление пользователя» из раздела «Уведомления» последовательно в цикле. В настройках почтового уведомления производим следующие настройки:
Заголовок - название элемента внутри бизнес – процесса. Носит локальный характер
Отправитель сообщения - с какого email адреса будет отправлено письмо.
Получатель сообщения - адрес электронной почты адресата сообщения. В нашем случае, указана переменная {=Document:ASSIGNED_BY_EMAIL}, в которой хранится адрес электронной почты ответственного по данной сделке.
Тема сообщения - тема электронного письма
Текст сообщения - сообщение, которое будет отправлено адресату. Можно (и нужно) использовать переменные.
Тип сообщения - типа может быть либо текстовый, либо html. В последнем случае, вы можете применять оформление письма с помощью html кода. Рекомендуем табличную верстку, как в случае с email рассылкой
Помимо почтового уведомления, мы настроим отправку сообщения внутри Битрикс24. Переходим к опция настройки элемента «Уведомление пользователя»:
Заголовок - так же имеет локальное значение внутри бизнес процесса
Отправитель уведомления - пользователь, от которого поступит сообщение. В нашем случае это руководитель отдела продаж.
Получатель уведомления - переменная, в которой хранится ответственный по сделке.
Текст уведомления для сайта - сообщение, которое получит юзер внутри Битрикс24
Тип уведомления - мы выбираем персонализированное уведомление от руководителя отдела продаж. Чтобы неповадно было :)
Как было сказано в начале статье, уведомления мы хотим посылать один раз в три дня. Находим раздел элементов «Прочее» и добавляем элемент «Пауза в выполнении». Производим его настройку, она тривиальна:
Готово. Мы сделали простенький бизнес – процесс для отработки конкретного статуса. На финальном этапе он выглядит вот так:
Сохраняем. Теперь нам необходимо создать служебный бизнес – процесс, который будет отслеживать изменение статусов. Как и ранее, в разделе «Сделка» нажимаем «Добавить шаблон»:
Все настройки идентичны предыдущим, за исключение параметров автоматического запуска. Здесь мы выставляем галочку «При изменении».
Производим настройку элементов бизнес – процесса. В разделе «Конструкции» добавляем элемент «Условие». По умолчанию, данный блок имеет два ответвления. Выбираем любое, и переходим к его настройке:
Заголовок - локальное значение. Для наглядности мы назвали его согласно статусу – «Дожатие»
Тип условия - выставляем «Поле документа»
Поле документа - проверять будем стадию сделки
Условия - равняется ли заданное поле нашему значению. Выставляем «Равно».
Значение - тут выставляем «Дожатие»
Следом за этим блоком добавляем из раздела «Обработка документа» элемент «Запуск бизнес-процесса» со следующими параметрами:
Заголовок - любое удобное наименование
ID документа - ID документа и указание сущности. Так как мы работаем со сделками, то указываем префикс DEAL_
Сущность - указываем «Сделка»
Тип документа - укажите «Сделка»
Шаблон - выберите бизнес – процесс, который необходимо запустить. В нашем случае это созданный БП «Дожатие»
Для запуска бизнес-процесса изнутри бизнес-процесса используйте префикс CONTACT_, COMPANY_, DEAL_, LEAD_.
Во второй ветке условия настройка тривиальна:
В результате мы имеем следующую картину:
Сохраняем и закрываем. Готово. Теперь, когда наш менеджер переведет сделку в статус «Дожатие», ему раз в три дня будет приходить напоминания о том, что данная сделка нуждается в его внимании. Как только сделка будет сконвертирована или переведена в иной статус, уведомления прекратятся.
Предыдущая статья из цикла про популярные приложения TCP/IP тут.
Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.
Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.
TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP.
На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.
TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:
Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками.
Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками.
Восстановление после ошибок и надежность
TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.
На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)
Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)
Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.
Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.
Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.
Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.
Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.
Управление потоком с использованием окон
TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель.
Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках.
Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.
Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).
Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.
Закрепим самое важное про TCP и UDP в следующей статье.