как установить линукс на роутер
Опыт создания домашнего Wi-Fi маршрутизатора. Часть 2. Установка и настройка ПО
И снова здравствуйте!
В первой части статьи я рассказывал о «железной» составляющей будущего роутера. Поскольку без софта даже самое расчудесное железо, естественно, работать не будет, следовательно требовалось снабдить аппарат соответствующей программной «начинкой».
Когда я затевал всё это движение, я предполагал, что будет непросто. Но не предполагал, что настолько. В одном из комментариев к предыдущей части статьи я клятвенно пообещал рассказать о нижеследующем «к выходным». Благоразумно умолчал к каким именно. 🙂 Тут ещё умудрился прихворнуть не вовремя, но всё-таки сдерживаю своё обещание.
Ещё раз уточню, что эти ваши интернеты приходят ко мне по 100 Мбитному каналу (тариф, естественно, даёт несколько меньшую скорость, но не суть). Получилось, собственно, вот что:
1. FreeBSD 10.1-RELEASE
Всё было замечательно, система встала, но меня ждал неприятный сюрприз, о котором я, откровенно говоря, знал, но решил-таки проверить на практике: FreeBSD напроч отказывалась видеть Wi-Fi карточку. Вернее видеть-то она её видела, но только адрес и название вендора, а что это и с чем её едят, фряха понимать не желала (драйвер устройства значился как none1). Кроме того, дальнейшее чтение мануала выявило, что в режиме точки доступа во FreeBSD работают только Wi-Fi карты на основе набора микросхем Prism. Печальбеда. Да, нашёл я также и информацию, что моя карточка в настоящий момент вообще не имеет драйвера под фряху. Даже портированного.
10. Debian 7.7.0
Расстраивался я недолго: не состоялась фряха — возьму старый добрый Debian. Установил с netinstall-образа базовую систему без графического окружения. Долго пытался понять, что не так. Стабильный релиз Debian в данный момент 7.7.0, имеет ядро версии 3.2. В этом ядре опять же нет поддержки моей многострадальной Wi-Fi сетевушки. Полез на ЛОР искать ответ, в итоге получил неутешительные выводы: надо ставить ядро посвежее (в случае Debian — тот ещё геморрой), пляски с бубном ядрами, по мнению гуру, не труъ Debian-way (так прямо и сказали: хочешь перекомпилять ядра — выбери другой дистрибутив).
11. Ubuntu Server 14.04 LTS
Плюнув на попытки круто провести время покрасноглазить, я взял знакомый и уважаемый мной дистрибутив. Уже более года он (правда версии 12.04 LTS ) вертится у меня на сервере, раздающем плюшки в сети провайдера.
Из плюсов: стабильность, простота установки, настройки и администрирования, куча документации.
Из минусов: необходимость дорабатывать напильником, поскольку «искаропки» получается толстоват и несколько неповоротлив.
Установка
По сути не представляет ничего сложного и аналогична таковой в Debian. Производится в диалоговом режиме text-mode. Описывать детально не вижу смысла, т.к. всё это уже десятки раз пережёвано и валяется на множестве ресурсов (начиная с официальных сайтов на разных языках и заканчивая местечковыми форумами).
Перед началом любых манипуляций с накопителем рекомендуется обновить прошивку, но на моём оказалась самая свежая, поэтому данный шаг я пропустил.
При разметке я создал 3 раздела:
Как видно, все разделы начинаются с секторов, кратных 8. Таким образом доступ будет осуществляться с обращением по правильному сектору, что поможет сберечь нежный ресурс накопителя.
Далее в опциях монтирования разделов в /etc/fstab следует добавить discard — для включения TRIM и noatime — для отключения записи в метаданные времени последнего доступа к файлу.
Все остальные советы, нагугленные на просторах сети, как то увеличение времени между сбросами буферов на диск (опция commit=[time, sec.]), отключение «шлагбаума» (опция barrier=0) и прочее не внушили мне доверия в плане приобретаемой полезности в ущерб сохранности данных и безопасности.
Кроме того, я не стал выделять отдельный раздел для swap, решив, что оперативной памяти мне должно хватить для поставленных задач. Если же всё-таки возникнет необходимость в подкачке, ничто не мешает сделать swap в виде файла и смонтировать его как раздел.
Также было принято волевое решение вынести временные файлы (/tmp) в tmpfs.
В процессе установки задаются общие параметры, как то: локаль, параметры времени/геопозиции, имя системы, а также создаётся новый юзер и пароль к нему. Далее следует выбор устанавливаемого программного обеспечения, в котором я пометил для установки следующее:
add to /etc/modprobe.d/blacklist.conf:
blacklist gma500_gfx
Пруф.
В случае с Debian — /etc/modprobe.d/fbdev-blacklist.conf.
После перезагрузки всё заработало.
Настройка сети
Проблема связана с библиотекой авторизации libpam-smbpass, можно просто её снести, а можно поступить более изящно:
снять пометку с SMB password synchronization, что отключает синхронизацию паролей системных пользователей и пользователей Samba.
Устанавливаем все доступные обновления:
И приступаем к настройке сетевых интерфейсов. В маршрутизаторе 4 физических интерфейса и loopback:
К моему величайшему сожалению такой способ не сработал, и команда вывалилась с ошибкой, поэтому я прибегнул к альтернативному способу:
Теперь необходимо сконфигурировать все сетевые интерфейсы, чтобы было удобнее с ними работать. Я решил объединить встроенные сетевушки и Wi-Fi в мост, чтобы управлять этим хозяйством как единым целым при раздаче IP-адресов по DHCP, маршрутизации и пр. Приводим к следующему виду /etc/network/interfaces:
Включаем автоматический запуск hostapd при загрузке системы, для этого в /etc/default/hostapd раскомментируем и редактируем строки:
Далее, не мудрствуя лукаво, я настроил общий доступ. Скрипт для настройки iptables и ip-форвардинга я взял отсюда, привёл его в соответствие своим реалиям и настроил автозапуск. В результате iptables наполняются необходимым содержимым при загрузке системы.
Логично, что нужно текже настроить DHCP-сервер. Решив упростить задачу до минимума, я установил dnsmasq и снёс имеющийся в наличии и конфликтующий с ним bind9. Конфиг прост:
На самом деле в конфиге ещё куча закомментированных опций, которые позволяют производить очень fine tuning, но такого набора вполне хватает для корректной работы. В принципе, с этого момента аппарат уже работает как домашний маршрутизатор.
После окончания основной настройки я установил и настроил transmission-daemon, aMuled и vsftpd. Собственно говоря, настройка данных сервисов достаточно тривиальна, останавливаться детально на ней не буду. Естественно, доступ к данным ресурсам имеется только из локальной сети, если хочется получить доступ извне, необходимо будет открыть соответствующие порты в iptables.
Вёб-сервер представляет из себя связку Apache 2.4.7 + MySQL Ver 14.14 Distrib 5.5.40. Пока не придумал, чем буду его заполнять: накатить готовый движок и баловаться с дизайном или же просто попрактиковаться в html и php. В любом случае сие имеет для меня прикладное значение. Возможно, в перспективе получится настроить вёб-интерфейс для мониторинга и управления маршрутизатором.
После всех манипуляций остаётся настроить ведение логов: по возможности привести настройки всех процессов, ведущих логи, выводить в них только критически важные уведомления и предупреждения. Идея заключается в снижении количества операций записи, а, соответственно, и негативного влияния на SSD.
Кроме того, следует настоятельно рекомендуется включить запуск по cron раз в сутки fstrim (для каждого раздела отдельно). Говорят, хуже не будет точно.
Ффух… Получилось несколько сумбурное описание моих мытарств с собственноручно собранным устройством, но удовлетворение от того, что всё работает просто неописуемо.
Вроде бы ничего не забыл, упомянул все ключевые моменты. За подробностями прошу в комментарии. Спасибо за внимание! (-;
UPD: Господин Revertis справедливо заметил, и я с ним соглашусь, что изначально при установке системы не следовало отмечать DNS-сервер, чтобы потом его сносить (речь о bind9), но в статье я описывал именно путь, который проделал — со всеми его ошибками и закоулками. И да, соглашусь, что nginx лучше, чем Apache, более того — я его даже заменю. Спасибо за совет.
Наш рецепт отказоустойчивого Linux-роутера
В высоконагруженных проектах всегда повышенные требования к избыточности и надежности. Одним из важнейших звеньев инфраструктуры является маршрутизатор, потому что от его устойчивости зависит доступность сети в целом. Именно на таких узлах мы используем одну из схем реализации отказоустойчивого виртуального роутера на базе GNU/Linux с использованием iproute2, NetGWM, keepalived, ISC DHCPD, PowerDNS. Как мы всё это настраиваем, читайте в этой статье.
Компоненты
В идеальной схеме отказоустойчивого роутера мы резервируем все элементы, которые могут привести к недоступности сети, то есть:
Как видно из схемы, нам нужны 2 коммутатора с поддержкой 802.1Q VLAN. Оператор 1 коммутируется в Коммутатор 1 и ему выделяется отдельный VLAN (например, 110). Оператор 2 коммутируется в Коммутатор 2, в другой VLAN (например, 120). Отдельный VLAN (в нашем случае — 200), выделяется под локальную сеть. Между коммутаторами организуется транк, и транком же линкуем оба маршрутизатора, которые и будут «сердцем» нашего виртуального роутера (схема router-on-a-stick).
Такая компоновка позволяет оставлять работоспособной сеть при выходе из строя любого компонента: роутера, коммутатора или оператора.
Стек базовых компонентов, которые мы используем в работе роутеров:
Настройка интерфейсов
Настраиваем VLAN. Конфигурация /etc/network/interfaces будет выглядеть примерно так:
И настроим правила маршрутизации для промаркированных пакетов — мы это делаем вызовом скрипта iprules.sh при выполнении ifup lo (смотри выше в /etc/network/interfaces ). Внутри скрипта:
Эти таблицы маршрутизации необходимо объявить в /etc/iproute2/rt_tables :
Балансировщик основного шлюза
Настроим NetGWM — утилиту для приоритезации основного шлюза. Она будет устанавливать маршрут по умолчанию, выбирая операторов в соответствии с двумя правилами: а) установленным нами приоритетом, б) статусом оператора (жив или нет).
Чтобы установить NetGWM, можно воспользоваться исходниками на GitHub или нашим репозиторием для Ubuntu. Второй способ в случае Ubuntu 14.04 LTS выглядит так:
Настройка keepalived
Keepalived — реализация протокола VRRP для Linux. Этот протокол позволяет реализовать схему с отказоустойчивой маршрутизацией, создавая виртуальный IP, который будет использоваться в качестве маршрута по умолчанию для обслуживаемой сети. Виртуальный IP автоматически передается резервному серверу при выходе из строя основного сервера.
На этом этапе мы определяемся, что Маршрутизатор 2 будет играть роль Backup, а Маршрутизатор 1 — роль Master. Настраиваем keepalived, изменяя конфигурационный файл /etc/keepalived/keepalived.conf :
Настройка ISC DHCPD
ISC DHCPD был выбран нами, так как позволяет масштабировать DHCP на несколько серверов. Он прост в конфигурировании и хорошо зарекомендовал себя на практике. Кроме того, нам понравилось, что разработчики этого DHCP-сервера придумали изящное решение для организации реплики между серверами. Для основного и второстепенного серверов выделяются разные пулы адресов и на запросы отвечает сервер, который успел сделать это первым, выдавая адрес из своего пула. При этом база арендованных IP синхронизируется. В случае, если один из серверов отказывает, второй как ни в чем не бывало продолжает выдачу адресов из своего пула. При возврате отказавшего сервера он начинает выдачу из своего пула, при этом не возникает коллизий.
Правим конфиг /etc/dhcp/dhcpd.conf :
Скопируйте сгенерированный ключ и вставьте в конфигурационный файл вместо слова КЛЮЧ.
Настройка PowerDNS
В качестве DNS-сервера мы предпочли PowerDNS, так как он имеет возможность хранить зоны в СУБД MySQL, которую удобно реплицировать между первым и вторым сервером. Кроме того, PoweDNS — это производительное решение, хорошо функционирующее в высоконагруженном роутере.
Настройку PowerDNS начнем с подготовки базы данных.
Теперь нужно настроить PowerDNS и научить его работать с БД. Для этого требуется установить пакет pdns-backend-mysql и изменить конфиг /etc/powerdns/pdns.conf :
На этом базовая конфигурация PowerDNS закончена. Нам же ещё потребуется настроить рекурсор — обработчик рекурсивных DNS-запросов, который позволяет значительно повысить производительность DNS-сервера. Правим файл /etc/powerdns/recursor.conf :
В файл forward_zones вносим зоны intranet, которые обслуживают соседние серверы:
После запуска настраиваем реплику MySQL между серверами.
Заключение
Мы используем данное решение не только в чистом виде. В большинстве случаев оно усложняется добавлением туннелей VTun, OpenVPN или IPSec через основного и резервного оператора связи и динамической маршрутизацией, которая реализуется с помощью Quagga. Поэтому схему, предложенную в статье, предлагаю воспринимать как фундамент для создания более сложных решений.
Будем рады, если вы зададите свои вопросы в комментариях или укажете на места в схеме, которые можно улучшить. И, конечно, подписывайтесь на наш хаб, чтобы не пропускать новые полезные материалы! )
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
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 конфигурационный файл с сетевыми интерфейсами, аналогичный рисунку ниже.
Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем:
В этом файле необходимо указать адреса DNS серверов, лучше всего указать DNS провайдера или, как в нашем случае, OpenDNS.
Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):
Собственно сеть настроена, можно переходить к следующему этапу, однако мы рекомендуем установить еще несколько пакетов для удобства администрирования. Сначала обновим список доступных пакетов:
Также рекомендуем обновить версии пакетов до актуальных:
Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:
Для удаленного управления сервером (не бегать же к нему каждый раз) установим OpenSSH, что позволит подключаться к нему из любого места, даже из дома, по защищенному протоколу:
Для ограничения доступа к серверу можно дописать в файл /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
Останавливаем прокси-сервер и приступаем к настройке:
Открываем /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 запросы, а также умеющий раздавать клиентским машинам необходимые для работы в сети настройки.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов
Главное меню » Linux » Настройка Linux-шлюза/маршрутизатора, руководство для не сетевых администраторов
Мы напишем о том, как вы можете настроить обычный дистрибутив Linux в качестве пограничного маршрутизатора/шлюза для вашей локальной сети, но для простоты использования будем основывать свои примеры на Ubuntu.
Мы можем купить маршрутизатор или заменить устройство на что-то, что может обеспечить такую же функциональность. В этом случае мы выбрали сервер Linux, поэтому нам нужно выяснить, какие сервисы предоставляет маршрутизатор, а затем каким-то образом эмулировать их:
К счастью, Linux поддерживает все это:
Мы будем настраивать каждую из этих служб в следующих постах, а пока:
Предварительная работа, настройка оборудования
Перед настройкой каких-либо служб вам понадобятся две вещи: две сетевые карты, одна для исходящего соединения, а другая для (коммутируемой) локальной сети, и способ сообщить серверу, что вы хотите, чтобы весь трафик из сети 1 был перенаправлен в сеть 2. Возможно, вы захотите установить более двух карт на случай, если вам потребуется маршрутизировать несколько локальных сетей. Мы увидим это позже.
Вам также понадобится ОС. Мы выбрали Ubuntu, потому что она очень проста в установке и содержит все необходимое программное обеспечение в репозиториях, но вы можете использовать любой другой дистрибутив, если вам это нужно.
Кроме того, в этой статье мы будем использовать такую настройку:
Если у вас нет всего этого оборудования …
Не у всех может быть два запасных рабочих стола с тремя сетевыми картами, готовыми к тестированию. Даже если вы это сделаете, вам может быть лень настраивать физическую часть вашей сети. Если это ваш случай, вы также можете настроить виртуальную машину для эмуляции вашей настройки, и Virtualbox отлично подходит для этой задачи:
Теперь все готово, с помощью этой виртуальной настройки вы можете начать настройку маршрутизатора.
Настройка Linux GW: NATting и пересылка
Для нашего Linux GW такие сервисы, как DNS и DHCP, хороши, но реальное подключение намного важнее. Давайте настроим функции NAT и переадресации соединений нового маршрутизатора, затем мы можем проверить, правильно ли работает наша установка, пропингуя IP одной локальной сети из другой.
Мы сделаем это, настроив NAT с помощью iptables. Нам также нужно будет настроить ОС для переадресации соединений с одной сетевой карты на другую:
Нам также нужно будет настроить IP для eth0, так как не будет DHCP-сервера (мы являемся сервером!). Откройте/etc/network/interfaces и добавьте что-то вроде этого:
После того, как все проверено, перезапустите сетевые сервисы, как ниже:
Все готово, теперь просто подключите ваш компьютер к новому маршрутизатору и протестируйте его. Не забудьте вручную установить IP-адрес в том же диапазоне сети, что и у маршрутизатора, поскольку в данный момент DHCP отсутствует. Это может быть полезно для устранения проблемы.
На своем клиентском ПК установите свой IP-адрес:
Проверьте, установлен ли у вас IP:
Если вы получили ответ, ваш новый IP-адрес в порядке, если нет, то проблема с вашим клиентом. Второй шаг, посмотрите, можете ли вы добраться до маршрутизатора:
Обратите внимание, что вам может потребоваться обновить все (т.е. перезапустить сеть и вручную назначить свой IP-адрес) после подключения кабеля.
Опять же, если вы получите ответ, у вас есть связь с маршрутизатором. До сих пор мы не тестировали ни правила iptables, ни переадресацию, поэтому любая проблема на этом этапе должна иметь конфигурацию IP. Если все прошло хорошо, пришло время проверить правила NAT и переадресацию.
Это должно дать вам ошибку. Конечно, поскольку нет DHCP, маршрут не установлен. Давайте вручную установим маршрут в клиенте:
Магия! Работает! Если это не так, у вас есть проблема либо в конфигурации NAT, либо в IP-пересылке маршрутизатора. Вы можете проверить это с помощью wireshark: если эхо-запросы достигают сервера, но они никогда не получают ответ, тогда это NAT, то есть он может пересылать IP-пакеты на eth1 на eth0, но у маршрутизатора нет NAT, и он не знает, как направить ответ обратно. Если эхо-запросы никогда не достигают eth0, тогда у вас проблема с пересылкой IP.
Сохранение правил пересылки
Чтобы правила пересылки сохранялись после перезагрузки, нам нужно сначала изменить /etc/sysctl.conf, чтобы разрешить пересылку IP. Это просто вопрос раскомментирования этой строки:
У нас также будет много правил iptables, которые нам нужно настроить во время загрузки. Мы создали скрипт в /home/router/set_forwarding.sh, который также связали с /etc/init.d/rc.local, поэтому он запускается всякий раз, когда загружается система.
В следующий раз мы перейдем к чему-то более сложному: установке DNS-сервера и использованию доменов вместо IP-адресов.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.