Меню Рубрики

Установка pppoe server в centos

Настройка шлюза на CentOS 7

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

Данная статья является частью единого цикла статьей про сервер Debian.

Введение

В нашем распоряжении будет следующий сервер для настройки шлюза:

Использовался образ minimal для установки CentOS 7. Если вы еще не выполнили установку, рекомендую воспользоваться моим материалом на эту тему. На сервере две сетевые карты eth0 и eth1:

В данной статье мы выполним необходимые предварительные настройки на сервере, включим nat, настроим firewall и установим средство мониторинга сетевой активности.

Если у вас недостаточно опыта и вы не чувствуете в себе сил разобраться с настройкой шлюза самому с помощью консоли сервера — попробуйте дистрибутив на основе centos для организации шлюза и прокси сервера в локальной сети — clearos. С его помощью можно через браузер настроить весь необходимый функционал. В отдельной статье я подробно рассказал о настройке clearos.

Предварительная настройка сервера

Любую настройку сервера я рекомендую начинать с обновления:

После этого я устанавливаю mc, так как привык к нему и постоянно пользуюсь:

Дальше отключаем selinux. Находим файл /etc/sysconfig/selinux и редактируем его:

Приводим строку с соответствующим параметром к следующему виду:

Чтобы применить изменения, перезагружаем сервер:

Более подробно о базовой настройке сервера CentOS 7 читайте отдельно. Мы же двигаемся дальше.

Теперь настроим сеть. Я очень подробно рассмотрел вопрос настройки сети в CentOS 7 в своем отдельном материале. Рекомендую с ним ознакомиться. Здесь же я кратко выполню необходимые команды, без пояснений.

Сначала удаляем NetworkManager. Он нам не понадобится, выполним все настройки вручную. Иногда он может вызывать непонятные ошибки, я предпочитаю им не пользоваться:

Теперь включаем классическую службу сети в CentOS 7:

Настраиваем сетевые интерфейсы:

Перезапускаем службу сети:

Вы настраивайте сеть в зависимости от своих условий. Если внешний адаптер получает настройки не по dhcp, как у меня, а в статике, то не забудьте настроить шлюз по-умолчанию и dns сервер. Как это сделать написано в моей статье о сетевых параметрах, ссылку на которую я приводил выше.

Включаем маршрутизацию, firewall и nat

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

Чтобы заработала настройка, выполняем команду:

Теперь приступаем к самому главному — настройке фаерволла. Опять же отсылаю вас к своему материалу, где я очень подробно рассмотрел вопрос настройки iptables в CentOS 7. Там же приведен готовый скрипт для iptables. Так что выполняем все необходимые действия без пояснений.

Устанавливаем службы iptables:

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

Помещаем отредактированный скрипт в /etc/iptables.sh и делаем его исполняемым:

Добавляем их в автозагрузку:

Выполняем скрипт с правилами:

Проверяем установленные правила:

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

По сути наш шлюз уже готов и может обслуживать клиентов. Но не работает одна важна служба, без которой нормальной работы с интернетом не получится. Нам нужно настроить кэширущий dns сервер для клиентов локальной сети. Можно пойти по простому и очень простому пути. Простой путь это выполнить простейшую настройку dns сервера bind. Как это сделать у меня опять же подробно написано отдельно — настройка Bind 9 в CentOS 7. Рекомендую ознакомиться, там рассмотрены интересные нюансы настройки.

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

Установка и настройка dnsmasq в CentOS 7

С большой долей вероятности dnsmasq у вас уже установлен. Проверить это можно следующей командой:

Если вывод такой же, значит пакет уже стоит. Если нет, то устанавливаем dnsmasq командой:

Редактируем файл конфигурации /etc/dnsmasq.conf и приводим его к очень простому виду:

Либо перезапускаем, если он был у вас запущен:

Добавляем dnsmasq в автозагрузку:

Я редактировал конфиг, когда у меня уже был установлен и запущен dnsmasq. И он то ли завис, то ли просто затупил, но я не мог его перезагрузить или остановить с помощью systemctl. Пришлось перезагрузить сервер. После этого все нормально заработало. Клиент на windows получил сетевые настройки. Информация об этом появилась в логе /var/log/messages. Я проверил на клиенте интернет, все было в порядке, он работал.

На этом настройка завершена, шлюзом под CentOS 7 можно пользоваться.

Анализ сетевой активности на шлюзе в linux

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

Она отсутствует в стандартном репозитории CentOS 7. Для ее установки необходимо подключить репозиторий epel:

Устанавливаем iftop на CentOS 7:

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

Читайте также:  Установка круиз контроль для bmw x1

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

Теперь уже гораздо интереснее. Я еще добавил параметр -P, который отображает порты, по которым проходят соединения. Посмотрим, кто больше всех загружает канал интернета:

В моем случае это пользователь с ip 192.168.10.98, на котором я запустил проверку скорости интернета с серверов Яндекса.

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

Заключение

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

Давайте разберемся в том, что мы сделали:

  1. Выполнили предварительную настройку сервера, подготовили его к работе.
  2. Включили маршрутизацию.
  3. Настроили firewall.
  4. Включили NAT.
  5. Установили и настроили dnsmasq для организации служб dns и dhcp.
  6. Проанализировали сетевую активность шлюза, узнали кто загружает канал интернета.

Это минимально необходимый функционал для организации работы шлюза на CentOS 7. Следующим этапом может быть настройка прокси сервера, шейпера траффика, настройка 2-х и более провайдеров и много другое. Что-то из этого я рассмотрю в своих будущих статьях.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Онлайн курсы по Mikrotik

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

77 комментариев

Я не понял, а где процесс прописывания данных для установки связи с интернетом по PPPoE? В конкретно вашем примере карта eth0 смотрит в интернет. И что? Где логин? Где пароль для установки связи с интернетом? o_O

А при чем тут PPPoE? Это частный случай и весьма редкий. У меня лично за всю карьеру был только один шлюз с PPPoE, а настроил я их десятки.

Да какой редкий-то? Большинство провайдеров страны предоставляет интернет по PPPoE, поэтому для сетевой карты, смотрящей в интернет, необходимо устанавливать именно PPPoE-соединение. С вышеприведённая конфигурация интернет локальной сети НЕ раздаёт.

У меня другая статистика. Я чаще всего у юриков, а сейчас и физлиц, вижу ethernet. Все остальное экзотика.

То есть, никаких высокоскоростных соединений с помощью роутеров уже устанавливать не надо? Тупо UTP-кабель, и всё? Провайдер раздаёт интернет как в локальной сети что ли?

Я тут явно чего-то не понимаю. Ethernet — это Ethernet, на нём основаны именно _локальные_ сети в организациях. А интернет провайдеры предоставляют либо по PPPoE, либо, что реже, по L2TP. По крайней мере, у меня в городе именно так, я знаю всех провайдеров города.

Так что всё-таки предлагаю дополнить статью информацией об установке rp-pppoe в CentOS 7 и pppoe-setup для настройки высокоскоростного соединения.

Вам бы теорию подтянуть, чтоли.. PPPoE это по большому счету VPN-канал. Он нужен был для того, чтобы не напрягаясь можно было скорость ограничивать. Технологии давно ушли вперед, и теперь достаточно знать mac клиента, а еще лучше так организовать свою сеть, чтобы точно знать, на каком порту висит канал к клиенту. И все. А это в современном мире прям в два счета делается. И никакого PPPoE с его потерей ширины канала на шифрование трафика больше не нужно.
А то, что у вас в городе провайдеры используют старое оборудование и не хотят учиться использовать новое ПО — это сугубо их проблемы.

Вам бы тоже теорию подтянуть что ли. Вы из своей Москвы-то выйдите хотя бы километров на 200-400 и убедитесь, что окромя Москвы с её технологиями существует ещё и другая Россия, где тот же Ростелеком (и прочие провайдеры) предоставляют интернет именно по PPPoE, и никак иначе. Ваш пафос по поводу современного мира совершенно неуместен. Если данная статья выше расчитана исключительно на москвичей — ну, пожалуйста, буду учитывать это при прочтении других статей в будущем.

У меня родня в тамбове, я знаю, что происходит в 600км от столицы.
И я не видел НИ РАЗУ, чтобы клиенты на провод, приходящий от провайдера сажила СЕРВЕР с CentOS, чтобы на нем шлюз разворачивать. На провод вешается коммутатор, который легчайше поднимает PPPoE, и раздает пьюр инет в сервер-шлюз. А в идеале не пьюр инет даже, а уже слегка фильтрованный, на всякий случай.
Так что еще раз предлагаю подучить матчасть и пересмотреть архитектуру сети, изучить best practics и т.д.

Ну, тогда я тоже настойчиво предлагаю изучить матчасть и убедиться в том, что нормальные администраторы на периферии (за Москву не буду расписываться), наобщавшись с техподдержкой Ростелекома и наиспользовавшись их дебильных роутеров ZTE, создают свои собственные роутеры (они же шлюзы) из не сильно мощных компьютеров с основой на Linux. Так же сделал и я для своей организации. Зато теперь роутингом управляю именно я, а не непонятная китайская хрень, в которой даже правила нормально настроить невозможно. Да даже изначально не понимаю, в чём смысл городить городушки из нескольких устройств, если их количество можно сократить? Зачем мне отдельно роутер, отдельно шлюз и ещё что-либо отдельно, если используемая машина позволяет это прекрасно объединить?

Читайте также:  Установка подъемного механизма сенсо

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

И зачем нам убеждаться в том что нас не интересует уже давно как ? Да еще и деревенские унылые технологии ваши 🙂

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

Да, у всех простой ethernet. Провайдер проводит кабель в помещение и все. Настройки либо статика, либо по dhcp. Так сейчас почти везде, где я вижу интернет. В том числе в квартирах у физиков. А у юриков я всегда такое видел. Увидеть PPPoE или vpn для подключения к интернету это редкость. По крайней мере в Москве.

А так как я в основном сервера в ЦОДах настраиваю, там ничего, кроме ethernet и нету.

Написал «в цепочке INPUT» в 6-м вопросе. Подумал. Больше в FORWАRD наверное, раз шлюз.
И ще один вопрос тогда
Мы чистим таблицу mangle, хотя ее не используем в скрипте.
$IPT -F -t mangle
$IPT -t mangle -X
Зачем?

Спасибо за статью и подробное объяснениею. Есть несколько вопросов.
1. Зачем
$IPT -A OUTPUT -p all -m state —state ESTABLISHED,RELATED -j ACCEPT ?
если есть
$IPT -A OUTPUT -o $WAN -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -o $LAN1 -j ACCEPT
Если бы не было 3-х последних (в скрипте они идут первыми), то сервер не смог бы установить исходящее соединение — наверное, DNS бы не резолвился, например
Тогда, $IPT -A OUTPUT -p all -m state —state ESTABLISHED,RELATED -j ACCEPT просто лишнее (или копипаст :)), тем более это правило добавится последним (ключ -A). Правильно?
2. $IPT -A OUTPUT -p tcp ! —syn -m state —state NEW -j DROP. Сдесь мы защищаем Интернет от атак со своего хоста? . Тем более мы уже открыли все интефейсы на OUTPUT на еще раньше в скрипте. Мне не понятно 🙁
3. Если у нас есть статический IP (85.31.203.127 в скрипте) на интерфейсе, который смотрит «в мир», почему мы не можем использовать —to-source SNAT вместо MASQUERADE?
4. Если мы НАТим (Маскарадим) только определенные локальные IP LAN1_IP_RANGE=10.1.3.0/24 в -A POSTROUTING -o $WAN -s $LAN1_IP_RANGE, почему бы не огрничтить эти адреса и в $IPT -A FORWARD -i $LAN1 -o $WAN -j ACCEPT — чтобы не выпускать наружу локальные (серые) адреса вне диапазона 10.1.3.0/24?
5. Наличие 3-х нижних правил вместе в одном скрипте мне тоже не понятно если есть всего 2 интерфеса (как и в.1.)
$IPT -A FORWARD -p all -m state —state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -i $LAN1 -o $WAN -j ACCEPT
$IPT -A FORWARD -i $WAN -o $LAN1 -j REJECT
6. Может правила с —state ESTABLISHED,RELATED поднять повыше в скрипте — в шлюзе через них, скорее всего, основной трафик будет идти, пусть лучше первыми срабатывают в цепочке INPUT?
7. Вместо -m state —state ESTABLISHED,RELATED лчуше бы использовать в учебных целях (ИМХО, конечно) -m conntrack —ctstate ESTABLISHED,RELATED, т.к. первые считаются устаревшими хотя и потдерживаются
Спасибо.

На первый взгляд замечания по существу. Не готов сейчас подробно разбирать правила, немного отошел уже от этой темы. По первому пункту однозначно это правило должно быть в самом начале. Возможно, когда писал статью, раскомментировал то, что у меня самого стоит в блокировке. Я сделал более либеральные правила. Из-за этого нарушилась логика работы, но не функционал. По-умолчанию я блокирую все, что не разрешено, используя этот универсальный конфиг. Отсюда же чистится цепочка mangle, которая реально не используется в данном случае. В пятом пункте то же самое. Открыв всю локалку наружу, я просто упростил правила, и предыдущее с ESTABLISHED,RELATED стало бесполезным.

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

Вообще итоговая цель — шлюз с https прокси на squid, может что нибудь посоветуете (статьи, другой дистрибутив)?

Здравствуйте. Подскажите в чём проблема. Включаю iptables и клиент перестаёт получать настройки автоматом, выключаю всё работает?

Неверно правила для iptables составили. Скорее всего блокируете на сервере все входящие соединения.

На всякий случай уточню. Вы какие настройки клиента имеете ввиду? Сетевые?

Да, конечно, iptables ваши (естественно с моими названиями сетевых и IP). Единственное, я использовал только эту статью. У меня всё на виртуалке одна сетевая в инет по DHCP вторая в локалку. И инет тоже не даёт клиенту даже при выключенном iptables, sysctl сделано.

DHCP-запрос — широковещательный, его не рекомендуется разрешать для шлюзования. Вам надо поднять DHCP-сервер и DNS-сервер (активный, а не просто маскарад) во внутренней сети (можно на том же шлюзе). И разрешить в iptables широковещательные запросы на внутреннюю сетевую. Я бы советовал вообще поднять домен во внутренней сети (сам так и сделал), но тут тонкий момент, что в настройках сетевых карт должен быть указан сначала DNS-сервер шлюза, а вторым — внутренний, если он есть, иначе винда не хочет в интернет ходить.
А proxy и squid это совершенно другая пьянка.

Читайте также:  Установки мест трубопроводной арматуры

Дело в том, что есть физический сервер на котором нужно настроить роутер + proxy, для фильтрации инета и ограничения скорости по группам. Чтобы не мучить железо, решил создать лабораторную среду на virtualbox, может я сеть не так настроил на виртуальных машинах (внешняя сетивуха мостом, а внутренняя «Внутренняя сеть»)? В итоге не получается поднять шлюз, тоесть виртуальный клиент виртуального сервера получает настройки от dnsmasq но в интернет не выходит….

Походу точно накосячил с iptables, подскажите что нужно раскоментировать или дописать в скрипте из статьи, чтобы входящий трафик шел во внутреннюю сеть. Внешняя — enp0s3, IP — 192.168.1.142/24. Внутренняя — enp0s8, IP — 10.0.0.1/22

В статье как раз этой случай и описан. Могу только предложить еще раз ее внимательно прочитать.

Извиняюсь за настойчивость и тупость, всё из за спешки (прокуратура не дремлет), а тут спешить нельзя… Всё заработало.
Огромное спасибо за Ваши статьи и помощь страждущим.

Бьюсь 5й день. Поднял виртуалки на гипервизоре. Не могу заставить ВМ из внутренней сети ходить в инет через шлюз на центосе7. С ВМ внутри сети ходят пинги на внутренний и внешний интерфейсы центоси, но дальше — ни шагу. Сам центось пингует ya.ru нормально.
Делал все по мануалу вплоть до маскарада дхцп, но как я понимаю в тестовой среде это не важно, надо просто заставить ходить в инет пакеты. А они не ходят..
Схема подключения такая: пк виндовый с «частным виртуальным коммутатором», центос с «частным» + «по умолчанию» (на 2м включен NAT, и он связывает ВМ с хостом и далее дает доступ в инет, хост подключен к роутеру, в тот приходит оптика.
В чем может быть косяк? Куда копать?

По описанию похоже, что не сделано вот это, либо сделано неправильно.

Находим файл /etc/sysctl.conf и вставляем туда строку:
# mcedit /etc/sysctl.conf
net.ipv4.ip_forward = 1
Чтобы заработала настройка, выполняем команду:
# sysctl -p

Перед и после знака равенства — пробелы! А я их не написал по аналогии со всеми остальными .конф файлами..
Спасибо!

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

Если хоть один комп выходит в интернет, значит шлюз работает нормально. Возможно где-то в настройках просто опечатка. Так часто бывает.

Мы предотвратили попытку войти в аккаунт из небезопасного приложения.
Небезопасное приложение
воскресенье, 24 июня 2018 г., 20:41 (Румыния)
Romania*

Автор (Мамкин хакер) походу еще и обидчивый

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

Статьи видимо откуда-то перекопированы, потому как полный бред. Не советую ни кому повторять примеры из таких статей.

Ну конечно. А 46 тысяч человек, которые перед тобой прочитали статью и не поделились такой важной информацией, дураки. Один ты умный. Что за манера у людей, свое неумение и неспособность понять прочитанное перекладывать на автора, который как минимум, на практике проверил все то, о чем написал.

Здравствуйте, вот такой вопрос, всю настройку проводил только по вашим статьям, есть
шлюз gw1(CentOS7), eth0 — 10.10.0.4 (статический адрес) и eth1 — 10.10.1.8 (/24)
за ним есть машина gwtest(CentOS7) — eth0 — 10.10.0.5 (внешний адрес) и eth1 — 10.10.1.9 (/24)
и есть необходимость чтобы подключиться по ssh (по порту 2345) к этой второй машине через шлюз gw1, машина gwtest не настроена iptables и firewalld я отключил, чтобы не мешали.
gw1(основные моменты, остальное все как у Вас):
# Внешний интерфейс
export WAN=eth0
export WAN_IP=10.10.0.4

# Локальная сеть
export LAN1=eth1
export LAN1_IP_RANGE=10.10.1.0/24

# Разрешаем исходящие подключения сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT
#$IPT -A INPUT -i $WAN -j ACCEPT

# Пробрасываем порт в локалку
$IPT -t nat -A PREROUTING -p tcp —dport 2345 -i $ -j DNAT —to 10.10.1.9:2345
$IPT -A FORWARD -i $WAN -d 10.10.1.9 -p tcp -m tcp —dport 2345 -j ACCEPT

# Разрешаем доступ из локалки наружу
$IPT -A FORWARD -i $LAN1 -o $WAN -j ACCEPT
# Закрываем доступ снаружи в локалку
#$IPT -A FORWARD -i $WAN -o $LAN1 -j REJECT
# Включаем NAT
$IPT -t nat -A POSTROUTING -o $WAN -s $LAN1_IP_RANGE -j MASQUERADE

если подключаюсь из gw1 к gwtest — ssh -p 2345 admroot@10.10.1.9 — все ОК
если подключаюсь на внешний интерфейс gwtest по порту 2345 — все ОК
если на внешний интерфейс gw по порту 2345 — нехочет
При этом с помощью iftop на gw:
ru134.telecom.com:64621 => 10.10.1.9:56371 0b 69b 69b

Zerox, можете чуть подробней описать как работает проброс порта?

источник

Добавить комментарий

Adblock
detector