Как объединить две сети в одну

Объединение локальных сетей при помощи OpenVPN на VPS

Рассмотрим способ объединения двух локальных сетей (site to site) при помощи OpenVPN развернутого на VPS хостинг провайдера. Схема сети, следующая:

В качестве площадки для размещения серверной части OpenVPN можно использовать VPS/VDS с предоставляемым публичным IP–адресом. В нашем случае это будет хостинг-провайдер firstvds.ru. Виртуальный сервер с 1 Гб оперативной памяти, 20 Гб дискового пространства и выделенным публичным IP–адресом обойдется нам в 239 р./ месяц. Хостинг-провайдер позволяет выбрать предустановленный вариант ОС на виртуальном сервере. Будем использовать Ubuntu 22.04.

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

Шаг 1. Подготовка виртуального сервера

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

$ sudo apt update

$ sudo apt upgrade

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

$ sudo apt install nano mc net-tools

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

$ adduser username sudo

username замените на имя вашего пользователя.

Отключим доступ по SSH от root пользователя:

$ sudo nano /etc/ssh/sshd_config

Закомментируем строку #PermitRootLogin yes и сохраним изменения.

Установим ufw (простой фаервол), выполнив следующую команду:

$ sudo apt-get install ufw

Также нам нужно открыть затребованные порты, такие как SSH port 22, 80, 443, 993 и так далее:

$ sudo ufw allow 22

$ sudo ufw allow 80

$ sudo ufw allow 443

$ sudo ufw allow 993

Для включения фаервола воспользуемся следующей командой:

$ sudo ufw enable

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

$ sudo ufw status

Шаг 2. Установим OpenVPN при помощи скрипта openvpn-install.sh

Выполним команду wget:

$ wget https://git.io/vpn -O openvpn-install.sh

Запустим скрипт openvpn-install.sh для установки и настройки сервера OpenVPN в автоматическом режиме:

$ sudo bash openvpn-install.sh

Выполним простое конфигурирование выбрав необходимые параметры.

Протокол: TCP; Порт: 993, для того чтобы замаскироваться под Internet Message Access Protocol (IMAPS); ДНС сервер 1.1.1.1 или другой удобный для вас.

На последнем шаге указываем имя клиента (например, client1, client2, и т.д.). Нажимаем Enter, скрипт должен все успешно установить.

Для добавления нового клиента повторно выполните запуск скрипта и укажите Add a new client введя цифру 1.

Количество клиентов соответствует количеству локальных сетей и отдельных пользователей, которые необходимо объединить в одну виртуальную сеть.

Шаг 3. Конфигурирование файла server.conf

Далее необходимо выполнить ряд изменений в файле конфигурации OpenVPN сервера server.conf. Для этого его откроем в редакторе nano:

$ sudo nano /etc/openvpn/server/server.conf

Закомментируем строки начинающиеся на push и добавим следующие записи:

client-config-dir /etc/openvpn/server/ccd – укажем путь к настройка сетей клиентов;

route 192.168.0.0 255.255.255.0

route 192.168.43.0 255.255.255.0

Данными записями мы указываем серверу о наших локальных сетях 192.168.0.0/24 и 192.168.43.0/24. В вашем случае укажите все локальные сети, которые необходимо объединять.

client-to-client – разрешаем маршрутизацию между добавленными сетями.

push «route 192.168.0.0 255.255.255.0»

push «route 192.168.43.0 255.255.255.0»

Данными записями мы задаем настройки маршрутизации нашим клиентам. Сохраняем файл конфигурации (ctrl+o) и выходим (ctrl+x). Пример файла конфигурации:

Далее необходимо описать сетевую конфигурацию клиентов и создать соответствующие фалы в директории /etc/openvpn/server/ccd.

Данная директория не создается по умолчанию, создадим её при помощи следующих команд:

Далее перейдем в эту директорию и создадим файлы наших клиентов, названия должны совпадать с именами клиентов:

Добавим в него следующую запись:

iroute 192.168.0.0 255.255.255.0

То есть client1 находится в сети 192.168.0.0/24. Для других клиентов выполним аналогичные записи. Главное, чтобы имя файлов совпадало с именами клиентов.

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

$ sudo systemctl restart openvpn

Также для взаимодействия со службой OpenVPN имеются следующие команды:

$ sudo systemctl stop openvpn – остановка службы;

$ sudo systemctl start openvpn – запуск службы.

Шаг 4. Выгрузка файлов конфигураций клиентов

Далее необходимо выгрузить с виртуального сервера сконфигурированные файлы клиентов (.ovpn). По умолчания файлы (.ovpn) создаются в директории root, их необходимо скопировать в директории /home/username. К данной директории можно подключиться сторонним SFTP клиентом. Для этого удобнее всего воспользоваться клиентом WinSCP. Подключимся к нашему серверу по протоколу SFTP, указав IP–адрес виртуального сервера и данные авторизации.

Установим OpenVPN клиенты на подключаемые windows машины и передадим им соответствующие конфигурационные файлы (.ovpn) и установим подключение.

После установки соединений в windows прописывается необходимая маршрутизация, для вывода в командной строке необходимо прописать команду route print. Пример вывода списков маршрутов с клиента 1:

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

Далее необходимо на каждой windows машине запустить службу, отвечающую за внутреннюю маршрутизацию, служба называется Маршрутизация и удаленный доступ. Это позволит использовать адресацию локальной сети. Для запуска этой службы нажмите клавиши Win+R на клавиатуре (или нажмите правой кнопкой мыши по кнопке «Пуск» и выберите пункт «Выполнить»), введите services.msc в окно «Выполнить» и нажмите Ok или Enter. Далее найдите службу Маршрутизация и удаленный доступ укажите тип запуска вручную, нажмите применить и затем нажмите кнопку Запустить.

После выполнения указанных действий наши windows машины могут быть доступны по своим локальным адресам.

На этом все, надеюсь материал оказался для Вас полезным.

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

Объединение двух локальных сетей с одинаковым номерами сетей на Linux-шлюзе

При создании локальной сети не каждый администратор подходит с ответственностью к выбору диапазона адресов. А может и не каждый догадывается о наличии частных диапазонов кроме 192.168.0.0/24. И со временем такая бомба замедленного действия может дать о себе знать. Локальные сети объединяются, возникает потребность в коммуникации между хостами разных сетей. И тут выясняется, что номера сетей совпадают. И менять их по каким либо причинам проблематично или невозможно.

В таком случае, серверу, маршрутизирующему пакеты между сетями, остается сделать вид, что номера сетей различны и выдавать желаемое за действительное. В богатом арсенале Linux есть средства для таких манипуляций: iptables с NETMAP и утилита ip.

Цель

Из сети LAN1 мы хотим послать пакет в сеть LAN2. Но мы не можем послать его в сеть, номер которой одинаков с нашим. В самом частом случае 192.168.0.0/24. Если такой пакет появится в LAN1, он не будет знать, что есть LAN2, он будет искать такую машину в LAN1. Таковы правила маршрутизации по умолчанию.
Значит, надо посылать пакеты с другими адресами, которые уйдут в роутер.

Как это должно вглядеть для наблюдателя из LAN1
Например, пользователь сети LAN1 будет видеть сеть LAN2 как 10.8.1.0/24. Тут уже никакого пересечения адресов. LAN1 доволен.

Как это выглядит с обеих сторон
Из LAN1 приходит пакет с адресом отправителя 192.168.0.100 и адресом назначения 10.8.1.200. Из роутера с интерфейса LAN2 выходит тот же пакет с адресом отправителя 10.8.1.100 и с адресом назначения 192.168.0.200. Пакет проходит до адреса назначения и тот шлет в ответ на адрес отправителя со своим адресом. Пакет уходит в роутер. В нем происходит обратное преобразование и пользователь LAN1 получает ответ с того адреса, на который отправил пакет.

Теория. Путь пакета в ядре роутера: netfilter

Здесь я попытаюсь рассказать о путешествии транзитного трафика через наш Linux-роутер. Для полного понимания процесса путешествия пакета лучше видеть схему его прохождения из Википедии по цепочкам netfilter.

Наш пакет с [источником|назначением] [192.168.0.100|10.8.1.200] попадает на сетевой интерфейс роутера и первой его цепочкой будет PREROUTING.

PREROUTING

Проходя по цепочке он попадает в таблицу PREROUTING mangle. В которой посредством iptables мы определяем интерфейс, с которого он пришел, и адрес источника. Если это наш пациент, мы его помечаем действием MARK.
После чего пакет [192.168.0.100|10.8.1.200|(marked)] попадает в таблицу nat. Эта таблица предназначена для трансляции адресов. Поскольку не существует реального адреса 10.8.1.200, то на последующем этапе маршрутизации пакет будет отброшен или уйдет в неизвестном направлении. Поэтому заменяем ему адрес назначения на тот, на который он действительно должен пойти именно тут: [192.168.0.100|192.168.0.200|(marked)]. Делается это действием NETMAP, которое заменяет номер сети по маске.

ROUTING

Наш пакет пакет попадает на этап принятия решения, куда он должен идти дальше. Он промаркирован, поэтому можем отправить его в специальную таблицу маршрутизации, которую мы создали для такого случая. Там принимается решение, что пакет не предназначен для локального компьютера и должен идти в LAN2.

Пакет успешно проходит цепочку FORWARDING. Попадает опять на этап маршрутизации. Если в FORWARDING с ним ничего не случилось, а по идее не должно было. Он идет тем же путем. После чего попадает в POSTROUTING.

POSTROUTING

Без изменений доходя до таблицы nat. Мы должны изменить адрес источника. Ведь ответ на пакет [192.168.0.100|192.168.0.200] будет отправлен в локальную сеть, а не в роутер. Чтоб он попал обратно в роутер, меняем адрес источника на несуществующий [10.8.1.100|192.168.0.200]. Опять же NETMAP. После этого пакет выходит в LAN2.
С ответным пакетом проделываем обратную процедуру, чтоб он дошел до изначального источника.

Реализация

iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8

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

iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24

Узнаем пакет по метке и действием NETMAP в таблице PREROUTING подменяет номер сети.

iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24

В POSTROUTING NETMAP подменяет адрес источника.
После этого все обращения на подсеть 10.8.1.0/24 будут выглядеть внутри LAN2, как обращения из подсети 10.8.2.0/24.

ROUTING

Чтобы маршрутизировать пакеты по метке необходимо создать свою таблицу маршрутизации.Редактируем /etc/iproute2/rt_tables, добавляя уникальное число и название новой таблицы.
256 netmap
Далее надо добавить правило, по которому в эту таблицу будут направляться пакеты на маршрутизацию.

ip ru add fwmark 8 lookup netmap

Теперь помеченные пакеты будут уходить на маршрутизацию в таблицу netmap.

И последним шагом нужно определить маршруты в таблице netmap.

ip route add default dev eth1 table netmap

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

ip route add default via 192.168.1.254 dev eth1 table netmap

Пока рано радоваться, к нам придет ответ из LAN2 [192.168.0.100|10.8.2.200].
Надо сделать все тоже самое, но только преобразовать обратно. Увы, netfilter сам этого не делает. Все действия уже описаны, приведу только последовательность команд для преобразования адресов в одну и в обратную сторону. (В первой таблице маршрутизации необходимости в данном случае нет, но при иных обстоятельствах может понадобиться.)

ip rule add fwmark 8 lookup netmap ip route add 192.168.0.0/24 dev eth1 table netmap iptables -t mangle -A PREROUTING -i tun0 -d 10.8.1.0/24 -j MARK --set-mark 8 iptables -t nat -A PREROUTING -m mark --mark 8 -j NETMAP --to 192.168.0.0/24 iptables -t nat -A POSTROUTING -m mark --mark 8 -j NETMAP --to 10.8.2.0/24 # в обратную сторону ip rule add fwmark 9 lookup netmap2 ip route add 192.168.0.0/24 dev tun0 table netmap2 iptables -t mangle -A PREROUTING -i eth1 -d 10.8.2.0/24 -j MARK --set-mark 9 iptables -t nat -A PREROUTING -m mark --mark 9 -j NETMAP --to 192.168.0.0/24 iptables -t nat -A POSTROUTING -m mark --mark 9 -j NETMAP --to 10.8.1.0/24

Результаты

Вот что пишет tcpdump (первый пример с vnc, второй с пингом):

tcpdump -i any port 5900

12:46:46.358969 IP 192.168.0.100.41930 > 10.8.1.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.358978 IP 10.8.2.100.41930 > 192.168.0.200.5900: Flags [P.], seq 647:657, ack 261127, win 1213, options [nop,nop,TS val 460624 ecr 171318], length 10
12:46:46.505847 IP 192.168.0.200.5900 > 10.8.2.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0
12:46:46.505861 IP 10.8.1.200.5900 > 192.168.0.100.41930: Flags [.], ack 657, win 64879, options [nop,nop,TS val 171320 ecr 460624], length 0

tcpdump -i any icmp

12:47:46.363905 IP 192.168.0.100 > 10.8.1.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.363922 IP 10.8.2.100 > 192.168.0.200: ICMP echo request, id 2111, seq 1, length 64
12:47:46.364049 IP 192.168.0.200 > 10.8.2.100: ICMP echo reply, id 2111, seq 1, length 64
12:47:46.364054 IP 10.8.1.200 > 192.168.0.100: ICMP echo reply, id 2111, seq 1, length 64

Tcpdump отлично демонстрирует, как происходит преобразование адресов на входе в один интерфейс и на выходе в другой и в обратную сторону.

Так же отлично работают остальные сервисы, типа Samba и ее аналог на Windows.

Note

Если соединение между сетями организовано посредством туннеля OpenVPN, то для правильной маршрутизации со стороны клиента в конфиг сервера необходимо добавить дополнительный маршрут через туннель.
push «route 10.8.1.0 255.255.255.0»

Warning!

При отладке конфигурации не пытайтесь законнектиться к серверу, на котором шлюз. Соединяйтесь с машинами за ним в LAN2.
И вот почему. Правила расчитаны, что пакет будет проходить через шлюз, i. e.
PREROUTING -> Маршрутизация -> FORWARD -> Маршрутизация -> POSTROUTING
Если пакеты будут адресованы 10.8.2.1 (серверу), то они в результате маршрутизации пойдут в цепочку INPUT и преобразование адреса источника в POSTROUTING не будет выполнено.
PREROUTING -> Маршрутизация -> INPUT -> Приложение
Соответственно, адрес источника не будет измненен и ответ будет послан не на 10.8.2.xy, а на 192.168.0.xy — на маршрут по умолчанию для этого диапазона, т. е. в LAN2, а не в LAN1.

Объединение двух локальных сетей через VDS

Несколько офисов можно объединить в одну сеть – это позволяет обеспечить расширенный доступ к информационным ресурсам одной организации. Целью такого слияния обычно служит использование единой офисной АТС, обеспечение доступа к ресурсам компании из различных локаций, удаленный доступ к другим ПК и многое другое.

О том, как все это можно организовать через VDS, мы поговорим в сегодняшней статье.

Как происходит объединение сетей

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

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

Далее мы рассмотрим, как выполнить такую связь на VDS-сервере с использованием PPTP.

Объединяем локальные сети через VDS и PPTP

Мы выяснили, что при слиянии сетей в силу вступает технология VPN, но что же такое PPTP? Это один из первых протоколов, который использовался в VPN еще на ОС Windows 95. Он работает во многих организациях и по сей день. PPTP наиболее простой в настройке и быстрый протокол.

Нельзя не упомянуть и его минусы: PPTP уязвим. Его стандартные методы аутентификации небезопасны, в связи с чем часто взламываются злоумышленниками. Альтернативой этому протоколу могут выступать L2TP, IPSec или OpenVPN – они хорошо защищены и используются многими разработчиками. Однако в данной статье мы не будем на них останавливаться, а рассмотрим лишь подключение через PPTP.

Настройка и подключение PPTP

Для примера мы будем использовать VDS на хостинге Timeweb.

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

Переходим по ссылке и загружаем на рабочий стол PuTTY. Далее запускаем программу и в разделе «Session» вводим IP-адрес хостинга, указываем порт 22 и выбираем SSH-соединение. Последним действием кликаем по кнопке «Open».

В результате перед нами отобразится консольное окно – в нем пока что требуется только авторизоваться. Вводим логин и пароль от своего VDS и следуем далее.

Теперь все последующие команды, которые нам нужно использовать для объединения сетей, можно скопировать и вставить в консоль простым кликом правой кнопки мыши.

Можно переходить к установке протокола. Первым делом ставим PPTP на сервер, для этого вводим:

apt-get install pptpd

Эта и последующие команды актуальны для дистрибутивов Ubuntu.

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

Далее открываем файл для редактирования:

nano /etc/pptpd.conf

При открытии файла перед нами отобразится новое окно. В нем мы будем выполнять последующее редактирование строк.

Указываем диапазон выдаваемых IP-адресов, для этого изменяем строчки localip (IP-адрес вашего сервера) и remoteip (адреса клиентов). Для примера я использую значения:

localip 17.255.0.1 remoteip 17.255.0.100-200

После этого сохраняем внесенные изменения с помощью комбинации клавиш «CTRL+O» и выходим из файла «CTRL+X». Следующим шагом открываем chap-secrets и добавляем в него клиентов. Пример:

A pptpd password 17.255.0.1 B pptpd password 17.255.0.15 C pptpd password 17.255.0.20

Первая буква – это наши сети, password – придуманный пароль, содержащий не более 63 символов, IP – адреса клиентов.

Сохраняем изменения и перезагружаемся:

service pptpd restart

Далее переходим в nano /etc/sysctl.conf и добавляем:

net.ipv4.ip_forward = 1

Завершаем действия строчкой:

sysctl -p

На этом настройка завершена. Далее мы поговорим о подключении Микротика.

Установка MikroTik

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

Запускаем программу Микротик и переходим в Interface -> + PPTP Client. В разделе «General» указываем имя и переходим в окно «Dial Out».

Далее в строчке «Connect To» прописываем адрес для соединения, указываем имя и пароль, в завершение кликаем по кнопке «Apply».

После этого произойдет подключение по адресу 17.255.0.1, который мы указали ранее.

Аналогичным образом подключаем MikroTik к другой сети, он будет соединяться с 17.255.0.15 и другими IP.

Iptables

С Микротиком мы разобрались, но подключиться к нему по VPN мы пока не можем.

Прописываем строчки кода:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A INPUT -p gre -j ACCEPT iptables -A INPUT -m tcp -p tcp --dport 1723 -j ACCEPT iptables -I INPUT -s 17.255.0.0/32 -i ppp0 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp1 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp1 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp2 -j MASQUERADE Далее добавляем еще один набор: iptables -I INPUT -s 17.255.0.0/32 -i ppp2 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp3 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp3 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp4 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp4 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp5 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp5 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp6 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp6 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp7 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp7 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp8 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp8 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp9 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp09 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp10 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp10 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp11 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp11 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp12 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp12 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp13 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp13 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp14 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp14 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp15 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp15 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp16 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp16 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp17 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp17 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp18 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp18 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp19 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp19 -j ACCEPT iptables --table nat --append POSTROUTING --out-interface ppp20 -j MASQUERADE iptables -I INPUT -s 17.255.0.0/32 -i ppp20 -j ACCEPT iptables --append FORWARD --in-interface eth0 -j ACCEPT

Перезапускаем сервер, чтобы изменения вступили в силу:

service pptpd restart

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

iptables-save > /etc/iptables_rules

Внесем их в автозагрузку:

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

1.17 Как объединить три и более компьютера в сеть или зачем нужны коммутаторы

• 12.06.2018
• Cisco CCNA (ICND1 и ICND2), Компьютерные сети
• 4 комментария

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны на программе Cisco ICND1 и помогут вам подготовиться к экзаменам CCENT/CCNA. В этой теме мы поговорим о том как объединить три или более компьютера в одну сеть, а в процессе этого разговора мы разберемся с вопросом: зачем нужны коммутаторы и какие преимущества они нам дают.

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

1.17.1 Введение

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

Мы наконец-то опять воспользуемся Cisco Packet Tracer и попробуем собрать более сложную и интересную схему с использованием коммутаторов и нескольких компьютеров, обратите внимание: сейчас мы не рассматриваем хабы, они уже морально устарели, также в данной теме на неважно какой перед нами коммутатор: управляемый или неуправляемый, для нас это пока просто коммутатор, а в дальнейшем мы будем работать только с управляемыми коммутаторами.

1.17.2 Вспоминаем схему соединения двух узлов

Давайте вспомним нашу простую компьютерную сеть, в которой было ровно два участника, схема такой сети показана на Рисунке 1.17.1. Напомню, что устройства одного уровня модели OSI 7 при классической схеме включаются витой парой с перекрестным обжимом, на рисунке это показано пунктиром.

Рисунок 1.17.1 Два компьютера, соединенных витой парой

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

Понять факт того, что два устройства находятся в одной подсети можно по комбинации IP-адреса и маски сети, с этим мы разберемся в дальнейшем. Результаты проверки при помощи утилиты пинг говорят нам, что все хорошо: компьютер может взаимодействовать с ноутбуком (Рисунок 1.17.3), а ноутбук с компьютером (Рисунок 1.17.2).

Рисунок 1.17.2 Проверяем соединение от ноутбука к ПК

Пинг проходит, потерь нет, всё здорово.

Рисунок 1.17.3 Проверяем соединение от ПК к ноутбуку

В обратную сторону ситуация аналогичная, все хорошо работает. Давайте посмотрим на физический интерфейс ноутбука и компьютера, то есть на сетевую карту, которая выполняет работу сразу на трех уровнях эталонной модели сетевого взаимодействия или на двух уровнях модели стека протоколов TCP/IP, в Cisco Packet Tracer это сделать можно, достаточно кликнуть два раза левой кнопкой мышки по устройству, находящемуся в рабочей области, а затем в появившемся окне выбрать вкладку Physical.

Ноутбук и доступные для него интерфейсы показан на Рисунке 1.17.4, вкладку Physical я выделил красным прямоугольником, сетевая карта ноутбука выделена зеленым.

Рисунок 1.17.4 Интерфейс физического подключения к сети на ноутбуке

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

Рисунок 1.17.5 Физические интерфейсы сетевой карты на ноутбуке в Cisco Packet Tracer

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

На Рисунке 1.17.6 показана вкладка Physical, но уже для стационарного ПК, выглядит и меняется это все аналогично.

Рисунок 1.17.6 Интерфейс физического подключения к сети на стационарном ПК

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

1.17.3 Что если узлов нужно соединить больше, чем два?

Первое, что приходит на ум – добавить каждому устройству по сетевой карте и соединить эти устройства между собой. Ломовое решение, допустим, на стационарном ПК это бы и получилось, есть сетевые карты с двумя и более разъемами, есть конструктивные решения, которые позволяют нам добавить сетевую карту к ПК, но что делать с ноутбуком, там-то сетевую карту не добавишь. И допустим, нам нужно объединить три ПК между собой, и мы даже нашли ноутбук с двумя сетевыми картами, давайте посмотрим на схему, которая показывает такое соединение на Рисунке 1.17.7.

Рисунок 1.17.7 Соединяем три компьютера между собой

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

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

Третий момент, избыточность соединительных линий, а это тоже дополнительные расходы на монтаж этих самых линий и затем на дальнейшее обслуживание, кабель бесплатно никто прокладывать не будет. Четвертый момент, неэкономное расходование IP-адресов, да сейчас мы используем частные IP-адреса, которых для небольших сетей хватит за глаза, но проблема в том, что в данном случае для соединения трех машин между собой мы использовали три подсети: 192.168.1.(1-255), 192.168.2.(1-255), 192.168.3.(1-255). Но по сути только лишь в первую подсеть мы могли бы включить 253 машины, а включили только две, хотя тут можно было бы использовать и более мелкие подсети, но мы с масками пока не работали и сейчас ничего не будем усложнять.

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

Рисунок 1.17.8 Соединяем четыре компьютера между собой

Итак, для того чтобы соединить четыре компьютера нам потребовалось по три сетевых карты на каждом устройстве, шесть соединительных линий и шесть подсетей, по сути мы сейчас лишились всех тех преимуществ, который дает нам технология Ethernet, но также мы устранили некоторые недостатки этой технологии, об этом обо всем мы поговорим в отдельной части, посвященной технологии Ethernet, сейчас просто обратите внимание на все те неудобства, которые несет схема соединения каждый на каждого, их на самом деле больше, но мы перечислили самые очевидные. Для решения этой проблемы я перечислю вам три способа: использовать схему с общей шиной и коаксиальные Ethernet провода, использовать хаб и использовать коммутатор.

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

1.17.4 Нас спасает коммутатор

Итак, у нас стоит задача объединить четыре компьютера в локальную сеть без лишних трудозатрат, для решения такой или подобной задачи в современных компьютерных сетях используются коммутаторы, на данном этапе нам даже не важно что за коммутатор перед нами: управляемый или простенький неуправляшка. Давайте посмотрим на то, как преобразится наша схема, если мы будем использовать коммутатор. Тут стоит сказать, что с добавлением коммутатора изменится не только топология, но и другие характеристики планируемой компьютерной сети. Давайте сперва добавим коммутатор в проект Cisco Packet Tracer, где найти коммутаторы показано на Рисунке 1.17.9.

Рисунок 1.17.9 Где найти коммутатор в Cisco Packet Tracer

Чтобы добавить коммутатор в проект нужно сперва нажать на иконку, выделенную зеленым, затем желтым, а после этого перетащить в рабочую область красную иконку. Тем самым вы добавите в проект коммутатор Cisco 2960 – это один из самых простых и дешевых управляемых коммутаторов Cisco, который чаще всего используется на уровне доступа в корпоративных сетях, если они построены на базе оборудования Cisco.

Обратите внимание на Рисунок 1.17.10, здесь показаны порты коммутатора Cisco 2960. У данного коммутатора имеется один консольный порты, который используется для первоначальной конфигурации устройства, 24 медный порта с пропускной способностью 100 Мбит/c (про скорость передачи данных можно понять по надписи FastEthernet), обычно эти порты используются для подключения конечных абонентов, а также два гигабитных медных порта, которые чаще всего используются для соединения коммутатора с другими коммутаторами или маршрутизаторами.

Рисунок 1.17.10 Порты коммутатора Cisco 2960

Иногда первых двадцать четыре порта называют access-портами или портами доступа, что не совсем корректно. Да, эти порты чаще всего используются для подключения конечных абонентов, но никто не запрещает вам использовать эти порты для соединения с другими коммутаторами/маршрутизаторами. Два гигабитных порта иногда называют транковыми, поскольку они используются для соединения с другими транзитными устройствами сети, но опять же, эти порты можно использовать и для подключения конечных абонентов, никто этого вам запретить не может. Само логическое состояние порта: транк(trunk) и access мы обсудим и поговорим про настройки, когда начнем разбираться с вланами.

Как выглядит лицевая панель коммутатора Cisco 2960, а также других устройств от Cisco, можно посмотреть в самом Cisco Packet Tracer, достаточно кликнуть дважды на интересующее устройство и в левом верхнем углу появившегося окна выбрать вкладку Physical, появится рисунок устройства, который можно приближать и удалять, лицевая панель нашего коммутатора показана на Рисунке 1.17.11.

Рисунок 1.17.11 Лицевая панель коммутатора Cisco 2960

Теперь давайте объединим наши компьютеры в сеть при помощи коммутатора, обратите внимание на Рисунок 1.17.12. Тут нужно сказать вот о чем: при подключении к порту коммутатора вы не сможете тут же начать передавать данные, главным образом из-за того, что работает протокол защиты от петель STP, который в первичной своей редакции очень медленный, также при подключении коммутатор согласовывает физические и канальные характеристики передачи данных с удаленным устройством, но это уже влияет не так сильно.

Рисунок 1.17.12 Передача данных начнется не сразу, это видно по оранжевой индикации со стороны коммутатора

О том, что передавать данные еще нельзя, говорит нам оранжевая индикация со стороны коммутатора, с появлением зеленой индикации можно начинать передавать данные. На Рисунке 1.17.13 показана та же схема, но здесь коммутатор уже готов к передаче данных.

Рисунок 1.17.13 Коммутатор готов к передаче данных

Об этом нам говорит зеленая индикация с обеих сторон. Также обратите внимание на то, что для конечных устройств я задал IP-адрес и маску подсети, а к настройкам коммутатора я не прикасался вовсе, для работы схемы в данном случае нам это не нужно, сейчас мы можем даже считать, что на коммутаторе нет IP-адреса. Также обратите внимание, если навести курсор мыши на зеленую лампочку и немного его там подержать, появится подсказка в виде портов, в которые включен выбранный кабель, на Рисунке вы можете видеть надписи Fa0 и Fa0/1, эти надписи появились после наведения и говорят о том, что первый компьютер включен в порт коммутатор FastEthernet0/1.

Теперь давайте проверим работоспособность схемы, зайдем на первый ПК и пропингуем с него три других, результаты показаны на Рисунке 1.17.14.

Рисунок 1.17.14 Проверяем работоспособность схемы с коммутатором

Мне следует сделать небольшое примечание уже сейчас: в нашей импровизированной компьютерной сети в качестве транзитного узла используется коммутатор, то есть устройство канального уровня нашей компромиссной модели передачи данных, которую мы выработали, когда разбирались с моделью стека протоколов TCP/IP. А это очень важно, так как это означает, что для передачи данных по нашей сети сетевой уровень не используется вовсе, так как транзитный узел не умеет работать с IP-адресами, то есть, если посмотреть на инкапсуляцию данных в такой сети в процессе их передачи, то мы не увидим заголовков сетевого уровня (IP-протокол просто не используется), если выполнить декомпозицию взаимодействия в сети с коммутаторами, то мы увидим, что для передачи данных из точки А в точку Б будет достаточно только двух уровней: физического и канального.

Как видим, пинг проходит до всех участников сети без потерь, для полной проверки нужно повторить эту манипуляцию со всех устройств, но это уже вы сможете сделать самостоятельно. Сейчас же я хочу вернуть вас к схеме с четырьмя устройствами, соединенными напрямую, там у нас было три сетевых карты на каждом устройстве, шесть соединительных медных линий, а также мы использовали шесть подсетей, в которые можно было включать до 253 устройств. С появлением коммутатора наша жизнь резко изменилась, нам потребовалась одна подсеть, из которой мы заняли четыре IP-адреса по числу устройств (192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4), на каждом конечном устройстве по одной сетевой карте, так как больше и не надо, а для соединения нам потребовалось четыре медных линии типа витая пара, кстати, обратите внимание: конечные устройства соединяются с коммутатором при помощи витой пары с прямой схемой обжима, так как Cisco Packet Tracer считает, что компьютеры находятся на сетевом уровне модели OSI 7, а коммутаторы доступа находятся на канальном уровне эталонной модели.

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

У нашего первого ПК задан IP-адрес 192.168.1.1 с маской 255.255.255.0, это означает, что IP-адреса других компьютеров, которые могут находится в одной подсети или в одном широковещательном домене с первым компьютером, должны начинаться с 192.168.1.x, а вот в качестве «x» может быть любое число от 0 до 255, но дело в том, что IP-адрес 192.168.1.0 – это номер нашей подсети и его нельзя задавать конечным устройствам, также, как и IP-адрес 192.168.1.255, который является широковещательным IP-адресом, если попробовать пропинговать такой адрес, то наш компьютер обратится ко всем узлам, которые находятся с ним в одной подсети, в современных компьютерных сетях широковещательные IP-адреса используются для служебных целей, например, чтобы получить IP-адрес от DHCP-сервера. Хочу сразу заметить, что не стоит обобщать широковещательный трафик с видами сетевого взаимодействия, которых мы говорили, это совсем другая классификация. Обратите внимание на результаты работы команды ping 192.168.1.255 в рамках нашей схемы, он показан в листинге ниже:

[php]
C:\>ping 192.168.1.255

Pinging 192.168.1.255 with 32 bytes of data:

Reply from 192.168.1.3: bytes=32 time Reply from 192.168.1.4: bytes=32 time Reply from 192.168.1.2: bytes=32 time Reply from 192.168.1.2: bytes=32 time Reply from 192.168.1.4: bytes=32 time Reply from 192.168.1.3: bytes=32 time Reply from 192.168.1.2: bytes=32 time Reply from 192.168.1.3: bytes=32 time Reply from 192.168.1.4: bytes=32 time Reply from 192.168.1.2: bytes=32 time Reply from 192.168.1.3: bytes=32 time=1ms TTL=128
Reply from 192.168.1.4: bytes=32 time

Ping statistics for 192.168.1.255:
Packets: Sent = 4, Received = 12, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

В данном случае мы сделали четыре широковещательных запроса и четыре раза нам ответили узлы, находящиеся в одной с нами подсети, этот процесс можно рассмотреть более детально в режиме симуляции Cisco Packet Tracer, как это сделать показано на Рисунке 1.17.15.

Рисунок 1.17.15 Режим симуляции в Cisco Packet Tracer

Сначала нажмите на иконку, выделенную зеленым в правой нижней части, а затем нажмите на кнопку Show All/None, дело в том, что по умолчанию Cisco Packet Tracer показывает пакеты нескольких десятков протоколов в режиме симуляции, нам это будет только мешать, нажатие на эту кнопку говорит Packet Tracer о том, что никакие пакеты показывать вообще не надо, после этого нужно будет нажать на кнопку Edit Filters, у вас должно появиться примерно такое окно как на Рисунке 1.17.16, здесь нужно будет поставить галочку напротив ICMP.

Рисунок 1.17.16 Редактируем фильтры в Cisco Packet Tracer

Утилиты ping и tacert как раз-таки и используют протокол ICMP для своих задач, об этом протоколе мы поговорим чуть позже, когда будет разговор об IP протоколе, также обратите внимание, что есть еще утилита traceroute, которая не тоже самое, что и tracert, traceroute использует для диагностики UDP дейтаграммы.

Давайте попробуем пропинговать широковещательный IP-адрес в режиме симуляции, результат показан на Рисунке 1.17.17.

Рисунок 1.17.17 Пингуем широковещательный IP-адрес в режиме симуляции

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

Рисунок 1.17.18 Первоначальное состояние схемы в Cisco Packet Tracer

Здесь показано состояние нашей компьютерной сети сразу после того, как мы выполнили команду ping 192.168.1.255. Также обратите внимание на то, что возле первого ПК появился фиолетовый пакет, это означает, что наш компьютер сформировал пакет, но пока его еще не отправил, чтобы он отправил этот пакет, да и вообще, чтобы посмотреть что будет дальше, нужно нажимать на кнопку «Capture/Forward» в правой части окна Cisco Packet Tracer, чтобы вернуться на шаг назад нужно нажать на кнопку «Back».

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

Рисунок 1.17.19 Пакет с ICMP вложением дошел до коммутатора

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

Рисунок 1.17.20 Коммутатор разослал пакет ICMP всем участникам широковещательного домена

На следующем Рисунке показан следующий шаг: 2, 3, 4 компьютеры ответили первому на его ICMP запрос и кадры с ICMP вложением дошли до коммутатора, состояние командной строки первого ПК на данном шаге никак не меняется, поэтому я его не показываю, наш ПК до сих пор не получил ответ на свой запрос.

Рисунок 1.17.21 Три компьютера послали свои ответы на коммутатор

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

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

Рисунок 1.17.23 Компьютер ПК1 получил ICMP-ответы от всех участников своей подсети

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

1.17.5 А что если IP-адреса узлов будут из разных подсетей?

Мы убедились, что коммутатор – это очень удобная штука, которая может сэкономить нам деньги и время, а также избавить сетевого инженера от множества проблем, связанных с обслуживанием сети, управляемые коммутаторы еще и упрощают диагностику неполадок на сети и их (управляемые коммутаторы) можно мониторить при помощи специальных приложений. Но давайте попробуем провести еще один эксперимент. В первом случае все узлы нашей сети имели IP-адреса из одной подсети, то есть находились в одном широковещательном домене, давайте подключим к нашему коммутатору еще два узла, которые будут находиться в другой подсети, скажем 192.168.2.25 и 192.168.2.120, у обоих будет маска 255.255.255.0. Новая схема показана на следующем рисунке.

Рисунок 1.17.24 Узлы из разных подсетей подключены к одному коммутатору

Таким образом получается, что ноутбуки у нас находятся в подсети 192.168.2.х, а стационарные ПК находятся в подсети 192.168.1.х. Давайте попробуем с ноутбука .25 пропинговать другой ноутбук, сделать широковещательный запрос и пропинговать первый стационарный компьютер. Результат показан в листинге ниже:

[php]
Packet Tracer PC Command Line 1.0
C:\>ping 192.168.2.120

Pinging 192.168.2.120 with 32 bytes of data:

Reply from 192.168.2.120: bytes=32 time=8ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128

Ping statistics for 192.168.2.120:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 8ms, Average = 5ms

Pinging 192.168.2.255 with 32 bytes of data:

Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128

Ping statistics for 192.168.2.255:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 4ms, Average = 4ms

Pinging 192.168.1.1 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Сначала мы пинговали ноутбук, который находится с нами в одной подсети, на наши запросы мы получили четыре ответа, затем мы сделали широковещательный запрос (ping 192.168.2.255), логично, что ответ мы получили только от узла с IP-адресом 192.168.2.120, так как все остальные узлы находятся в другом широковещательном домене/канальной среде/подсети и классический L2 коммутатор никак не сможет нам помочь попасть из одной подсети в другую, он просто не умеет этого делать, зато у классического L2 коммутатора есть такая технология как VLAN, которая позволяет еще более надежно изолировать одну подсеть от другой.

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

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

1.17.5 Выводы

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

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

В любом случае все необходимые термины и слова вы запомните, читая различные статьи в Интернете и книги, а также самостоятельно практикуясь, при этом процесс запоминания лучше происходит во время практики, поэтому запомните вы именно то, что вам будет необходимо для работы, а для всего остального у вас есть Яндекс и Google, понимая принципы работы и зная назначения технологии или протокола, найти нужное решение, инструкцию или подсказку в Интернете не составит труда.

Еще записи о создании сайтов и их продвижении, базах данных, IT-технология и сетевых протоколах

• 1.19 Как объединить две подсети в сеть или зачем нужны маршрутизаторы и основной шлюз? Пример настройки домашнего роутера
• 1.18 Коаксиальный Ethernet кабель, сеть с топологией общая шина или зачем нужны хабы и сетевые концентраторы
• 9.1 Зачем нужен протокол DHCP? Что такое DHCP опции (DHCP options) и зачем они нужны?
• 4.9 Виды устройств в IP-сетях: конечные узлы, маршрутизаторы и их функции. Сколько IP-адресов может быть у компьютера
• 1.7 Условные обозначения Cisco и стандартные физические компоненты компьютерной сети или что такое компьютерная сеть?
• Команда tracert в Windows. Зачем нужна и как пользоваться сетевой утилитой tracert?
• Часть 1: Введение. Основы взаимодействия в компьютерных сетях
• Часть 9. Динамическая конфигурация узлов и протокол DHCP (Dynamic Host Configuration Protocol)

Возможно, эти записи вам покажутся интересными

Related Posts

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны…

Привет, посетитель сайта ZametkiNaPolyah.ru! Эта запись для рекламодателей, пропустите ее, если вы не заинтересованы в…

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей. В девятой части мы с…

Выберете удобный для себя способ, чтобы оставить комментарий

This article has 4 comments

Дима 10.07.2018 Reply

А подскажи, пожалуйста, чем отличаются управляемые сетевые коммутатора от неуправляемых коммутаторов. И в чем разница между свичом или свитчем и коммутаторами, а то этот момент для меня не совсем понятен. Неуправляемый коммутатор это тоже что и сетевой концентратор или как?

Кирилл 10.07.2018 Reply

Привет! Свич и коммутатор — это одно и то же, просто разные слова. Разница между управляемым сетевым коммутатором и неуправляемым действительно есть. Неуправляемый коммутатор ты достаешь из коробки, ставишь себе на сеть и он будет работать так, как его настроил производитель, никаких изменений и конфигураций на нем ты сделать не сможешь. Еще стоит добавить, что у управляемых коммутаторов обычно гораздо больше всяких плюшек и дополнительных технологий, которые ты можешь настраивать включать и отключать. Если интересно, зайди на сайт, например, D-Link, найди там описание и характеристики неуправляемого коммутатора, а затем сравни их с характеристиками управляемого. Пример неуправляемого коммутатора: D-link DES1008D, пример управляемого свича: D-Link DES 3200. Что касается хабов и неуправляемых свичей — это разные вещи, хаб — это устройство физического уровня, оно ничего не знает о Ethernet кадрах и MAC-адресах и по сути не имеет программной логики, неуправляемый коммутатор в курсе, что есть кадры и мак-адреса и умеет с ними работать. У него есть своя небольшая таблица мак-адресов. Такая путаница происходит по одной простой причине: многие называют неуправляемый коммутатор хабом, хоть он им и не является, настоящие хабы ты уже вряд ли найдешь в магазинах.

Мурзик 10.07.2018 Reply

А почему вместо сетевого коммутатора нельзя использовать сервер с несколькими сетевыми картами или сетевой картой с несколькими портами?

Кирилл 10.07.2018 Reply

А кто сказал, что нельзя? Можно и иногда так и делают, например, сервер подключают к интернету, а затем он раздает этот интернет на устройства офисной сети. Но сервер не всегда удобно использовать, сам сервер обойдется, скорее всего, дороже. Плюс надо учитывать, что коммутаторы и роутеры — это по сути тоже компьютеры, только вот железо этих компьютеров заточено на обработку Ethernet кадров и IP-пакетов. Вообще, всё зависит от инженера, который занимается планированием сети, задач и бюджета, выделенного на эту сеть, иногда действительно может оказаться так, что сервер выгоднее поставить, чем связку роутер + сетевой коммутатор или L3 коммутатор. В общем, всё индивидуально.