Как настроить dhcp nat

Windows Server 2019. NAT или как включить Forwarding.

Берем типичную ситуацию. У нас есть сервер с двумя сетевыми интерфейсами. Один подключен к интернету, а другой подключен к локальной сети. Нам бы конечно хотелось что бы локальная сеть тоже была в интернете, например для удаленного доступа на локальную машину или просто нужен интернет (Пикабусики там). Получается сервер у нас выступает шлюзом между двумя сетями которые мы хотим объединить. Для этого настроим NAT.

NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation. Преобразование адреса методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Наиболее популярным является SNAT, суть механизма которого состоит в замене адреса источника (англ. source) при прохождении пакета в одну сторону и обратной замене адреса назначения (англ. destination) в ответном пакете.

Поехали.

Первым делом нам настроить сетевые интерфейсы. Интерфейс который смотрит в интернет (назовем его INT) может получать настройки и по DHCP. А вот локальный ( LOC ) надо настраивать ручками, мы будем шлюзом для всей локальной сети.

Далее нам потребуется добавить роль «Маршрутизация и удалённый доступ» на сервер.

Теперь переходим к настройке маршрутизации :

Настройка и включение маршрутизации — Особая конфигурация — Переадресация сетевых адресов .

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

Вот и все. Теперь нам доступен интернет из локальной сети.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Linux. Настройка роутера (NAT + DHCP + Squid)

Linux. Настройка роутера (NAT + DHCP + Squid)

Наиболее частым применением Linux серверов является организация общего доступа в интернет. Это обусловлено низкой стоимостью такого решения и невысокими требованиями к железу. Во многих случаях это бывает первый Linux сервер в организации, что способно вызвать у администраторов определенные сложности. В данной статье мы пошагово рассмотрим настройку роутера (NAT + DHCP + Squid) на базе Ubuntu Server 9.04

Внимание! Данный материал устарел, при настройке роутера на базе Ubuntu Server 12.04 и старше рекомендуем воспользоваться обновленной статьей.

Установка и первоначальная настройка

Ubuntu Server отличается от своей настольной версии отсутствием графической оболочки и пользовательских приложений, а также возможностью предустановки заранее выбранных ролей сервера. Несмотря на это, все сказанное будет справедливо для любой версии Ubuntu и, с некоторыми поправками, для любого Linux дистрибутива. Установка Ubuntu Server происходит в текстовом режиме на русском языке и, как правило, не вызывает сложностей. Отдельно стоит только остановится на списке ролей: из предложенного нас, пожалуй, может заинтересовать только OpenSSH, для удаленного доступа, однако воспользовавшись пунктом Manual package selection опытный пользователь может сразу установить необходимые ему пакеты.

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

В первую очередь настроим сетевые соединения. Вводим в консоли:

Эта команда откроет в консольном редакторе nano конфигурационный файл с сетевыми интерфейсами, аналогичный рисунку ниже.

Пока там прописан единственный интерфейс eth0, настроенный на работу по DHCP. К eth0 у нас подключен ADSL модем (или любая сеть провайдера), а eth1 смотрит во внутреннюю сеть. IP адрес на внешнем интерфейсе 192.168.1.2, шлюз (ADSL модем) 192.168.1.1, внутренняя сеть лежит в диапазоне 10.0.0.1 — 254. Тогда настройки будут выглядеть следующим образом:

Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем:

В этом файле необходимо указать адреса DNS серверов, лучше всего указать DNS провайдера или, как в нашем случае, OpenDNS.

Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):

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

Также рекомендуем обновить версии пакетов до актуальных:

Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:

Для запуска Midnight Commander достаточно набрать в консоли его краткое имя: mc. Сразу рекомендуем включить встроенный редактор, более удобный чем nano: F9 — Настройки — Конфигурация — Встроенный редактор.

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

Для подключения с Windows станций можно использовать программу PuTTY (скачать), для корректного отображения символов перед подключением необходимо на закладке Window — Translation выбрать кодировку UTF8.

Для ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_config параметр AllowUsers с указанием пользователя имеющего доступ по SSH, например для пользователя admin:

Также можно разрешить доступ определенной группе пользователей используя параметр AllowGroups, либо запретить доступ определенным пользователям / группам использовав DenyUsers и DenyGroups.

Настраиваем NAT

Для организации общего доступа к интернет необходимо настроить трансляцию сетевых адресов (NAT), что позволит сетевым службам внутренней сети получать доступ к внешней сети. Для этого достаточно выполнить всего одну команду, но есть одна тонкость: все будет работать только для перезагрузки. На настоящий момент в Linux нет механизма, который бы сохранял настойки iptables при перезагрузке сервера или сети. Поэтому мы пойдем другим путем и вынесем эти настройки в отдельный скрипт, запускаемый при загрузке системы. Сначала создадим файл скрипта:

Потом откроем его в редакторе Midnight Commander (F4) и внесем следующий текст:

Сохраняем (F2), для автоматического запуска скрипта снова открываем /etc/network/interfaces и в самый конец файла дописываем:

Также не забываем дать нашему скрипту права на исполнение:

Если нигде не допущено ошибок все должно работать. Для проверки укажем на машинах внутренней сети в качестве шлюза и DNS адрес нашего роутера: 10.0.0.1 и пропингуем любой внешний адрес, например один из OpenDNS серверов: 208.67.222.222. Но интернет пока работать не будет. Почему? Да потому, что мы указали в качестве DNS сервера наш роутер, который пока таковым не является. Можно конечно явно прописать DNS на клиентской машине,однако, это не наш метод, если вдруг DNS сервера изменятся, нам что, бегать перепрописывать?

Одно из решений: поднять на нашем роутере полноценный DNS сервер, но в большинстве случаев это избыточно, поэтому мы ограничимся простым кеширующим DNS (а также и DHCP) сервером Dnsmasq.

После установки открываем /etc/dnsmasq.conf, находим, раскомментируем и изменяем следующим образом строку, чтобы разрешить серверу принимать DNS запросы из внутренней сети.:

Перезапускаем DNS сервер:

После чего на клиентских машинах должен заработать интернет.

Настраиваем DHCP

Теперь, когда наш сервер работает, нужно настроить клиентские машины. Можно, конечно, прописать все параметры вручную, но как быть если клиентских машин много и расположены они по всему зданию? Здесь нам на выручку приходит протокол DHCP, который позволяет клиентским машинам получать сетевые настройки автоматически. В качестве DHCP сервера выступит уже установленный Dnsmasq. Настроить его не просто, а очень просто, для чего снова открываем /etc/dnsmasq.conf.

Все что нам надо, это задать диапазон выдаваемых адресов (в нашем случае 10.0.0.100-150), сетевую маску и время, на которое выдается IP адрес:

Адреса DNS сервера и шлюза сервер берет автоматически из системных настроек. Еще раз перезапускаем Dnsmasq:

Теперь можно выставить на клиенте автоматическое получение IP адреса и убедиться, что все работает нормально.

Просмотреть выданные адреса можно командой:

В выдаче будут перечислены выданные IP адреса и MAC адреса которым они выданы.

Настраиваем кеширующий прокси-сервер Squid

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

Останавливаем прокси-сервер и приступаем к настройке:

Открываем /etc/squid/squid.conf, находим и корректируем следующие строки, не забыв их раскомменитровать:

Указываем порт и адрес на котором squid будет принимать соединения:

Указываем внутренние сети, лишние комментируем:

Разрешаем доступ из внутренних сетей (найти и раскомменитровать):

Устанавливаем лимит использования памяти:

Задаем язык вывода ошибок для пользователя

Важное замечание! В Ubuntu 9.10 эта строка может выглядеть так, рекомендуем проверить правильность пути: error_directory /usr/share/squid/errors/ru

Сохраняем файл конфигурации. Теперь строим кэш и запускаем:

Для проверки указываем в браузере на клиентской машине использование прокси-сервера с адресом 10.0.0.1 и портом 3128, убеждаемся что все работает. Остается настроить прозрачную работу прокси-сервера, чтобы http трафик заворачивался на Squid автоматически, без прописывания прокси на клиенте. Для этого открываем /etc/nat и дописываем в конец строку:

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем роутер NAT + DHCP + Squid3 с поддержкой фильтрации SSL-трафика

Настраиваем роутер NAT + DHCP + Squid3 с поддержкой фильтрации SSL-трафика

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

Данный материал во многом повторяет нашу предыдущую инструкцию Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3, благо никаких принципиальных изменений в процессе настройки с тех пор не произошло. Поэтому мы не будем подробно останавливаться на повторяющихся настройках, а просто приведем необходимые участки конфигурационных файлов с минимальными пояснениями. В нашем случае использовался Debian 9, но данная статья будет справедлива для любого основанного на Debian / Ubuntu дистрибутиве.

Настройка сети

В данном примере у нас будет статическая настройка внешнего сетевого интерфейса, если же вы используете динамические подключение, такие как PPPoE или PPTP, то для их настройки обратитесь к соответствующим инструкциям (по ссылкам).

Для настройки сети откроем файл /etc/network/interfaces:

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

Если внешний интерфейс получает настройки по DHCP, то используйте следующие настройки:

Сразу создадим файл для хранения настроек брандмауэра и сделаем его исполняемым:

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

Настройка NAT и брандмауэра

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

Откроем созданный нами файл /etc/nat и внесем в него следующие строки:

Чтобы применить изменения просто запустим измененный файл:

Убедиться, что правила применились мы можем командами:

Если теперь вручную настроить сеть на рабочей станции, указав роутер в качестве шлюза с использованием DNS-сервера провайдера (или публичного), вы должны попасть в интернет.

Настройка DHCP и кеширующего DNS

В наших решениях эту роль обычно исполняет dnsmasq, не будем отступать от традиций и в этот раз. Установим данный пакет:

Для настройки откроем файл /etc/dnsmasq.conf и внесем некоторые изменения. Прежде всего ограничим адреса, которые будут слушать наши службы:

Затем зададим пул для выдачи адресов через DHCP и срок аренды:

Для одноранговой сети будет неплохо указать DNS-суффикс, чтобы избежать сложностей с разрешением плоских имен:

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

Просмотреть список выданных в аренду адресов можно командой:

Настройка прокси-сервера Squid3 с поддержкой SSL

К сожалению, в репозиториях нет пакета squid с поддержкой SSL, поэтому потребуется собрать его самому, как это сделать мы рассказывали в статье Сборка Squid 3.5 с поддержкой SSL из исходных кодов для Debian / Ubuntu, поэтому будем считать, что вы уже выполнили эту процедуру, либо используете уже собранные нами пакеты.

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

В процессе установки вы получите сообщения о неудовлетворенных зависимостях, поэтому разрешим их командой:

Чтобы наши пакеты не были перезаписаны пакетами из репозитория при обновлении их следует зафиксировать:

Если у вас был уже установлен squid, то просто удалите его и установите наши пакеты, все настройки при этом будут подхвачены автоматически, хотя на всякий случай сохраните куда-нибудь файл конфигурации:

Установив пакеты с поддержкой SSL, перейдем к конфигурированию нашего прокси. Для этого откроем файл /etc/squid/squid.conf, все указанные ниже опции надо либо найти и раскомментировать, приведя к указанному виду, либо создать.

Следующий блок, задающий стандартные ACL-элементы присутствует по умолчанию:

В нем мы должны изменить только опцию acl localnet src — указав диапазон собственной локальной сети.

Затем добавим несколько своих списков, прежде всего укажем диапазон адресов офисных ПК, которые мы раздаем по DHCP, это будут основные кандидаты на применение к ним правил фильтрации:

Затем идет элемент со списком значений «черного списка», который хранится в виде regex-выражений в файле /etc/squid/blacklist:

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

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

Но это заблокирует не только vk.com, но и все сайты с окончанием на vk.com, скажем mvk.com. Чтобы этого избежать, при этом надежно заблокировав домен с поддоменами, следует использовать конструкцию:

Для проверки созданных вами регулярных выражений мы рекомендуем использовать онлайн-сервис Regex101.

Следующий блок также является стандартным, просто контролируем его наличие:

После чего добавим свое правило для фильтрации HTTP-трафика:

Которое запретит для всех ПК офиса доступ к ресурсам перечисленным в черном списке. Далее следует стандартный набор списков доступа:

Это самый простой вариант, но тем не менее достаточный в качестве примера.

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

В параметрах HTTPS-порта задаются рекомендованные опции (ALL) и выключаются небезопасные устаревшие протоколы SSLv2 и SSLv3, также указывается сертификат squid, который мы создадим позже.

Ниже укажем ряд необходимых опций:

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

Зададим черный список для SSL:

Как было сказано выше, мы будем использовать раздельные списки, данный список будет хранится в файле /etc/squid/blacklist_ssl и также содержать регулярные выражения, описывающие блокируемые домены.

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

А теперь укажем, что делать с защищенным трафиком:

Действие peek «заглядывает» в соединение на указанную нами глубину, terminate блокирует соединения по совпадению условий (черный список + офисный диапазон адресов) и наконец splice разрешает все остальные соединения, не вмешиваясь в них.

Следующая опция также необходима для работы squid с SSL:

Также обязательно укажем DNS-сервер, который следует использовать squid, он должен обязательно совпадать с DNS-сервером, используемым клиентами, в нашем случае это dnsmasq, в доменной сети следует указать доменные DNS:

Ниже приведены параметры кеша:

И настройка логов:

В нашем случае используется 7 ротаций (неделя), поэтому установите нужное вам значение.

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

Либо можем скопировать уже существующий:

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

Затем создадим сертификат для squid:

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

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

Остановим прокси, перестроим кеш (так как мы изменили его параметры) и запустим заново:

Если вы используете прозрачный режим, то в конец файла /etc/nat добавьте следующие строки:

Для непрозрачного режима следует настроить WPAD, для автоматической настройки параметров прокси на клиентах (прописывать настройки руками в 21 веке дурной тон).

Проверим доступ к запрещенному ресурсу, как видим — все работает:

Ошибка «local IP does not match any domain IP»

Внешне данная ошибка проявляется в том, что squid в прозрачном режиме разрывает соединение с защищенным сайтом, регистрируя ошибку с указанным текстом в лог. Фактически такое поведение squid не является ошибкой, а связано со старой уязвимостью CVE-2009-0801, которая позволяла в прозрачном режиме обходить систему контроля доступа путем изменения HTTP-заголовков.

Коротко суть проблемы состоит в следующем: один и тот же ресурс на клиенте и на сервере разрешается в разные IP-адреса, этому в основном подвержены крупные ресурсы, имеющие несколько адресов для одного домена, а также сайты, использующие различные CDN (например, CloudFlare). Для squid такая ситуация равносильна попытке подмены заголовка, и он разрывает соединение.

Некоторые инструкции в сети советуют при сборке наложить патч client_side_request.patch, который по сути вернет уязвимость обратно. Заявления автора патча, что он не несет угрозы безопасности с отсылкой к одному из разработчиков squid не совсем верно отражают суть проблемы. Действительно, данная уязвимость никак не отражается на безопасности самого прокси-сервера, она позволяет клиентам, при определенных условиях, обойти его систему контроля доступа.

Как избежать данной ситуации? Использовать общий DNS-сервер как для клиента, так для прокси-сервера, мы обращали на это ваше внимание при описании соответствующей опции. Но не все так просто, ситуацию осложняет локальный DNS-кеш, который присутствует на любом клиенте и может содержать иную запись, нежели локальный кеш сервера. И добиться полной синхронизации кешей будет довольно сложно.

Однако данная проблема встречается не так часто, поэтому вполне будет достаточно очистить клиентский кеш и начать использовать общий DNS-сервер, но 100% гарантией избавления от проблемы это не будет.

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

Надеемся, что данная статья окажется вам полезна и поможет начать эффективно фильтровать защищенные соединения при помощи прокси-сервера squid.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник