8 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Разница между NAT и Proxy

NAT — это технология, позволяющая подключать ПК, объединенные в локальную сеть, к интернету при задействовании механизма трансляции IP-адресов (либо портов) в сетевое пространство за пределами ЛВС. Каждый ПК, подключенный к локальной сети, осуществляет запросы в службу NAT, которая преобразует их в те, что адресованы тем или иным сервисам интернета.

Использование технологии NAT, как правило, предполагает задействование отдельного сетевого устройства — маршрутизатора, сервера или же, например, межсетевого экрана.

Даже если к интернету посредством технологии NAT подключается несколько компьютеров одновременно, онлайновый сервер видит запросы только с одного IP-адреса — устанавливающегося на устройстве, в котором реализованы алгоритмы NAT.

Есть две основные разновидности рассматриваемой технологии — Source NAT и Destination NAT.

Первая предполагает замену адреса, установленного для источника пакета, при передаче данного пакета на компьютер назначения в интернете и, соответственно, замену адреса, установленного для ПК назначения в локальной сети, при отправлении пакета обратно. При необходимости меняться могут также номера портов ПК в ЛВС.

Технология Destination NAT предполагает трансляцию пакетов, направляемых в ЛВС из внешней среды — например, с онлайнового сервера, на конкретный ПК, имеющий локальный IP-адрес, который недоступен для соответствующего онлайнового сервера.

Основное преимущество применения схемы подключения ЛВС к интернету через NAT — централизация настроек соответствующей службы. Нет необходимости выставлять какие-либо специальные опции на каждом из ПК, подключенном к локальной сети.

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

Прокси-серверы могут быть как программными (поддерживающими различные платформы Linux, Windows), так и программно-аппаратными, уже готовыми для использования решениями.

Прокси-серверы, как правило, имеют следующие функции:

  • Предоставление доступа компьютерам и другим устройствам в сети во внешнюю сеть интернет.
  • Кэширование информации. Это позволяет уменьшить нагрузку на сеть, за счет хранения в памяти прокси-сервера кэша ранее открываемых веб-сайтов.
  • Сжатие передаваемой информации. Эта функция позволяет снизить количество поступаемого трафика, как извне, так и внутри организации.
  • Возможность использования NAT (Network Address Translation). Другими словами, при выполнении сетевого запроса получателем запроса будет являться прокси-сервер, который далее выполнит этот запрос от своего имени. Такое решение позволяет обезопасить внутреннюю сеть организации и не раскрывать сетевую адресацию.
  • Возможность фильтрации контента. К этому определению относится как настройка запрета перехода на определенный перечень веб-страниц, так и установление параметров квоты на трафик для каждого пользователя, полосы пропускания. Прокси-серверы позволяют обеспечивать фильтрацию рекламы и ее блокирование.
  • Возможность получения доступа к контенту, который может быть заблокирован для некоторых стран. Реализация такой функции позволяет обращаться к запрещенным веб-сайтам за счет настройки соединения через прокси-серверы других стран, в которых требуемые веб-сайты разрешены.

Прокси-серверы делятся на следующие виды:

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

Далее представлена еще одна классификация прокси-серверов:

  • CGI — прокси-серверы для поиска веб-страниц. Если пользователю требуется открыть запрещенный веб-сайт, ему необходимо зайти на специальный сайт прокси-сервера, и ввести в нем требуемый URL-адрес, как в поисковике.
  • HTTP/SHTTP — прокси-серверы в привычном для всех представлении. Различие HTTP-прокси от SHTTP заключается в поддержке протокола SSL.
  • SOCKS4, SOCKS5 — прокси-серверы позволяющие перенаправлять запросы не только от браузеров, но и других приложений.
  • Автор: Уваров А.С.
  • 08.07.2019

Проброс портов — на первый взгляд тривиальная повседневная задача, которая не должна вызывать никаких затруднений. Действительно, в бытовых роутерах это так, но если речь идет об оборудовании Mikrotik, то сложности могут не заставить себя ждать. А все потому, что RouterOS дает в руки администратора богатые сетевые возможности, требуя в ответ понимания работы сетей хотя бы на базовом уровне. Конечно, можно настроить все по готовой инструкции, но гораздо лучше понимать каждое свое действие, и именно для тех, кто хочет разобраться предназначена эта статья.

Проброс портов

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

Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.

Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.

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

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

Маршрутизатор на основании данных таблицы трансляции выполнит обратное преобразование, заменив на этот раз адрес источника с внутреннего адреса веб-сервера, на свой внешний адрес и отправит пакет запросившему его узлу.

На первый взгляд все понятно, поэтому перейдем к практике. В RouterOS в качестве сетевого фильтра используется iptables, поэтому далее мы будем оперировать его терминами. В таблице NAT используются две цепочки: PREROUTING — в которую попадают все пришедшие на маршрутизатор пакеты и POSTROUTING — через нее проходят все прошедшие через устройство пакеты. В PREROUTING нам доступно действие dst-nat (DNAT), которое позволяет изменить адрес назначения пакета, в POSTROUTING будут доступны src-nat (SNAT) и masquerade, которые позволяют изменить адрес источника пакета.

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

Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:

Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.

Как правильно выполнить настройку? Перейдем в IP — Firewall — NAT и добавим следующее правило: Chain — dstnat (читай PREROUTING), Dst. Address — 192.168.1.113 — внешний IP-адрес нашего роутера, Protocol — tcp — используемый протокол, если сервис может использовать несколько протоколов, скажем TCP и UDP — потребуется создать отдельное правило для каждого протокола, Dst. Port — 80 — порт, на котором маршрутизатор будет принимать внешние соединения.

На закладке Action укажите: Action — dst-nat — выполняем замену адреса получателя, To Addresses — 192.168.186.195 — внутренний адрес веб-сервера, To Ports — 80 — порт, на котором веб-сервер принимает соединения. Если внешний и внутренний порт совпадают, то последний можно не указывать.

Либо выполните в терминале:

Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.

Создадим новое правило. IP — Firewall — Filter Rules, где добавим: Chain — forward — цепочка FORWARD, Protocol — tcp, Dst. Port — 80 — протокол и порт, In. Interface — ether5 — внешний интерфейс вашего роутера. Так как по умолчанию в новых правилах стоит действие accept, на закладку Action можно не переходить.

Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.

Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.

Из терминала это можно сделать командами:

Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:

Как видим, все прекрасно работает.

Hairpin NAT

Все это хорошо, но ровно до тех пор, пока мы не попытаемся получить доступ по внешнему адресу из внутренней сети. Вообще, таких ситуаций следует избегать, предпочтительно использовать для доступа доменные имена и двойной горизонт DNS, когда для внешних пользователей одно и тоже имя разрешается во внешний адрес, а для внутренних — во внутренний. Но это возможно не всегда. Попробовав же обратиться изнутри по внешнему адресу, мы получим ошибку соединения:

Почему так происходит? Давайте рассмотрим еще одну схему:

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

Читать еще:  Обзор смартфона TECNO Spark 4

Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.

Чтобы понять, как это работает мы подготовили следующую схему:

Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.

Для настройки на Mikotik перейдем в IP — Firewall — NAT и добавим: Chain — src-nat (POSTROUTING), Src. Address — 192.168.186.0/24 — диапазон вашей локальной сети, Dst. Address — 192.168.186.195 — внутренний адрес веб-сервера, Protocol — tcp, Dst. Port — 80 — протокол и порт.

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

Затем переходим на закладку Action и указываем: Action — src-nat (SNAT), To Addresses — 192.168.186.1 — указываем внутренний адрес нашего маршрутизатора. Если вы используете на внешнем интерфейсе другой порт, то обязательно укажите его в поле To Ports, если порты совпадают, то делать это необязательно.

Через терминал данное правило можно создать следующим образом:

Во многих иных статьях для данного правила используется действие masquerade, давайте разберемся в чем разница. В первом приближении оба действия делают одно и тоже — изменяют адрес источника пакета, но src-nat работает только со статическими адресами, зато позволяет указать в качестве источника любой адрес, masquerade работает с динамическими адресами, но в качестве адреса источника может использовать только адрес того интерфейса, с которого уходит пакет. За счет того, что masquerade при каждом запросе определяет адрес интерфейса — это действие требует больше вычислительных ресурсов, нежели src-nat.

В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.

Правило создано, проверим его работу:

Если вы нигде не допустили ошибок — все будет работать, как и предполагалось.

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

Что такое Proxy?

Proxy — это технология, которая позволяет подключать ПК, объединенные в сеть, к тем или иным онлайновым сервисам через специальный шлюз, задействующийся отдельными приложениями. То есть для подключения ПК, которые входят в состав ЛВС, к proxy-серверу на каждом из них необходимо выставить настройки соединения. Технология Proxy — это, по сути, программная служба, загружаемая на отдельном сервере ЛВС или на одном из серверов интернета.

Компьютеры, подключенные к ЛВС, запрашивают доступ к онлайн-ресурсам не напрямую, а через IP-адрес и порт proxy-сервера. Данная концепция предопределяет наличие некоторого сходства между Proxy и NAT в том смысле, что онлайновый сервер направляет контент по запросу отдельных ПК на общий IP-адрес, прописанный в настройках proxy-сервера. Конечно, proxy-серверы в некоторых случаях могут устанавливать для подключаемых ПК уникальные внешние IP-адреса — но практически исключено их совпадение с оригинальными IP-адресами, под которыми компьютеры зарегистрированы в ЛВС.

Можно отметить, что существуют чисто «онлайновые» proxy-серверы, которые используются как раз таки в целях намеренной маскировки IP-адресов компьютеров, подключающихся к интернету. Принцип их работы в целом схож с тем, что характеризует функционирование proxy-серверов, устанавливаемых в ЛВС.

Одно из главных преимуществ использования технологии Proxy — возможность осуществлять кеширование онлайнового контента (сохранение в памяти сервера элементов посещенных веб-страниц, загруженных файлов), что позволяет ускорять доступ к интернету с отдельных ПК. Другие преимущества Proxy — в возможности:

  • проводить контроль над доступом отдельных пользователей ЛВС к интернету, фильтрацию контента и адресов сайтов,
  • устанавливать на proxy-серверах антивирусный софт, осуществляющий анализ исходящего и входящего трафика, что позволяет значительно повысить безопасность сети.

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

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

Прокси-серверы могут быть как программными (поддерживающими различные платформы Linux, Windows), так и программно-аппаратными, уже готовыми для использования решениями.

Прокси-серверы, как правило, имеют следующие функции:

  • Предоставление доступа компьютерам и другим устройствам в сети во внешнюю сеть интернет.
  • Кэширование информации. Это позволяет уменьшить нагрузку на сеть, за счет хранения в памяти прокси-сервера кэша ранее открываемых веб-сайтов.
  • Сжатие передаваемой информации. Эта функция позволяет снизить количество поступаемого трафика, как извне, так и внутри организации.
  • Возможность использования NAT (Network Address Translation). Другими словами, при выполнении сетевого запроса получателем запроса будет являться прокси-сервер, который далее выполнит этот запрос от своего имени. Такое решение позволяет обезопасить внутреннюю сеть организации и не раскрывать сетевую адресацию.
  • Возможность фильтрации контента. К этому определению относится как настройка запрета перехода на определенный перечень веб-страниц, так и установление параметров квоты на трафик для каждого пользователя, полосы пропускания. Прокси-серверы позволяют обеспечивать фильтрацию рекламы и ее блокирование.
  • Возможность получения доступа к контенту, который может быть заблокирован для некоторых стран. Реализация такой функции позволяет обращаться к запрещенным веб-сайтам за счет настройки соединения через прокси-серверы других стран, в которых требуемые веб-сайты разрешены.

Прокси-серверы делятся на следующие виды:

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

Далее представлена еще одна классификация прокси-серверов:

  • CGI — прокси-серверы для поиска веб-страниц. Если пользователю требуется открыть запрещенный веб-сайт, ему необходимо зайти на специальный сайт прокси-сервера, и ввести в нем требуемый URL-адрес, как в поисковике.
  • HTTP/SHTTP — прокси-серверы в привычном для всех представлении. Различие HTTP-прокси от SHTTP заключается в поддержке протокола SSL.
  • SOCKS4, SOCKS5 — прокси-серверы позволяющие перенаправлять запросы не только от браузеров, но и других приложений.
  • Автор: Уваров А.С.
  • 08.07.2019

Проброс портов — на первый взгляд тривиальная повседневная задача, которая не должна вызывать никаких затруднений. Действительно, в бытовых роутерах это так, но если речь идет об оборудовании Mikrotik, то сложности могут не заставить себя ждать. А все потому, что RouterOS дает в руки администратора богатые сетевые возможности, требуя в ответ понимания работы сетей хотя бы на базовом уровне. Конечно, можно настроить все по готовой инструкции, но гораздо лучше понимать каждое свое действие, и именно для тех, кто хочет разобраться предназначена эта статья.

Проброс портов

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

Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.

Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.

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

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

Маршрутизатор на основании данных таблицы трансляции выполнит обратное преобразование, заменив на этот раз адрес источника с внутреннего адреса веб-сервера, на свой внешний адрес и отправит пакет запросившему его узлу.

На первый взгляд все понятно, поэтому перейдем к практике. В RouterOS в качестве сетевого фильтра используется iptables, поэтому далее мы будем оперировать его терминами. В таблице NAT используются две цепочки: PREROUTING — в которую попадают все пришедшие на маршрутизатор пакеты и POSTROUTING — через нее проходят все прошедшие через устройство пакеты. В PREROUTING нам доступно действие dst-nat (DNAT), которое позволяет изменить адрес назначения пакета, в POSTROUTING будут доступны src-nat (SNAT) и masquerade, которые позволяют изменить адрес источника пакета.

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

Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:

Читать еще:  Значение слова олдфаг. Олдфаг - что это значит? Кто такой Ньюфаг

Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.

Как правильно выполнить настройку? Перейдем в IP — Firewall — NAT и добавим следующее правило: Chain — dstnat (читай PREROUTING), Dst. Address — 192.168.1.113 — внешний IP-адрес нашего роутера, Protocol — tcp — используемый протокол, если сервис может использовать несколько протоколов, скажем TCP и UDP — потребуется создать отдельное правило для каждого протокола, Dst. Port — 80 — порт, на котором маршрутизатор будет принимать внешние соединения.

На закладке Action укажите: Action — dst-nat — выполняем замену адреса получателя, To Addresses — 192.168.186.195 — внутренний адрес веб-сервера, To Ports — 80 — порт, на котором веб-сервер принимает соединения. Если внешний и внутренний порт совпадают, то последний можно не указывать.

Либо выполните в терминале:

Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.

Создадим новое правило. IP — Firewall — Filter Rules, где добавим: Chain — forward — цепочка FORWARD, Protocol — tcp, Dst. Port — 80 — протокол и порт, In. Interface — ether5 — внешний интерфейс вашего роутера. Так как по умолчанию в новых правилах стоит действие accept, на закладку Action можно не переходить.

Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.

Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.

Из терминала это можно сделать командами:

Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:

Как видим, все прекрасно работает.

Hairpin NAT

Все это хорошо, но ровно до тех пор, пока мы не попытаемся получить доступ по внешнему адресу из внутренней сети. Вообще, таких ситуаций следует избегать, предпочтительно использовать для доступа доменные имена и двойной горизонт DNS, когда для внешних пользователей одно и тоже имя разрешается во внешний адрес, а для внутренних — во внутренний. Но это возможно не всегда. Попробовав же обратиться изнутри по внешнему адресу, мы получим ошибку соединения:

Почему так происходит? Давайте рассмотрим еще одну схему:

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

Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.

Чтобы понять, как это работает мы подготовили следующую схему:

Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.

Для настройки на Mikotik перейдем в IP — Firewall — NAT и добавим: Chain — src-nat (POSTROUTING), Src. Address — 192.168.186.0/24 — диапазон вашей локальной сети, Dst. Address — 192.168.186.195 — внутренний адрес веб-сервера, Protocol — tcp, Dst. Port — 80 — протокол и порт.

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

Затем переходим на закладку Action и указываем: Action — src-nat (SNAT), To Addresses — 192.168.186.1 — указываем внутренний адрес нашего маршрутизатора. Если вы используете на внешнем интерфейсе другой порт, то обязательно укажите его в поле To Ports, если порты совпадают, то делать это необязательно.

Через терминал данное правило можно создать следующим образом:

Во многих иных статьях для данного правила используется действие masquerade, давайте разберемся в чем разница. В первом приближении оба действия делают одно и тоже — изменяют адрес источника пакета, но src-nat работает только со статическими адресами, зато позволяет указать в качестве источника любой адрес, masquerade работает с динамическими адресами, но в качестве адреса источника может использовать только адрес того интерфейса, с которого уходит пакет. За счет того, что masquerade при каждом запросе определяет адрес интерфейса — это действие требует больше вычислительных ресурсов, нежели src-nat.

В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.

Правило создано, проверим его работу:

Если вы нигде не допустили ошибок — все будет работать, как и предполагалось.

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

Что такое Proxy?

Proxy — это технология, которая позволяет подключать ПК, объединенные в сеть, к тем или иным онлайновым сервисам через специальный шлюз, задействующийся отдельными приложениями. То есть для подключения ПК, которые входят в состав ЛВС, к proxy-серверу на каждом из них необходимо выставить настройки соединения. Технология Proxy — это, по сути, программная служба, загружаемая на отдельном сервере ЛВС или на одном из серверов интернета.

Компьютеры, подключенные к ЛВС, запрашивают доступ к онлайн-ресурсам не напрямую, а через IP-адрес и порт proxy-сервера. Данная концепция предопределяет наличие некоторого сходства между Proxy и NAT в том смысле, что онлайновый сервер направляет контент по запросу отдельных ПК на общий IP-адрес, прописанный в настройках proxy-сервера. Конечно, proxy-серверы в некоторых случаях могут устанавливать для подключаемых ПК уникальные внешние IP-адреса — но практически исключено их совпадение с оригинальными IP-адресами, под которыми компьютеры зарегистрированы в ЛВС.

Можно отметить, что существуют чисто «онлайновые» proxy-серверы, которые используются как раз таки в целях намеренной маскировки IP-адресов компьютеров, подключающихся к интернету. Принцип их работы в целом схож с тем, что характеризует функционирование proxy-серверов, устанавливаемых в ЛВС.

Одно из главных преимуществ использования технологии Proxy — возможность осуществлять кеширование онлайнового контента (сохранение в памяти сервера элементов посещенных веб-страниц, загруженных файлов), что позволяет ускорять доступ к интернету с отдельных ПК. Другие преимущества Proxy — в возможности:

  • проводить контроль над доступом отдельных пользователей ЛВС к интернету, фильтрацию контента и адресов сайтов,
  • устанавливать на proxy-серверах антивирусный софт, осуществляющий анализ исходящего и входящего трафика, что позволяет значительно повысить безопасность сети.

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

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

Прокси-серверы могут быть как программными (поддерживающими различные платформы Linux, Windows), так и программно-аппаратными, уже готовыми для использования решениями.

Прокси-серверы, как правило, имеют следующие функции:

  • Предоставление доступа компьютерам и другим устройствам в сети во внешнюю сеть интернет.
  • Кэширование информации. Это позволяет уменьшить нагрузку на сеть, за счет хранения в памяти прокси-сервера кэша ранее открываемых веб-сайтов.
  • Сжатие передаваемой информации. Эта функция позволяет снизить количество поступаемого трафика, как извне, так и внутри организации.
  • Возможность использования NAT (Network Address Translation). Другими словами, при выполнении сетевого запроса получателем запроса будет являться прокси-сервер, который далее выполнит этот запрос от своего имени. Такое решение позволяет обезопасить внутреннюю сеть организации и не раскрывать сетевую адресацию.
  • Возможность фильтрации контента. К этому определению относится как настройка запрета перехода на определенный перечень веб-страниц, так и установление параметров квоты на трафик для каждого пользователя, полосы пропускания. Прокси-серверы позволяют обеспечивать фильтрацию рекламы и ее блокирование.
  • Возможность получения доступа к контенту, который может быть заблокирован для некоторых стран. Реализация такой функции позволяет обращаться к запрещенным веб-сайтам за счет настройки соединения через прокси-серверы других стран, в которых требуемые веб-сайты разрешены.

Прокси-серверы делятся на следующие виды:

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

Далее представлена еще одна классификация прокси-серверов:

  • CGI — прокси-серверы для поиска веб-страниц. Если пользователю требуется открыть запрещенный веб-сайт, ему необходимо зайти на специальный сайт прокси-сервера, и ввести в нем требуемый URL-адрес, как в поисковике.
  • HTTP/SHTTP — прокси-серверы в привычном для всех представлении. Различие HTTP-прокси от SHTTP заключается в поддержке протокола SSL.
  • SOCKS4, SOCKS5 — прокси-серверы позволяющие перенаправлять запросы не только от браузеров, но и других приложений.
  • Автор: Уваров А.С.
  • 08.07.2019
Читать еще:  Места Где Я Был - ТОП-10 Сервисов Для Туристов

Проброс портов — на первый взгляд тривиальная повседневная задача, которая не должна вызывать никаких затруднений. Действительно, в бытовых роутерах это так, но если речь идет об оборудовании Mikrotik, то сложности могут не заставить себя ждать. А все потому, что RouterOS дает в руки администратора богатые сетевые возможности, требуя в ответ понимания работы сетей хотя бы на базовом уровне. Конечно, можно настроить все по готовой инструкции, но гораздо лучше понимать каждое свое действие, и именно для тех, кто хочет разобраться предназначена эта статья.

Проброс портов

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

Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.

Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.

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

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

Маршрутизатор на основании данных таблицы трансляции выполнит обратное преобразование, заменив на этот раз адрес источника с внутреннего адреса веб-сервера, на свой внешний адрес и отправит пакет запросившему его узлу.

На первый взгляд все понятно, поэтому перейдем к практике. В RouterOS в качестве сетевого фильтра используется iptables, поэтому далее мы будем оперировать его терминами. В таблице NAT используются две цепочки: PREROUTING — в которую попадают все пришедшие на маршрутизатор пакеты и POSTROUTING — через нее проходят все прошедшие через устройство пакеты. В PREROUTING нам доступно действие dst-nat (DNAT), которое позволяет изменить адрес назначения пакета, в POSTROUTING будут доступны src-nat (SNAT) и masquerade, которые позволяют изменить адрес источника пакета.

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

Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:

Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.

Как правильно выполнить настройку? Перейдем в IP — Firewall — NAT и добавим следующее правило: Chain — dstnat (читай PREROUTING), Dst. Address — 192.168.1.113 — внешний IP-адрес нашего роутера, Protocol — tcp — используемый протокол, если сервис может использовать несколько протоколов, скажем TCP и UDP — потребуется создать отдельное правило для каждого протокола, Dst. Port — 80 — порт, на котором маршрутизатор будет принимать внешние соединения.

На закладке Action укажите: Action — dst-nat — выполняем замену адреса получателя, To Addresses — 192.168.186.195 — внутренний адрес веб-сервера, To Ports — 80 — порт, на котором веб-сервер принимает соединения. Если внешний и внутренний порт совпадают, то последний можно не указывать.

Либо выполните в терминале:

Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.

Создадим новое правило. IP — Firewall — Filter Rules, где добавим: Chain — forward — цепочка FORWARD, Protocol — tcp, Dst. Port — 80 — протокол и порт, In. Interface — ether5 — внешний интерфейс вашего роутера. Так как по умолчанию в новых правилах стоит действие accept, на закладку Action можно не переходить.

Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.

Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.

Из терминала это можно сделать командами:

Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:

Как видим, все прекрасно работает.

Hairpin NAT

Все это хорошо, но ровно до тех пор, пока мы не попытаемся получить доступ по внешнему адресу из внутренней сети. Вообще, таких ситуаций следует избегать, предпочтительно использовать для доступа доменные имена и двойной горизонт DNS, когда для внешних пользователей одно и тоже имя разрешается во внешний адрес, а для внутренних — во внутренний. Но это возможно не всегда. Попробовав же обратиться изнутри по внешнему адресу, мы получим ошибку соединения:

Почему так происходит? Давайте рассмотрим еще одну схему:

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

Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.

Чтобы понять, как это работает мы подготовили следующую схему:

Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.

Для настройки на Mikotik перейдем в IP — Firewall — NAT и добавим: Chain — src-nat (POSTROUTING), Src. Address — 192.168.186.0/24 — диапазон вашей локальной сети, Dst. Address — 192.168.186.195 — внутренний адрес веб-сервера, Protocol — tcp, Dst. Port — 80 — протокол и порт.

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

Затем переходим на закладку Action и указываем: Action — src-nat (SNAT), To Addresses — 192.168.186.1 — указываем внутренний адрес нашего маршрутизатора. Если вы используете на внешнем интерфейсе другой порт, то обязательно укажите его в поле To Ports, если порты совпадают, то делать это необязательно.

Через терминал данное правило можно создать следующим образом:

Во многих иных статьях для данного правила используется действие masquerade, давайте разберемся в чем разница. В первом приближении оба действия делают одно и тоже — изменяют адрес источника пакета, но src-nat работает только со статическими адресами, зато позволяет указать в качестве источника любой адрес, masquerade работает с динамическими адресами, но в качестве адреса источника может использовать только адрес того интерфейса, с которого уходит пакет. За счет того, что masquerade при каждом запросе определяет адрес интерфейса — это действие требует больше вычислительных ресурсов, нежели src-nat.

В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.

Правило создано, проверим его работу:

Если вы нигде не допустили ошибок — все будет работать, как и предполагалось.

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

Сравнение

Главное отличие NAT от Proxy — в технологических принципах обеспечения одновременного доступа в интернет нескольких ПК, находящихся в составе ЛВС.

Если говорить о NAT, то данный стандарт управления сетевыми подключениями предполагает применение относительно более простых алгоритмов — когда адрес ПК, отправляющего пакет в интернет, меняется на адрес NAT-устройства, что позволяет последнему получить ответный пакет и доставить его по назначению. Корректировка отправляемого и получаемого пакетов при этом не осуществляется.

Технология Proxy предполагает использование более сложных механизмов обеспечения обмена пакетами между ПК, находящимися в ЛВС, и онлайновыми серверами. Так, например, при задействовании proxy-сервера контент может кешироваться, фильтроваться, проверяться на наличие вирусов.

Определив, в чем разница между NAT и Proxy, зафиксируем основные выводы в небольшой таблице.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector