Как проверить работу nat ubuntu
Обновлено: 02.07.2024
Всё очень просто, в очередной раз объясняя на форуме новичкам в мире Linux, что да как я понял, что на просторах интернет не найти собранную воедино статью с объяснением не только настройки iptables, но и некоторых сетевых основ.
Как это выглядит
И так что же мы имеем:
сервер с 2мя сетевыми картами и установленным на нём Debian Lenny
имеющийся по умолчанию в Debian Lenny firewall — netfilter/iptables
локальную сеть из N компьютеров, все соединены через коммутатор, в том числе и сервер
Для начала нам нужно понять, что настраивать мы будем самый обыкновенный NAT(Network Address Translation). Для жаждущих, я в конце упомяну и о проксе сервере на примере squid. Как я уже сказал разжёвывать будем практически всё.
Что же такое NAT? На самом деле все просто, все компьютеры имеют физический (MAC) и сетевой (IP) адреса. Нас в данный момент интересуют IP адреса. IP адрес в пределах одной сети должен быть уникальным! А при нынешнем стандарте IPv4 уникальными могут быть всего-то 4 294 967 296 (232), что совсем не много и они практически кончились. но не переживайте вот вот вступит в широкое распространение IPv6, а там адресов навалом!
Но тут вы можете заметить, компьютеров значительно больше того числа, что позволяет IPv4 или скажете, что у друга дома такой же адрес как и у вас! И вот тут-то и заходит речь о NAT — он позволяет соединять компьютерные сети между собой используя единственный, свой IP адрес, действия фаервола при этом называется SNAT(Source NAT или подмена адреса источника). Т.е. в 99% случаев вся ваша контора выходит в интернет под 1 IP адресом, при этом внутри офиса у каждого он свой. О классах IP адресов вы сможете прочесть в интерне.
Теперь, когда мы знаем что такое NAT и для чего он нужен, можно приступать непосредственно к настройке сервера.
транзитный трафик
На клиентах указываем ip из выбранного диапазона и указываем в качестве шлюза ip адрес нашего сервера(обычно его назначают первым из подсети — я оставлю это на ваше усмотрение). Все сетевые настройки на сервере можно провести так:
$ nano /etc/network/interfaces в нём указываются настройки ваших сетевых интерфейсов.
доступ в недры сети через шлюз или DNAT
И хотя сейчас все работает, у всех есть интернет и все работает, некоторым всё же нужен прокси сервер. Я не буду рассказывать о настройке squid, я покажу правило которое позволит сделать его «прозрачным». В сквид надо лишь прописать волшебное слово transparent в нужном месте и он начнём корректно обрабатывать свалившееся на него запросы.
Пишем
Статья не резиновая и обо всем все-равно не расскажешь… Я привел минимальный набор действий и понятий что бы вы могли начать осваивать такую махину как шлюз на Linux. Здесь можно говорить очень и очень долго, обсуждая многие аспекты и возможности netfilter.
Итого
Как мы видим все действительно просто! Главное это понять принцип функционирования сети и не боятся настраивать и читать большие мануалы.
Надеюсь мне удалось собрать воедино информацию достаточную для начала вашей дружбы с программными маршрутизаторами на основе Linux.
Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3
Более четырех лет назад мы опубликовали материал посвященный настройке роутера на базе Ubuntu Server. Тема оказалась весьма востребованной и популярной, но за прошедшее время некоторые настройки успели измениться, пусть и незначительно. В связи с этим мы решили вернуться к этой теме и опубликовать современную версию популярной статьи.
Мы не будем подробно останавливаться на установке системы и назначении тех или иных компонентов, об этом достаточно сказано в исходном материале, а уделим основное внимание отличиям в современных версиях Ubuntu Server и настраиваемых пакетах.
Настройка сети
В нашем примере внешний сетевой интерфейс - eth0 - имеет статические настройки, если же вы используете PPPoE или PPTP подключение, то для настройки подключения рекомендуем воспользоваться нашими материалами:
Начиная с версии 12.04 (мы рассматриваем только LTS версии и крайне не рекомендуем использовать на серверах промежуточные релизы) все сетевые настройки, в том числе и DNS-сервера указываются в одном месте, конфигурационном файле /etc/network/interfaces. Перед тем как приступать к настройке повысим права до суперпользователя:
затем откроем файл в штатном редакторе nano, работа с ним далека от удобства, но для изменения нескольких строк он вполне подойдет:
Приведем его к следующему виду (настройки внешнего интерфейса приведены исключительно для примера):
Для указания DNS-серверов теперь используется директива dns-nameservers, если серверов несколько, они указываются в одну строку, через пробел.
Если вы получаете сетевые настройки от провайдера по DHCP, то настройки будут иметь вид:
Последней строкой идет автоматическая загрузка правил iptables из файла /etc/nat, который мы создадим позже.
Если все сделано правильно, на сервере должен появиться интернет. После чего следует обновить пакеты на сервере и установить необходимый минимум утилит для администрирования:
Представлять двухпанельный менеджер с удобным редактором Midnight Commander (mc) мы думаем не нужно, как и SSH-сервер, дающий возможность удаленного администрирования.
Настройка NAT и брандмауэра
Технология сетевой трансляции адресов - NAT - позволяет организовать выход в интернет компьютеров локальной сети через один сетевой адрес. Данная технология абсолютно прозрачна для клиентских устройств и способна работать с любыми сетевыми приложениями и протоколами. За функции NAT в Ubuntu отвечает сетевой фильтр iptables, который предоставляет также функции брандмауэра.
В зависимости от политики сетевой безопасности существуют различные подходы к настройке брандмауэра. Мы предпочитаем задавать только базовые правила, исходя внутри сети из принципа: все что не запрещено - разрешено. Это позволяет свободно работать любым сетевым службам во внутренней сети и без помех выходить в интернет, обеспечивая при этом достаточный уровень безопасности. Для внешней сети запрещено все, что не разрешено и доступ к сетевым службам администратор должен разрешать явно.
Создадим файл настроек:
и внесем в него следующее содержимое:
Сохраним изменения и дадим нашему файлу права на исполнение:
Теперь если вручную задать сетевые настройки для рабочей станции, указав в качестве шлюза наш роутер и любой доступный DNS-сервер, то не ней должен появиться доступ в интернет.
Настройка DHCP и кэширующего DNS
В принципе мы уже можем использовать наш роутер по назначению, однако ручное указание сетевых настроек, это даже не вчерашний, а позавчерашний день, поэтому DHCP-сервер является неотъемлемой частью сетей любого размера. Также имеет смысл настроить собственный кэширующий DNS-сервер, который не только снизит нагрузку на вышестоящие сервера и уменьшит время отклика, но также позволит создавать собственные записи для хостов внутренней сети, что может оказаться полезным при развертывании иных сетевых сервисов.
Все эти функции реализованы в одном пакете dnsmasq, который предельно прост в установке и настройке:
Функции кэширующего DNS-сервера становятся доступны сразу после установки и в настройке не нуждаются, однако следует явно указать интерфейсы, которые будет обслуживать dnsmasq. Для этого откроем файл /etc/dnsmasq.conf и изменим следующую строку (не забываем раскомментировать при необходимости):
Для настройки DHCP сервера достаточно указать диапазон пула адресов и срок аренды:
После чего хосты внутренней сети будут получать все сетевые настройки автоматически.
Настройка кэширующего прокси-сервера Squid3
На заре своего развития основным назначением прокси-сервера Squid было кэширование трафика, сегодня, когда безлимитный интернет стал нормой жизни, эти возможности отходят на второй план, но остаются достаточно актуальными.
Squid поддерживает кэширование двух типов, в оперативной памяти и на диске. Сегодня можно встретить рекомендации отказаться от дискового кэша, мол проще скачать объект заново, чем искать его на диске. Однако мы считаем, что разумный размер дискового кэша при большом количестве клиентов позволяет эффективно использовать канал за счет хранения в кэше статических элементов: картинок, скриптов, CSS-файлов для часто посещаемых ресурсов.
Сразу предостережем от распространенной ошибки - использования для хранения кэша старых медленных дисков и выделения под кэш значительного пространства. В этом случае эффект будет прямо противоположен ожиданиям, время поиска объекта на диске при большой нагрузке будет занимать значительно больше времени, чем его повторное скачивание.
Но все преимущества Squid раскрываются тогда, когда появляется необходимость тонкой фильтрации трафика, здесь богатые возможности позволяют реализовывать самые разнообразные схемы, которые просто невозможно рассмотреть в рамках одного материала, получить все материалы по данной теме вы можете выполнив поиск по тегу squid.
Внимание! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid, также аналогичным образом следует изменить все пути, т.е. вместо /etc/squid3 использовать /etc/squid.
Для установки squid выполните команду:
Перейдем к настройкам. Для новичка конфигурационный файл squid может показаться излишне сложным, на самом деле большую часть его занимают подробные комментарии и примеры. Поэтому мы пойдем по файлу от начала к концу, указывая какие строки надо добавить или изменить. Откроем файл конфигурации /etc/squid3/squid.conf и перейдем к указанию группы доступа (acl) для локальной сети. Раскомментируем и исправим или добавим ниже строку:
Затем, спускаясь далее по конфигурационному файлу найдем секцию отвечающую за правила доступа и убедимся, что она содержит следующие правила:
Данная секция разрешает доступ для клиентов локальной сети, собственно сервера и запрещает всем остальным.
Теперь укажем порт, интерфейс и режим работы прокси-сервера.
Параметр intercept указывает, что прокси работает в прозрачном режиме, т.е. не требует прямого указания прокси на клиентах.
Перейдем к указанию параметров кэша. Зададим доступный объем памяти и укажем максимальный объем кэшированного объекта в памяти:
При задании этих параметров исходите из доступной памяти сервера, но учтите, что кэш в памяти начинает эффективно работать только после "прогрева" и будет сброшен при перезагрузке или выключении сервера.
После чего укажем размер дискового кэша и его расположение:
Размер кэша указывается в МБ, в нашем случае 2048 МБ - 2 Гб, следующие два числа указывают количество директорий первого и второго уровня, рекомендуем оставтить эти параметры без изменения.
Следующий параметр задает максимальный размер объекта в дисковом кэше:
Далее по файлу укажем место хранения логов и количество ротаций:
В нашем случае логи хранятся 31 день, указывая это значение исходите из размеров лога и свободного места на диске, в любом случае этот параметр можно всегда изменить.
Внимание! В Ubuntu Server 12.04 (Squid 3.1) указанная выше строка должна иметь вид: access_log /var/log/squid3/access.log squid
Остальные параметры оставляем без изменений, сохраняем файл настроек.
Перед тем как перезапускать службу выполним проверку файла конфигурации:
Если команда отрабатывает без вывода - ошибок нет, в противном случае изучаем вывод и исправляем допущенные ошибки. После этого перезапустим службу, чтобы применить внесенные изменения.
В том случае, когда были изменены параметры кэша следует его перестроить:
Сохраняем изменения, перезагружаем сервер.
Обращаем ваше внимание, что squid3 в прозрачном режиме, в отличие от предыдущей версии, не принимает соединения, если в настройках прямо указано использование прокси.
Как видим, настройка роутера на современной платформе, несмотря на отличия, остается весьма простой и доступна для повторения широкому кругу читателей. В наших будущих материалах мы также будем принимать за основу роутер, настроенный именно по данному материалу, в тоже время с данным роутером будут работать все решения, опубликованные нами ранее, хотя для некоторых из них могут понадобиться незначительные корректировки.
Вас трудно понять. На том порту что-то слушает его? Есть tcptraceroute, которая аля-traceroute и в некотором смысле аля-ping.
пробрось обычный echo сервис и проверяй
Рассмотрим ситуацию на примере ПК с win. На роутере проброшен порт 3389. Когда я извне подключаюсь по rdp сессия поднимается. Тогда понятно, что ПК, к которому подключаюсь, включен. А я хочу знать, что ПК отвечает на запросы без подключения по rdp.
nmap -sS -p 3389 HOST | grep -q open && echo Ok
Так как это быстрое полуоткрытие tcp соединения, нужен root.
vodz ★★★★★ ( 05.09.17 09:54:12 )Последнее исправление: vodz 05.09.17 09:56:07 (всего исправлений: 1)
у него ms-wbt-server -sV подойдет лучше т.к. не требует рута
не думаю что на порту что-то другое, раз такой вопрос в теме
Morin ★★★ ( 05.09.17 10:03:39 )Последнее исправление: Morin 05.09.17 10:04:05 (всего исправлений: 1)
у меня не ms-wbt-server. Я просто не могу называть вещи своими именами, если вы понимаете о чем я=) Оба устройства на linux.
а ну тогда syn флуд вам уже написали, пользуйтесь
зы, надеюсь это ваши тачки, а то ведь может и не работать ;)
Morin ★★★ ( 05.09.17 10:06:27 )Последнее исправление: Morin 05.09.17 10:07:35 (всего исправлений: 1)
я проверил -sV на открытый свой сервер 80 порт. 8 секунд думает, на закрытый - две. Офигеть как удобно.
Тема исчерпания адресного пространства IPv4 уже не нова. В какой-то момент в RIPE появились очереди ожидания (waiting list), затем возникли биржи, на которых торговали блоками адресов и заключались сделки по их аренде. Постепенно операторы связи начали предоставлять услуги доступа в Интернет с помощью трансляции адресов и портов. Кто-то не успел получить достаточно адресов, чтобы выдать «белый» адрес каждому абоненту, а кто-то начал экономить средства, отказавшись от покупки адресов на вторичном рынке. Производители сетевого оборудования поддержали эту идею, т.к. этот функционал обычно требует дополнительных модулей расширения или лицензий. Например, у Juniper в линейке маршрутизаторов MX (кроме последних MX104 и MX204) выполнять NAPT можно на отдельной сервисной карте MS-MIC, на Cisco ASR1k требуется лицензия СGN license, на Cisco ASR9k — отдельный модуль A9K-ISM-100 и лицензия A9K-CGN-LIC к нему. В общем, удовольствие стоит немалых денег.
IPTables
Задача выполнения NAT не требует специализированных вычислительных ресурсов, ее в состоянии решать процессоры общего назначения, которые установлены, например, в любом домашнем роутере. В масштабах оператора связи эту задачу можно решить используя commodity серверы под управлением FreeBSD (ipfw/pf) или GNU/Linux (iptables). Рассматривать FreeBSD не будем, т.к. я довольно давно отказался от использования этой ОС, так что остановимся на GNU/Linux.
Включить трансляцию адресов совсем не сложно. Для начала необходимо прописать правило в iptables в таблицу nat:
Операционная система загрузит модуль nf_conntrack, который будет следить за всеми активными соединениями и выполнять необходимые преобразования. Тут есть несколько тонкостей. Во-первых, поскольку речь идет о NAT в масштабах оператора связи, то необходимо подкрутить timeout'ы, потому что со значениями по умолчанию размер таблицы трансляций достаточно быстро вырастет до катастрофических значений. Ниже пример настроек, которые я использовал на своих серверах:
И во-вторых, поскольку по умолчанию размер таблицы трансляций не рассчитан на работу в условиях оператора связи, его необходимо увеличить:
Также необходимо увеличить и количество buckets для хэш-таблицы, хранящей все трансляции (это опция модуля nf_conntrack):
NFTables
Сейчас модным направлением в программном «перекладывании пакетиков» является использование DPDK и XDP. На эту тему написана куча статей, сделано много разных выступлений, появляются коммерческие продукты (например, СКАТ от VasExperts). Но в условиях ограниченных ресурсов программистов у операторов связи, пилить самостоятельно какое-нибудь «поделие» на базе этих фреймворков довольно проблематично. Эксплуатировать такое решение в дальнейшем будет намного сложнее, в частности, придется разрабатывать инструменты диагностики. Например, штатный tcpdump с DPDK просто так не заработает, да и пакеты, отправленные назад в провода с помощью XDP, он не «увидит». На фоне всех разговоров про новые технологии вывода форвардинга пакетов в user-space, незамеченными остались доклады и статьи Pablo Neira Ayuso, меинтейнера iptables, про разработку flow offloading в nftables. Давайте рассмотрим этот механизм подробнее.
Основная идея заключается в том, что если роутер пропустил пакеты одной сессии в обе стороны потока (TCP сессия перешла в состояние ESTABLISHED), то нет необходимости пропускать последующие пакеты этой сессии через все правила firewall, т.к. все эти проверки всё равно закончатся передачей пакета далее в роутинг. Да и собственно выбор маршрута выполнять не надо — мы уже знаем в какой интерфейс и какому хосту надо переслать пакеты пределах этой сессии. Остается только сохранить эту информацию и использовать ее для маршрутизации на ранней стадии обработки пакета. При выполнении NAT необходимо дополнительно сохранить информацию об изменениях адресов и портов, преобразованных модулем nf_conntrack. Да, конечно, в этом случае перестают работать различные полисеры и другие информационно-статистические правила в iptables, но в рамках задачи отдельного стоящего NAT или, например, бордера — это не так уж важно, потому что сервисы распределены по устройствам.
Конфигурация
Чтобы воспользоваться этой функцией нам надо:
- Использовать свежее ядро. Несмотря на то, что сам функционал появился еще в ядре 4.16, довольно долго он было очень «сырой» и регулярно вызывал kernel panic. Стабилизировалось всё примерно в декабре 2019 года, когда вышли LTS ядра 4.19.90 и 5.4.5.
- Переписать правила iptables в формат nftables, используя достаточно свежую версию nftables. Точно работает в версии 0.9.0
Конфигурация NAT очень проста:
С flow offload немного сложнее, но вполне понятно:
Вот, собственно, и вся настройка. Теперь весь TCP/UDP трафик будет попадать в таблицу fastnat и обрабатываться намного быстрее.
Результаты
Чтобы стало понятно, насколько это «намного быстрее», я приложу скриншот нагрузки на два реальных сервера, с одинаковой начинкой (Xeon E5-1650v2), одинаково настроенных, использующих одно и тоже ядро Linux, но выполняющих NAT в iptables (NAT4) и в nftables (NAT5).
На скриншоте нет графика пакетов в секунду, но в профиле нагрузки этих серверов средний размер пакета в районе 800 байт, поэтому значения доходят до 1.5Mpps. Как видно, запас производительности у сервера с nftables огромный. На текущий момент этот сервер обрабатывает до 30Gbit/s при 3Mpps и явно способен упереться в физическое ограничение сети 40Gbps, имея при этом свободные ресурсы CPU.
Надеюсь, этот материал будет полезен сетевым инженерам, пытающимся улучшить производительность своих серверов.
Читайте также: