По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Port Forwarding – или проброс портов, который также иногда называемый перенаправлением портов или туннелированием – это процесс пересылки трафика, адресованного конкретному сетевому порту с одного сетевого узла на другой. Этот метод позволяет внешнему пользователю достичь порта на частном IPv4-адресе (внутри локальной сети) извне, через маршрутизатор с поддержкой NAT.
Обычно peer-to-peer (p2p) программы и операции обмена файлами, такие как веб-сервер и FTP, требуют, чтобы порты маршрутизаторов были перенаправлены или открыты, чтобы позволить этим приложениям работать.
Поскольку NAT скрывает внутренние адреса, p2p работает только в ситуации где соединение идет изнутри наружу, где NAT может сопоставлять исходящие запросы с входящими ответами.
Проблема в том, что NAT не разрешает запросы, инициированные извне, но эту ситуацию можно решить с помощью перенаправления портов. Проброс портов может быть настроен для определенных портов, которые могут быть перенаправлены внутренним хостам.
Напомним, что программные приложения в интернете взаимодействуют с пользовательскими портами, которые должны быть открыты или доступны для этих приложений. В различных приложениях используются разные порты. Например, HTTP работает через well-known порт 80. Когда кто-то набирает адрес wiki.merionet.ru то браузер отображает главную страницу нашей базы знаний. Обратите внимание, что им не нужно указывать номер порта HTTP для запроса страницы, потому что приложение принимает порт 80. Если требуется другой номер порта, его можно добавить к URL-адресу, разделенному двоеточием (:). Например, если веб-сервер слушает порт 8080, пользователь вводит http://www.example.com:8080.
Проброс портов позволяет пользователям в интернете получать доступ к внутренним серверам с помощью адреса порта WAN маршрутизатора и соответствующего номера внешнего порта. Внутренние серверы обычно конфигурируются с частными адресами IPv4 и когда запрос отправляется на адрес порта WAN через Интернет, маршрутизатор перенаправляет запрос на соответствующий сервер в локальной сети. По соображениям безопасности широкополосные маршрутизаторы по умолчанию не разрешают перенаправление любого внешнего сетевого запроса на внутренний хост.
Пример с ”домашним” роутером
На схеме показан пример, когда проброс портов выполнятся при помощи домашнего SOHO (small office/home office) роутера. Переадресация портов может быть включена для приложений при помощи указания внутреннего локального адреса. Пользователь в интернете вводит адрес //wiki.merionet.ru, который соответствует внешнему адресу 212.193.249.136 и пакет попадает на маршрутизатор, который перенаправляет HTTP-запрос на внутренний веб-сервер по адресу IPv4 192.168.1.10, используя номер порта по умолчанию 80.
Можно указать порт, отличный от порта 80 по умолчанию. Тем не менее, внешний пользователь должен знать конкретный номер порта для использования. Подход, используемый для настройки перенаправления портов, зависит от марки и модели маршрутизатора.
Настройка проброса порта
Реализация перенаправления (проброса) портов с помощью команд IOS аналогична командам, используемым для настройки статического NAT. Переадресация портов - это, по существу, статическая трансляция NAT с указанным номером TCP или UDP-порта.
В общем виде основная команда выглядит так:
ip nat inside source {static{tcp | udp local-ip local-port global-ip global-port} [extendable]
где:
tcp или udp – указывает это tcp или udp порт;
local-ip – это ip адрес присвоенный хосту внутри сети;
local-port – устанавливает локальный tcp/udp порт в диапазоне от 1 до 65535. Это номер порта, который слушает сервер;
global-ip – это уникальный глобальный IP адрес внутреннего хоста, по которому клиенты в интернете будут связываться с ним;
global-port – устанавливает глобальный tcp/udp порт в диапазоне от 1 до 65535. Это номер порта снаружи, по которому будут связываться клиенты;
extendable – эта опция применяется автоматически. Она разрешает пользователю настраивать двойственные статические трансляции, если они идут на один и тот же адрес;
Пример настройки:
Router(config)#Ip nat inside source static tcp 192.168.1.10 80 212.193.249.136:8080
Router(config)# interface serial0/0/0
Router(config-if)# ip nat outside
Router(config)# interface serial0/0/1
Router(config-if)# ip nat inside
Показана настройка для данной схемы, где 192.168.1.10 - внутренний локальный адрес IPv4 веб-сервера, прослушивающий порт 80. Пользователи получат доступ к этому внутреннему веб-серверу, используя глобальный IP-адрес 212.193.249.136:, глобальный уникальный публичный IPv4-адрес. В этом случае это адрес интерфейса Serial 0/0/1. Глобальный порт настроен как 8080. Это будет порт назначения, вместе с глобальным адресом 212.193.249.136 для доступа к внутреннему веб-серверу. Как и другие типы NAT, перенаправление портов требует конфигурации как внутренних, так и внешних NAT-интерфейсов.
Подобно статическому NAT, команда show ip nat translations может использоваться для проверки переадресации портов.
Router# show ip nat translations
Pro Inside Global Inside Local Outside local Outside global
tcp 212.193.249.136:8080 192.168.1.10:80 212.193.249.17:46088 212.193.249.17:46088
tcp 212.193.249.136:8080 192.168.1.10:80 --- ---
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки:
Первую часть статьи про траблшутинг EIGRP можно почитать здесь.
Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась.
Было настроено автосуммирование или кто-то настроил суммирование вручную
Split-horizon блокирует объявление маршрутной информации.
Перераспределение было настроено, но информация из EIGRP не используется.
Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются.
Case #1
Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов:
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 1.1.1.0 0.0.0.255
OFF1(config-router)#network 192.168.12.0 0.0.0.255
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config-router)#network 192.168.12.0 0.0.0.255
Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите:
По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации.
Видно, что на OFF1 не настроен distribute lists.
OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит.
Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list.
Другой быстрый способ проверить это - использовать команду show ip protocol.
В этом случае использование show run могло бы быстрее обнаружить distribute-list.
Вот список доступа, доставляющий нам неприятности.
OFF2(config)#router eigrp 12
OFF2(config-router)#no distribute-list 1 out
Удалим distribute-list.
Задача решена!
Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации.
Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа.
Case #2
В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация:
OFF1(config)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF1(config-router)#network 10.0.0.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.12.0
OFF2(config-router)#network 10.0.0.0
Как вы видите - это довольно базовая конфигурация.
Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации.
Давайте включим отладку и посмотрим, что мы можем найти.
OFF2#clear ip eigrp 12 neighbors
Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс.
Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам:
Суммирование было кем-то настроено
Авто-суммирование включено для EIGRP.
Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
Отключение автоматического суммирования должно помочь.
Ну что, наши сети появились в таблице маршрутизации.
Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями.
Case #3
Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов:
Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование.
Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16.
Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит?
OFF2#clear ip eigrp 12 neighbors
Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс.
Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1.
Давайте проведем отладку OFF1.
Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его.
Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование.
Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена!
Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов.
Case #4
Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов.
Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах.
Суммирование было настроено на OFF2 и должно быть объявлено к OFF1.
К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так.
Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show.
Странно, это единственная сеть, которую OFF2 объявляет.
Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24.
Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи.
OFF2(config)#interface loopback 0
OFF2(config-if)#no shutdown
OFF2(config)#interface loopback 1
OFF2(config-if)#no shutdown
Включим интерфейсы.
Теперь мы видим, что суммирование объявляется.
Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена!
Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации.
ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон!
Case #5
Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов:
CONC(config)#router eigrp 123
CONC(config-router)#no auto-summary
CONC(config-router)#network 192.168.123.0
OFF1(config-if)#router eigrp 123
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 192.168.123.0
OFF1(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config)#router eigrp 123
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 192.168.123.0
OFF2(config-router)#network 3.3.3.0 0.0.0.255
Видно, что все сети объявлены.
Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов.
К сожалению, наши маршрутизаторы не видят ничего ...
Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит.
CONC#clear ip eigrp 123 neighbors
Сбросим соседство EIGRP, чтобы ускорить процесс.
В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой.
CONC(config)#interface serial 0/0
CONC(config-if)#no ip split-horizon eigrp 123
Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора.
Теперь мы видим, что маршрутизатор-концентратор объявляет все сети.
OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все.
Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали.
Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить.
Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом:
Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3:
Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1?
Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC.
У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2.
Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом:
Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем!
Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2
Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3.
Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2.
OFF2(config)#int s0/0
OFF2(config-if)#frame-relay map ip 192.168.123.2 301
Давайте frame-relay map сами.
Теперь роутер OFF2 знает, как связаться с роутером OFF1
Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map:
OFF1(config)#int s0/0
OFF1(config-if)#frame-relay map ip 192.168.123.3 201
Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1.
И наш пинг проходит!
Начиная с 2013 года по планете Земля начали свое победное шествие программы шифровальщики, требующие выкуп. Начал этот злостный хайп шифровальщик Cryptolocker, а затем были слышны такие громкие имена как Petya, NotPetya, WannaCry и иже с ними.
Мы хотели бы показать и объяснить механизмы работы подобного вида зловредного ПО, так как первичный источник заражения в организации обычно одинаковый и являет собой спам письмо – ниже, в последовательных шагах объясним, как, почему и зачем ОНО это делает.
Само заражение, подробно и без приукрас.
Конечный пользователь получает письмо как-будто бы от его начальника, в котором находится ссылка на популярный облачный сервис - Битрикс24, Salesforce, ZenDesk и так далее.
По ссылке открывается окно браузера и направляет пользователя на сайт, который выглядит вполне нормально и являет собой лэндинг для эксплойт кита.
До загрузки страницы, веб-сервер, на котором находится эксплойт-кит, начинает коммуникацию с компьютером жертвы и пытается понять какая версия Java используется для использования эксплойта в уязвимой версии.
Когда кто получает подтверждение уязвимости конкретной версии, эксплойт начинает свою работу и, в случае успеха, он загружает на рабочую станцию некий .EXE файл, и он начинает выполняться.
Экзешник создаёт дочерний процессы, который включает в себя процесс vssadmin.exe (теневую копию). Данный процесс удаляет имеющиеся теневые копии на компьютере жертвы и создаёт новые. Теневые копии, создаваемые самой ОС Windows, позволяют восстановить информацию - и поэтому WannaCry всеми силами пытается снизить вероятность восстановления файлов.
Далее WannaCry использует исполняемый PowerShell файл для распространения своих копий по системе и запускает шифрование файлов с определенными расширениями.
Дочерний процесс powershell.exe создает ещё три копии оригинального зловредного кода - сначала в директории AppData, затем в Start и в корневом каталоге диска C: . Данные копии используются совместно с модификациями регистра для автоматического перезапуска WannaCry после перезагрузки системы и различных событий.
После шифрования файлов на компьютере, малварь отправляет ключ шифрования и другую информацию в командный центр (C2).
Далее жертва получает сообщение, причем это может быть как банальное информирование пользователя о шифровке файлов и инструкций о передаче выкупа, так и установке другого зловредного ПО, например для кражи учётных данных.
Как правило, для усиления эффекта, на экране компьютера появляется таймер обратного отсчёта с указанием дедлайна, когда нужно отправить выкуп. Если не отправить вовремя, ключ для расшифровки будет уничтожен - то есть больше не останется шансов на восстановление вашей информации.
Обычно, оплата выкупа означает то, что вам пришлют ключ для расшифровки - но это совершенно точно не означает, что сам зловредный файл тоже удалится с машины жертвы. Обычно, в таких случаях нужно привлечь вашу службу ИБ или ИТ.
И, как уже было сказано выше, очень часто шифровальщики используются как некая маскировка более глубокой атаки на организацию - то есть кража учётных записей, персональных данных и прочие.
Наш посыл прост – не открывайте подозрительных ссылок! Особенно, если они пришли по электронной почте от людей, от которых не должно подобное приходить – руководитель компании и так далее. Старайтесь более ответственно относится к времяпрепровождению в Интернете, и тогда ИТ-службе (а это скорее всего вы и есть) будет гораздо спокойнее жить.