Лабораторная работа «Обучаемся настраивать сети в GNU/Linux»

  • Tutorial
Никто не любит длинные вступления, поэтому сразу к сути.
В данной импровизированной лаборатории я хотел бы осветить работу с сетями в GNU/Linux
и рассмотреть следующие темы:

  1. Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.
  2. Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.
  3. Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.
  4. Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT.
  5. Iptables. Настраиваем security zones. Изучаем tcp сессии.


З.Ы. все люди ошибаются, я открыт для ваших комментариев, если я написал какую-то глупость, готов ее исправить!

Дано: локальная сеть, состоящая из VM1,VM2. Роутер R1 (тоже виртуальная машина), веб сервер S1.
Скачать готовую виртуалку для этой лабораторки можно с яндекс диска
Т.к. я попытался подать данную статью как урок, то по большей части я не пишу команды текстом, а делаю скриншот, чтобы их вбивали своими руками. Это помогает лучше разобраться и быстрее запомнить. Я вполне понимаю что это неудобно, но я решил выбрать такой подход.
Схема сети


Пример виртуальных машин в моем VBOX


Настройка для VM1 — подключаем как bridge к интерфейсу. Интерфейс можно выбрать любой и забриджевать все на него. Для полноты соответствия схеме я сделал в системе 2 bridge адаптера (br0,br1) и подключил vm1,vm2,r1(адаптером 1) к br0, а s1,r1(адаптером 2) к br2.
пример настройки адаптера


Для остальных 3-х настройки аналогичны.

I. Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.



Запускаем vm1 и vm2 и смотрим интерфейсы в нашей системе командой
ip addr
(сокращенно ip a)
Результат


Добавляем новое устройство, которое будет называться eth0.100 и представлять собой тегированный интерфейс с id=100.
Результат


ip link add - добавить устройство
link eth0 - соединить с ФИЗИЧЕСКИМ адаптером eth0
name eth0.100 - имя устройства в списке. Это имя можно выбрать любым, но для собственного удобства мы выбрали имя физического интерфейса и номер vlan. так то точно не запутаемся
type vlan - тип создаваемого интерфейса. Оно работает с 8021q - тип vlan
id 100 - собственно сам id vlan


Теперь присвоим этому интерфейсу ip адрес:
ip addr add 10.10.10.10/24 dev eth0.100

короткий вид записи:
ip a a 10.10.10.10/24 dev eth0.100

Результат


Обращаем внимание на следующие вещи: no-carrier и DOWN
это значит что у нас к интерфейсу не подключен сетевой кабель, а сам интерфейс находится в DOWN.
Результат


Подключаем кабель и получаем такую картину:
Результат


И выполним включение интерфейса командой:
ip link set dev eth0.100 up

Результат


Таким образом мы создали интерфейс, который будет получать тегированные пакеты с vlan id = 100 и соответственно вешать на пакеты тег 100 при выпуске пакета в сеть через этот интерфейс. и назначили ему ip адрес 10.10.10.10/24
делаем то же самое на VM2, назначаем адрес 10.10.10.20/24
Результат


Проверяем связность между VM1 и VM2: выполним ping 10.10.10.10 с VM2
Результат


Подведем итог: мы создали на 2 машинах в 1 локальной сети 2 тегированных интерфейса в 100-том vlan-е и проверили связность между ними.

Проверяем, что все это не ложь и провокация! Запустим на VM1 слушателя и постучимся на него с VM2 и проснифаем траффик.
1. на VM1 запустим
nohup nc -lvp 3000 &
tcpdump -n host 10.10.10.20 -i eth0 -e

2. на VM2 запустим
nc 10.10.10.10 3000
Результат


Видим в заголовках канального уровня vlan 100. Значит пакеты по сети реально ходят с тегами и это не выдумки матушки гусыни.

II. Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.



Теперь переходим к пункту №2 — разобьем эти 2 виртуалки на разные vlan и настроим роутер.
На VM1:
добавить интерфейс eth0.200 c тегом 200 и присвоить ему адрес 192.168.0.2
на VM2:
добавить интерфейс eth0.300 c тегом 300 и присвоить ему адрес 172.16.0.2
(Самостоятельно)
Результат (VM1)


Результат (VM2)


Включим и настроим роутер R1. На роутере в отличие от VM1, VM2 нужно создать интерфейс и во vlan 200 и во vlan 300 — этот интерфейс будет шлюзом в данных сетях. Присвоим им адреса 192.168.0.1, 172.16.0.1.
Результат



Проверяем связность. Пингуем с роутера 192.168.0.2 и 172.16.0.2. (Кстати говоря вот тут была небольшая проблема, т.к. я ошибся в настройке eth0.300 на VM2.
Я не нашел ошибку
вместо id=300 я прописал id=200

Результат



Итак, мы получили связность между VM1,R1 и VM2,R1. Попробуем связать VM1,VM2 через R1.
Для того чтобы наш Router получил возможность форвардить пакеты между интерфейсам нужно разрешить ему это. Необходимо раскомментировать директиву net.ipv4.ip_forward = 1 в файле /etc/sysctl.conf и применить изменения командой sysctl -p.

# nano /etc/sysctl.conf
# sysctl -p
net.ipv4.ip_forward = 1

Результат


А теперь самое главное. Нужно настроить маршрутизацию. Есть 3 распространенных способа это сделать:
1. указать маршрут по умолчанию. т.е. мы не знаем где у нас находится destination ip, поэтому все пакеты не принадлежащие локальной сети шлем на роутер.
2. указать шлюз для конкретной подсети. Это нужно делать если сети доступны за разными маршрутизаторами.
3. указать интерфейс, за которым находится тот кто примет пакет. Такая ситуация у меня возникала, например при необходимости в ЦОДе смаршрутизировать подсеть. Т.е. Была виртуалка-роутер на внешний адрес которой датацентр статически маршрутизировал выделенную мне подсеть. Тогда я просто указал что ip адеса этой подсети находятся на одним из торчащих внутрь интерфейсов роутера. Пакеты слались в этот интерфейс и принимались на той стороне виртуалками, которым и были назначены эти белые адреса. т.е. в данной ситуации указывать шлюз было совершенно необязательно.
посмотрим список маршрутов на VM1:
ip ro

Результат


Наша виртуалка знает всего о 2 подсетях: 10.10.10.0/24 & 192.168.0.0/24. Про хост 172.16.0.2 ничего не сказано! потому если попробовать пропинговать ничего не выйдет:
Результат


добавим маршрут к подсети 172.16.0.0/24:
ip ro add 172.16.0.0/24 via 192.168.0.1

via — значит через кого. т.е. отправляем пакеты хосту 192.168.0.1, он разберется.
Просматривая таблицу маршрутизации принимается следующее решение:
1. Кому предназначен данный пакет? хосту 172.16.0.2
2. Кому отправить пакет 172.16.0.2? хосту 192.168.0.1
3. Что мы знаем о хосте 192.168.0.1? он directly connected. Эта подсеть наша. формируем на канальном уровне mac адрес источника, mac адрес хоста 192.168.0.1, ip источника — 192.168.0.2, ip адрес назначение 172.16.0.2, и отправляем через интерфейс eth0.200. Как говорил автор подкаста «сетей для самых маленьких», дальшейшая судьба пакета нас не волнует.
Попробуем пропинговать шлюз соседнего vlan:
ping 172.16.0.1

Результат


Работает! Но что будет если пинговать 172.16.0.2? Работать не будет, потому что нет обратного маршрута. Пакет дойдет до хоста VM2, а вот обратно VM2 отправить его уже не сможет, т.к. не знает куда. Попробуем добавить маршрут обратно на VM2.
Добавим маршрут по-умолчанию для VM2. Сделать это можно указав подсеть и маску (0.0.0.0/0 — т.е. под нее попадают абсолютно все адреса) или используя ключевое слово default
Результат


Получим один и тот же результат. И в итоге теперь VM1 свободно пингует VM2. Ура!

Подведем итог: Мы научились выполнять маршрутизацию между 2 vlan с помощью linux-роутера.

III. Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.



Добавляем некий публичный сервер S1. на нем я поставлю apache2 (apt install apache2) и буду имитрировать веб-сервер в интернете. Тогда как наши VM1,VM2 — приватные машинки, которые находятся за роутером. Роутер вторым интерфейсом смотрит в импровизированный интернет.
Добавим 2-й интерфейс для R1 — eth1 и уже без VLAN настроим ему ip адрес 8.8.8.100, а на S1 — 8.8.8.8
Результат


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


Если вы повторяете за мной в том числе и настройку VBOX, не забудьте добавить в br1 обе сетевые карты и на S1 и на R1. Bridge интерфейс в системе можно создать командой
ip link add br1 type bridge
.
Но вообще сделать всю лабу можно сделать и на одном любом интерфейсе ничего не создавая.
Я акцентирую разделение для того чтобы имитировать bridge = как бы коммутатор.

После настройки S1, R1 проверяем связность — выполним ping 8.8.8.8 — с R1 он должен работать. При этом если мы будем пинговать с VM2, то пинга не будет.
Почему?
Потому что S1 не знает о сети 172.16.0.0. добавим наш R1 как шлюз по умолчанию для S1:
ip ro add default via 8.8.8.100



Кроме того, если мы будем пинговать сервак с VM1 то он вообще скажет что сеть недоступна.
Почему?
Потому что мы вообще не прописывали default gw, а указали где находится сеть 172.16.0.0/24.


Исправим это прописав gateway:
Результат



Теперь все 4 машинки прекрасно пингуют друг друга. Но так быть не должно. Серые адреса не должны выходить в интернет! И та сеть, куда смотрит вторым интерфейсом R1, не должна знать где находятся адреса 172.16.*.*, 192.168.*.*.
Удалим deafult gw с S1:
ip ro del default


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

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

Настроим маскарад для подсети 17.16.0.0/24 — выполним на роутере команду:
iptables -t nat -A POSTROUTING -p tcp -m tcp -s 172.16.0.0/24 ! -d 172.16.0.0/24 -j MASQUERADE

Я не буду расписывать подробно как работают iptables, т.к. это много и много буков и эта статья явно не для этого. Вот очень неплохая статья на изучение.
Обращу только внимание на ! -d 172.16.0.0/24: зачем это нужно. Это нужно для того чтобы хосты из подсети 172.16.0.0/24, которые потенциально могли бы находиться за маршрутизатором (например удаленные vpn клиенты) не попадали бы под действие этого правила.
Посмотреть полученный результат можно командой iptables-save

Итак, чего мы достигли? Мы настроили маскарад для VM2. Это значит что когда она будет стучаться к S1, то S1 увидит адрес не VM2, а адрес роутера! Парочка пруфов:
Результат


а что же в этот момент видит S1?
Результат


8.8.8.8 прекрасно общается с 8.8.8.100, никаким 172.16.0.2 и не пахло!
А что же происходит в этот момент на роутере? Как работает эта кухня? Подслушаем «серый» интерфейс eth0.300
Результат


А вот как это выглядит на выходе во «внешнюю» сеть:
Результат



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

Подведм итог: Мы скрыли наши серые сети и выпустили хосты за роутер, подменив ip адеса источников на адрес роутера. И в другую сторону — мы научились пробрасывать определенный порт определнной виртуалки «наружу» и смогли подключиться к серому адресу виртуалки VM1 из «публичной» сети с сервера S1.

IV. Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT



Сымитируем, что S1 — некий клиент из интернета и он хочет подключиться к VM1 (тот клиент, до которого нет ни маршрута, ни настроен маскарад). Пусть это будет попытка подлючиться по ssh. SSH по дефолту висит на 22 порту, но если у нас таких серваков будет больше 1, то как быть? Вообще по-хорошему чтобы избавиться от самых простых сканеров сети, ssh нужно всегда убирать с 22 порта. Воспользуемся портом 30022, например, чтобы обратиться по ssh к VM1.

Как это работает?
S1 отправляет пакет (s.ip=S1.ip, d.ip=R1.ip; s.port=N, d.port=30022) который прилетает на R1.
R1 Просматривает iptables и применяет правило DNAT, и формирует пакет (по нашему правилу): (s.ip=S1.ip, d.ip=VM1.ip; s.port=N, d.port=22)
Просматривает таблицу маршрутизации и отправляет пакет vm1 через интерфейс eth0.200.

VM1 в свою очередь принимает пакет, получает data, и формирует ответ: (s.ip=VM1.ip, d.ip=S1.ip; s.port=22, d.port=N).
R1 принимает пакет и восстанавливает исходный s.ip к которому изначально обратился s1:
(s.ip=R1.ip, d.ip=S1.ip; s.port=22, d.port=N)

Достичь этого можно следующим образом:
Результат


пробуем подключиться:
Результат



Подведм итог: мы научились предоставлять доступ к сервисам, расположенным на виртуальных машинах за неким роутером (иначе можно сказать — к виртуалкам за NAT'ом — что как раз чаще всего и нужно)

V. Iptables. Настраиваем security zones. Изучаем tcp сессии.



И последнее, что я хотел бы рассмотреть в данном занятии — tcp сессии и направление установки этих сессий. Так, например, рассмотрим 2 сегмента: серверный и клиентский. Клиент, например, должен иметь возможность «сходить» в серверный сегмент к контроллеру домена. А вот контроллеру домена делать на клиентской машине нечего. Таких примеров можно придумать множество и ситуации почему из одного сегмента сети в другой ходить можно а наоборот нет — тоже. Зачем же может это понадобиться? Например у нас есть веб сервер, который «смотрит» в интернет и им «завладел» злоумышленник. С этого сервера он вполне может попробовать постучаться в корпоративную сеть. Однако, если запретить устанавливать сессии из этого сегмента — этого не произойдет. Т.е. мы по крайней мере усложняем злоумышленнику жизнь. Давайте добавим правило, которое запретит ходить VM2 к VM1, а VM1 к VM2 — можно.
Результат


Пробуем ходить с VM1 на VM2:
Результат


и в обратную сторону:
Результат


Почему так происходит? В момент установления TCP сессии прилетает пакет TCP SYN (на него отвечается SYN ACK, а потом ACK и сессия считается установленной). первое правило которое мы записали (c NEW) разрешает форвардить пакеты TCP SYN из сети 192.168.0.0 в 172.16.0.0.
Когда второй участник отвечает на этот и любой последубщий пакет, то попадает под действие 2 правила об установленных сессиях и такие пакеты из сети 172.16.0.0 проходят. А вот если он сам попробует установить сессию (или просто пингануть) то не попадет по 1,2 правило, а попадет под 3-е, которое дропнет этот пакет. Voila!

Подведем итог: Мы научились управлять направлениями установки tcp сессий для контроля направления трафика между зонами безопасности.

Спасибо за внимание!

Свои черновики лекции я выкладываю в канале telegram: t.me/bykvaadm
Share post

Similar posts

Comments 24

    0

    Втыкаем кабель — как это должно выглядеть на виртуалке? Сппсибо.

      0
      на vmware\vbox в свойствах адаптера есть возможность подключить\отключить кабель. у вмваре галочка «connected», у vbox можно из панели например или в
      свойствах


      –4

      А как же BGP, OAM или хотя бы бондинг? Какая-то хилая лабораторка.

        +5
        Вы хотите простыню, которую никто не прочитает?
          0
          Хорошие темы для следующей лабораторки, всему свое время.
            0
            наверное я так и сделаю=)
          0
          What about username/password from VM с яндекс диска?
            0
            Первым практическим заданием было сбросить пароль в выданной виртуалке. Сделать это можно очень большим количеством способов, зависит только лишь от факторов которые нас могут сдержать. На текущий момент сходу я могу предложить сдедующие варианты:
            1. Загрузка в /bin/bash и установка нового пароля. Область применения: есть возможность перезагрузить физическую или виртуальную машину.
            2. Монтирование диска. Область применения: есть доступ к физическому или логическому (vmdk например) диску, который мы можем подцепить к другому работающему linux
            3. LiveCD. Область применения: есть возможность загрузки со съемного носителя (диска или флешки и iso в случае виртуалки)
            4. Нажатие 28 раз backspace (хак. Актуально для старых версий grub)

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

            5. патчим в файле оперативки демона который отвечает за проверку паролей. Входим под любым.
            6. вытаскиваем /etc/shadow и брутим пароль
            7. Изменяем /etc/shadow и используем какой-либо доступный механизм (например крон.час) для запуска какого-либо скрипта, который заставит ядро перечитать файл /etc/shadow.

            Как сделать 1,2 пункты в картинках: http://www.oldnix.org/reset-password-root-linux/
            0
            Отстранённый вопрос, который пару дней не даёт мне покоя — есть ли какие-нибудь законченные (всымсле максимально «из коробки») способы поднять такой стенд без использования полноценных виртуальных машин? Например используя LXC или Docker?
              0
              Ещё бы ко всему этому openvswitch бы, конечно, раз такая пьянка
                0
                в этом стенде используется все из коробки. пакет iproute2 и iptables предустановлены в любом современном дистрибутиве. поидее вам кроме этого ничего и не нужно. apache2, nc, tcpdump — доп инструменты, для того чтобы убедиться как именно работает то что мы настраиваем.
                т.е. вы можете развернуть 1 контейнер, поставить туда по и раскопировать его 4 раза. Достаточно к голому дебиану поставить пару доп пакетов и все
                  0
                  Понятно, что везде есть и iproute и iptable и прочее. Так же понятно, что можно вручную всё развернуть. Я ищу как раз автоматизированное решение с гуём или что-то подобное
                    +1
                    конкретно такой лабораторки нет. и делать ее автоматизированной не вижу смысла.
                  0
                    0
                    Спасибо тебе, добрый человек! =)
                      0
                      Собственно, мне следовало изначально оставить ещё и ссылку на курс. Он начинается совсем скоро, у всех сетевиков есть шанс на него успеть.
                  0
                  Если есть интерес, то есть такая интересная штука ip netns. В русскоязычной части, примеров и описания не так много, да и зарубежных то не очень — хотя там все достаточно просто.
                  У меня с использованием ip netns — сервер обеспечивает доступ в тестовой зоне на CPE (ONT) со стороны LAN, с одинаковыми LAN IP (в которых крутятся tftp/ftp и т.д.) могу описать поподробнее, если будет интересно )
                    0
                    Про namespace я во второй лабе буду рассказывать
                    0
                    Вот только не до конца ясен смысл vlan`ов, которые в самом начале были упомянуты. Т.е что дает привязка таких тегов к интерфейсам?
                      0
                      Не совсем понятно, что имели ввиду. Попробую угадать — как минимум Uplink для сервера/ПК — может быть транковый, с кучей VLAN (грубо говоря по которым могут предоставляться различные сервисы, обслуживать сегменты и т.п.). А остальное будет зависеть, от фантазии и необходимости, того какой интерфейс создадут:
                      eth, виртуальные tun/tap, br, bound и т.п., которые будут в данных. (чего тоже не особо касались в статье)
                      + Я не заметил коснулись ли в статье нетегированного трафика? Данный момент возможно будет интересен с понятием native у Cisco.
                        0
                        не стоит делать статью слишком раздутой. Выше я уже это говорил. Все то что вы перечислили будет в последующих статьях.

                        А чем нетегированный трафик интересен? Это же просто обычный трафик. Мы можем сделать native присвоив адрес на eth0. И получить что-то типо порта с названием «гибридный» в терминологии HP.
                        0
                        Я не упоминаю в статье что такое vlan и зачем он нужен, это правда. Ставилась больше задача показать как это настроить. Я учту ваш комментарий при дальнейшем написании статей.
                        0
                        Важно помнить, что все команды, которые мы вводили в консоли работают только до перезагрузки. Когда я добавлял 2 интерфейс и выключил виртуалку, то после перезагрузки получил не настроенную машину, вследствие чего все команды пришлось применить заново.

                        Я бы добавил в команды в скрип после загрузки /etc/rc.local иди в /etc/network/*.
                          0
                          бесспорно. но это не интересно. пущай гуглят.

                        Only users with full accounts can post comments. Log in, please.