какие протоколы используются для подключения к linux серверам
Хотя UUCP, может быть, и разумный выбор для дешевых сетей связи по телефону, существует большое количество ситуаций, в которых техника «сохранил-передал» оказывается слишком не гибкой, например, в локальных сетях (LAN). Они обычно состоят из небольшого числа машин, расположенных в одном здании или даже на одном этаже, которые связаны для создания однородной рабочей среды. Вы хотели бы разбросать файлы между этими хостами или запускать одно приложение на различных машинах. Эти задачи требуют совершенно другого подхода к организации сети. Вместо отправления полных файлов наряду с описанием работы, все данные разбиваются на маленькие пакеты, которые немедленно отправляются нужному хосту, где они повторно собираются. Этот тип сети называется пакетной ( packet-switching) сетью. Среди прочего, это позволяет запускать по сети диалоговые приложения. Цена этого, конечно, резкое увеличение сложности программного обеспечения.
Решение, которое приняли Unix-системы и большинство не-Unix сайтов, известно как TCP/IP. В этом разделе мы будем рассматривать его концепции.
Введение в сети TCP/IP
TCP/IP происходит от проекта, финансируемого американским DARPA (Defense Advanced Research Projects Agency) в 1969. Это была экспериментальная сеть ARPANET, которая была преобразована в эксплуатационную в 1975 после того, как была доказана ее полезность.
В 1983 новый протокол TCP/IP был принят как стандарт и от всех хостов в сети требовалось его использование. Когда ARPANET, наконец, вырос в Inetrnet (ARPANET непосредственно окончил свое существования в 1990), использование TCP/IP распространилось и на сети вне Inetrnet. Наиболее известны локальные сети Unix, но из-за появлении быстрого цифрового телефонного оборудования, типа ISDN, он также имеет большой шанс стать протоколом транспортировки для телефонных сетей.
Для более конкретного рассмотрения TCP/IP повсюду в следующих разделах мы будем пользоваться как примером университетом Groucho Marx (GMU), большинство его отделов используют собственную локальную сеть, а другие используют несколько таких сетей. Они все связаны и подключены к Inetrnet через единственную быстродействующую линию.
Если Вы теперь запускаете приложение, оно будет входить в контакт с Вашим X-сервером вместо quark и отображать все окна на Вашем экране. Конечно, это требует наличия у вас X11. TCP/IP позволяет quark и erdos посылать X11-пакеты туда и обратно, создавая иллюзию, что Вы находитесь на удаленной системе. Сеть здесь почти прозрачна.
Другое очень важное приложение в сетях TCP/IP: NFS (сетевая файловая система, Network File System). Это другая форма создания прозрачной сети, она позволяет монтировать каталоги с других хостов так, чтобы они рассматривались подобно локальным файловым системам. Например, домашние каталоги всех пользователей могут быть на центральной машине, с которой все другие хосты в локальной сети монтируют требуемые каталоги. В результате пользователи могут войти в сеть с любой машины и находиться в том же самом домашнем каталоге. NFS подрпобно рассмотрена в главе 14.
Конечно, это не единственные примеры того, что Вы можете делать в сетях TCP/IP. Ваши возможности почти безграничны.
Теперь мы поближе познакомимся с работой TCP/IP. Вы будете нуждаться в этом, чтобы понять, как и почему Вы должны конфигурировать свою машину. Мы начнем с исследования аппаратных средств.
Ethernet
Среди сетевых аппаратных средств наиболее широко используется повсюду в локальных сетях Ethernet. Он состоит из единственного кабеля с хостами. Скорость передачи зависит от типа Ethernet и составляет 10, 100 или около 1000 мегабит в секунду.
Ethernets бывает трех типов: толстый (thick), тонкий (thin) и витая пара (twisted pair). Тонкий и толстый Ethernet использует коаксиальный кабель, отличающейся толщиной (отсюда и название) и способом подключения машины к кабелю. Тонкий Ethernet использует BNC-коннектор в форме буквы Т, в который Вы вставляете кабель и вкручиваете сзади компьютера в гнездо сетевой платы. Толстый Ethernet требует, чтобы Вы проделали маленькую дырочку в кабеле и воткнули коннектор «методом вампира» (vampire tap). Один или больше хостов может быть присоединено к одному такому коннектору. Тонкий и толстый кабель Ethernet может иметь длину не больше 200 и 500 метров соответственно, поэтому они также названы 10base-2 и 10base-5. Витая пара использует кабель, сделанный из медных проводов, но обычно требует дополнительных аппаратных средств (активных концентраторов, active hubs). Он также известен как 10base-T. Здесь «base» является сокращением от «baseband modulation», это значит, что данные непосредственно поданы на кабель без каких-либо модемов и других подобных устройств. Число в начале показывает скорость в мегабитах в секунду, число в конце показывает максимальную длину кабеля. «T» обозначает витую пару. Витая пара на 100 мегабит в секунду обозначается как «100base-T».
Добавление хоста к толстому Ethernet не слишком сложно, оно даже не разрушает временно сеть. Чтобы добавить машину к сети с тонким Ethernet Вы должны прервать работу сети по крайней мере на несколько минут потому, что надо разрезать кабель, чтобы вставить Т-connector. Витая пара в этом плане очень удобна: в ней используется концентратор (hub), который является точкой обмена данными. Машина может быть подключена к нему или отключена от него независимо от работы других машин в сети.
Один из недостатков Ethernet: ограниченная длина кабеля, который позволяет использовать его только для локальных сетей. Однако, несколько сегментов Ethernet могут быть связаны друг с другом с помощью повторителей (repeaters), мостов (bridges) или маршрутизаторов (routers). Повторители просто копируют сигналы между двумя или больше сегментами так, что все сегменты вместе действуют, как будто это один Ethernet. Но между двумя любыми машинами сети не может быть больше четырех повторителей, иначе они исказят сигнал. Мосты и маршрутизаторы более сложные. Они анализируют поступающие данные и отправляют их только тогда, когда хоста получателя нет в местном сегменте Ethernet.
Структура, посланная одной машиной, видна и всем остальным, но только хост места назначения подбирает и обрабатывает ее. Если две машины пробуют послать сообщение одновременно, происходит столкновение ( collision), которое решается двумя машинами с помощью остановки передачи и повторной попытки передачи данных несколько позже. Число столкновений доходит до 30% от пропускной способности сети, но при сильной нагрузке, этот показатель будет расти. Это нормально. Беспокоиться стоит начинать, когда он достигнет 60%. Тут может сильно помочь витая пара: в ней пакеты идут по двум разным проводам и поэтому не сталкиваются. Именно поэтому, все крупные сети делают на витой паре.
Другие типы оборудования
В больших сооружениях, типа университета Groucho Marx, Ethernet обычно не единственный тип используемого оборудования. В Groucho Marx локальная сеть каждого отдела связана с университетской магистралью, которая является оптическим кабелем FDDI ( Fiber Distributed Data Interface ). FDDI использует совершенно другой подход к передаче данных, который основывается на рассылке определенных маркеров ( tokens ) и только, если машина получает этот маркер, она может послать некий блок (один или несколько пакетов) информации. Главное преимущество FDDI скорость, достигающая 100 Mbps, и максимальная длина кабеля до 200 км. Кроме того, там нет столкновений пакетов из-за того, что сеть основана на передаче маркера.
Если Вы работаете с аппаратурой IBM, часто придется иметь дело с сетью IBM Token Ring. Token Ring является альтернативой Ethernet в LAN и использует решения, аналогичные применяемым в FDDI, но на низкой скорости (4 Mbps или 16 Mbps). В Linux Token Ring настраивается аналогично Ethernet, так что я не буду рассматривать его отдельно. Раньше за право быть наиболее распространенным стандартом бились Ethernet и Token Ring. В конце концов победил Ethernet, но стандарты по своим возможностям находятся примерно на одном уровне.
Есть и совершенно другие сетевые технологии, например, ArcNet и DECNet. Linux поддерживает и их, но из-за малой популярности, я не буду говорить о них в этой работе.
Многие сетевые операторы предлагают пакетные протоколы передачи. Вероятно, наиболее популярный из них стандарт X.25. Многие публичные сети подобно Tymnet в США, Austpac в Австралии и Datex-P в Германии предлагают это обслуживание. X.25 определяет собственный набор протоколов, но часто используется, чтобы соединить сети, работающие под TCP/IP и другими протоколами. Так как IP-пакеты не могут быть прямо отображены на X.25 (и наоборот), они просто вставляются в X.25-пакеты и посылаются по сети. X.25 требует синхронной связи и, следовательно, специальные синхронные аппаратные средства последовательного порта. Можно использовать X.25 с нормальными последовательными портами, если Вы используете специальное устройство PAD (Packet Assembler Disassembler). PAD автономное устройство. Оно обеспечивает асинхронные и синхронные последовательные порты. Это управляет протоколом X.25 так, чтобы простые устройства терминала могли создавать и принимать X.25-подключения. Имеется экспериментальная реализация протокола X.25 для Linux.
Более современный протокол называется Frame Relay. Frame Relay совместно использует ряд технических свойств с X.25, но гораздо больше похож в поведении на IP. Подобно X.25 Frame Relay требует специальных синхронных последовательных аппаратных средств. Из-за их сходства много плат поддерживают оба эти протокола. Доступен вариант, который не требует никаких специальных внутренних аппаратных средств. Это Frame Relay Access Device (FRAD), который формирует пакеты Frame Relay из пакетов Ethernet для передачи по сети. Frame Relay идеально подходит для переноса TCP/IP между сайтами. Linux обеспечивает драйверы многих внутренних устройств Frame Relay.
Если Вы нуждаетесь в работе с высокоскоростной сетью, Вас должен заинтересовать ATM (Asynchronous Transfer Mode). ATM является новой сетевой технологией, специально созданной для того, чтобы обеспечить управляемый, быстрый, с низким временем ожидания обмен данными. Она обеспечивает контроль над качеством обслуживание (QoS). Много компаний создают сети ATM, потому что это позволяет свести много услуг на одну платформу. ATM часто используется для передачи TCP/IP. Networking-HOWTO предлагает информацию относительно поддержки ATM в Linux.
Часто радиолюбители используют свое оборудование для создания сети из своих компьютеров. Это называется пакетное радио ( packet radio) или ham-радио. Протокол, используемый ham-радио, назван AX.25 (он получен из X.25). Он также используется для передачи TCP/IP и других протоколов. AX.25 подобно X.25 требует последовательных аппаратных средств, способных к синхронному действию, или внешнее устройство Terminal Node Controller, чтобы преобразовать пакеты. Есть немало плат с поддержкой этого протокола, они имеют общее название «Z8530 SCC based» (по имени наиболее популярного контроллера связи, используемого в проектах). Есть два протокола, которые работают поверх AX.25: NetRom и Rose, являющиеся протоколами сетевого уровня. Linux поддерживает полные реализации AX.25, NetRom и Rose. AX25-HOWTO является хорошим источником информации по использованию этих протоколов в Linux.
Есть методы, которые используют специально для медленных, но дешевых телефонных линий. Они требуют других протоколов для передачи пакетов типа SLIP или PPP, которые будут описаны ниже.
Internet Protocol
Конечно, Вы не хотели бы, чтобы Ваша сеть ограничивалась только Ethernet. В идеале хотелось бы использовать сеть независимо от того, какими аппаратными средствами это достигается. Например, в больших сооружениях (Groucho Marx) Вы обычно имеете набор отдельных Ethernet, которые должны быть связаны некоторым образом. В GMU в математическом отделе используются два Ethernet: одна сеть быстрых машин для профессоров и студентов последних курсов и другая с медленными машинами для студентов (обе связаны с FDDI).
Эта схема направления данных удаленному хосту называется маршрутизацией ( routing), а пакеты часто называют дэйтаграммами ( datagrams). Для простоты обмен дэйтаграммами управляется в соответствии c отдельным протоколом, который является независимым от используемых аппаратных средств: IP или Internet Protocol. В главе 2 мы будем рассматривать IP и routing более подробно.
Основное преимущество IP в том, что он преобразует физически несовместимые сети в одну с виду однородную сеть. Это называется internetworking, в результате получаем «метасеть» называемую internet. Обратите внимание на различие между inetrnet и Internet! Последнее является официальным названием одного специфического глобального inetrnet.
Мы не будем здесь вдаваться в подробности этого процесса, а сделаем это в главе 2. Пока достаточно помнить, что эти шаги называются hostname resolution, поиск IP-адреса по имени хоста, и address resolution, поиск физического адреса по IP.
IP на последовательных линиях
Здесь стандартом является SLIP ( Serial Line IP) или IP для последовательных линий. Есть модификация CSLIP (сжатый SLIP, Compressed SLIP), который использует сжатие IP-заголовков, чтобы оптимизировать IP для относительно низкой пропускной способности последовательной связи. PPP или протокол Point-to-Point Protocol еще один протокол для последовательных линий. PPP имеет большее число возможностей, чем SLIP, включая стадии переговоров о начале связи. Его главное преимущество по сравнению со SLIP в том, что он не ограничивается только транспортировкой IP-пакетов, а предназначен для передачи любого типа дэйтаграм.
Transmission Control Protocol
Это происходит в соответствии c другим протоколом, TCP ( Transmission Control Protocol), который надстраивается над IP для создания связи с проверкой целостности данных. Существенный плюс TCP то, что он использует IP. Это создает иллюзию простой связи между двумя процессами на Вашем хосте и отдаленной машине так, что Вы не заботитесь о том, как и по какому маршруту Ваши данные фактически путешествуют. A TCP создает дуплексную связь, позволяющую одновременно как посылать, так и получать информацию.
В TCP точки связи определяются IP-адресами хостов и номерами так называемых портов ( port) на каждом из хостов. Порты служат для определения процесса, с которым устанавливается связь. Если обратится к примеру с номерами телефонов, то IP-адрес соответствует кодам городов, а номер порта местному номеру телефона.
User Datagram Protocol
Конечно, TCP не единственный протокол пользователя в сетях TCP/IP. Хоть он и подходит для приложений подобных rlogin, но он излишне надежен и не нужен для приложений типа NFS. Вместо него в них использует UDP ( User Datagram Protocol). Подобно TCP, UDP также позволяет приложению-клиенту войти в контакт с сервером, обслуживающим определенный порт на удаленной машине, но он не устанавливает связь для этого. Вместо этого Вы можете использовать его, чтобы посылать отдельные пакеты к месту назначения.
Предположим, что Вы смонтировали директорию TeX с центрального NFS-сервера galois и хотите просмотреть документ, описывающий, как использовать LaTeX. Вы запускаете редактор, который сначала читает указанный файл. Однако, требуется слишком много времени, чтобы установить TCP-связь с galois, послать файл и повторять это снова. Вместо этого на запрос, посланный к galois, тот посылает файл в паре UDP-пакетов, что происходит гораздо быстрее. Однако, UDP не приспособлен для борьбы с потерей пакетов. Этим приходится заниматься NFS.
Еще о портах
Порты могут рассматриваться как точки присоединения сетевых связей. Если приложение (сервер) хочет предложить некий сетевой сервис, оно ассоциирует себя с портом и ждет клиентов (это называется слушать порт). Клиент, который хочет использовать этот сервис, получает порт на местном хосте и соединяется с портом сервера на удаленном хосте.
Стоит заметить, что хотя TCP и UDP полагаются на порты, эти номера не находятся в противоречии. Это означает, что TCP порт 513, например, отличается от UDP порта 513. Фактически, эти порты служат как точки доступа для двух различных услуг, а именно, rlogin (TCP) и rwho (UDP).
Библиотека сокетов
Ведутся работы по добавлению сокетов и для других протоколов.
Как подключиться к Linux из Windows
В мире ИТ существует уже довольно широкий спектр операционных систем, начиная с серверных, заканчивая операционными системами для мобильных устройств. В обычных пользовательских компьютерах и в серверах довольно часто используются две ОС — Linux и Windows. Поэтому очень часто возникают ситуации, когда приходится подключаться по сети из одной операционной системы к другой для выполнения разнообразных операций.
В этой статье мы рассмотрим варианты подключения к Linux из Windows. Существуют бесплатные и условно бесплатные утилиты вроде AnyDesk или TeamViewer, но установка их довольно тривиальна и не нуждается в дополнительном пояснении. Утилиты подобного рода обладают рядом ограничений при бесплатном некоммерческом использовании, либо их функциональность не удовлетворяет тем или иным потребностям пользователя. Мы рассмотрим полностью бесплатные способы как подключится к Linux из Windows.
Удалённый доступ к Linux с помощью VNC
На сегодняшний день самое популярное удаленное подключение к Linux из Windows, с использованием привычный в Windows графического интерфейса, является VNC (Virtual Network Computing) — утилита, использующая протокол RFB (Remote FrameBuffer — удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть.
В качестве сервера VNC в данном примере будет использоваться TightVNC, установленный в Ubuntu 20.04. Для установки сервера VNC необходимо выполнить ряд действий:
Шаг 1. Установка рабочей среды XFCE
Xfce — одна из самых легковесных рабочих сред, используемых в Linux, она будет быстро работать даже при слабом и нестабильном сетевом подключении. Установите её с помощью команд:
sudo apt install xfce4 xfce4-goodies
Шаг 2. Установка TightVNC
Далее установите TightVNC:
sudo apt install tightvncserver
Шаг 3. Настройка пароля
Перед началом выполнения всех действий необходимо задать пароль пользователя VNC. Выполните команду:
Вам будет предложено создать новый пароль, а также пароль только для просмотра. Откажитесь от второй опции:

Завершите процесс vncserver:
Шаг 4. Настройка скрипта запуска
Отредактируйте скрипт, который выполняется после запуска VNC-сервера:
Он должен содержать такой текст:
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
startxfce4 &
Сделайте файл исполняемым:
Шаг 5. Запуск VNC сервера
На этом этапе уже можно запустить VNC-сервер с помощью команды:
Шаг 6. Подключение из Windows
Для того, чтобы подключиться из Windows к вашему Linux-серверу, используйте TightVNC Viewer.
Укажите IP-адрес компьютера, к которому нужно подключиться, и номер порта в поле Remote Host. В данном примере — 192.168.56.102::5901:

После того, как будет введён пароль, вы должны увидеть рабочий стол Xfce:

Шаг 8. Настройка systemd
Для того, чтобы запуск вашего VNC-сервера добавить в автозагрузку надо использовать systemd. Создайте новый файл сервиса systemd:
sudo nano /etc/systemd/system/vncserver@.service
Его содержимое должно быть следующим:
Измените имя пользователя ubuntu и рабочего каталога ubuntu на нужные вам значения. Если у вас запущен VNC-сервер, остановите его:
Сообщите systemd о появлении нового сервиса:
sudo systemctl daemon-reload
Добавьте запуск вашего нового сервиса в список автозагрузки:
sudo systemctl enable vncserver@1.service
sudo systemctl start vncserver@1
Использование RDP для удалённого подключения
Помимо VNC, для управления Linux-сервером из Windows можно воспользоваться RDP (Remote Desktop Protocol). Для этого на компьютере с Ubuntu 20.04 установите утилиту xrdp:
sudo apt install xrdp
Для корректной работы сервиса необходимо добавить пользователя xrdp в группу ssl-cert:
sudo adduser xrdp ssl-cert
sudo apt-get install xfce4
Добавьте Xfce в сессии RDP в качестве рабочего стола по умолчанию:
Перезапустите сервис xrdp:
sudo systemctl restart xrdp.service
Процедура подключения из Windows к Linux-серверу по протоколу RDP почти ничем не отличается от подключения к удалённым Windows-серверам. Введите IP-адрес сервера, логин и пароль пользователя в Linux:

Если всё сделано правильно, вы увидите рабочий стол Xfce:

Подключение к Linux из Windows по SSH
Для подключения к компьютеру под управлением Linux по протоколу SSH из Windows можно воспользоваться PowerShell. Сначала становите OpenSSH Client, если ещё не установлен. Запустите на вашем компьютере PowerShell от имени администратора системы и выполните следующую команду:

Это необходимо для того, чтобы узнать текущую версию SSH-клиента. В данном примере доступна версия OpenSSH.Client-0.0.1.0. Установите OpenSSH.Client с помощью команды:

Для того, чтобы подключиться к устройству, на котором запущен SSH-сервер, необходимо ввести имя пользователя и IP-адрес. Команда для подключения по SSH используя PowerShell выглядит так:
Здесь ubuntu — имя пользователя на удалённом компьютере, а 192.168.56.1 — IP-адрес Linux-сервера, на котором запущен демон SSH.
При первом подключении необходимо подтвердить использование специального персонального ключа для шифрованного соединения по SSH-протоколу (введите слово Yes), затем введите пароль пользователя (в данном случае для пользователя ubuntu):

Как видите, соединение прошло успешно. Теперь можно выполнять все команды так же, как если бы вы их выполняли используя стандартный Linux SSH-клиент:

Для завершения терминальной сессии на удалённом компьютере введите команду exit. Теперь вы знаете как выполняется подключение к Linux из Windows по SSH.
Использование Putty для подключения к Linux
Пожалуй, одним из самых популярных способов подключения к Linux из Windows является кроссплатформенная утилита Putty — небольшая по размерам, но очень часто незаменима для подключения по таким протоколам как SSH, Telnet, rlogin и даже с помощью последовательных портов.
Для обычного подключения к Linux-серверу по протоколу SSH достаточно в поле Host Name (or IP—address) указать его IP-адрес и нажать кнопку Open (в данном примере Linux-сервер имеет IP-адрес: 192.168.56.102):

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

Далее нужно будет ввести логин и пароль. Если всё сделано правильно, запустится удалённая сессия терминала Linux:

Мало кто знает, что Putty позволяет запустить почти любое приложение, установленное на компьютере с Linux, по сети в Windows. Для этого на компьютере с Windows нужно установить собственный X-сервер. В данном примере воспользуемся Xming.
Скачайте Xming с официального сайта. Установка довольно тривиальная, поэтому не будем на ней останавливаться. Ничего не меняйте в процессе установки. Просто нажимайте кнопку Next до тех пор, пока программа не установится и не запустится:


В открывшемся терминале Putty введите консольное название программы, обладающей графическим интерфейсом. В данном примере введено название графического редактора drawing:
(Знак & позволит запустить программу в фоновом режиме, в этом случае в окне Putty можно будет выполнять и другие команды):

Как видите, Linux-приложение drawing успешно запустилось по сети на X-сервере, установленном в Windows. С ним можно работать так же, как и с локальным приложением.
Выводы
Сегодня не существует слишком уж больших проблем для подключения к Linux из Windows. Способов существует довольно много. Каждый из них обладает своими достоинствами и недостатками, например, скорость работы VNC, да и других тоже, существенно зависит от скорости сетевого соединения. Существуют также программные средства, позволяющие подключаться к Linux-серверам используя мессенджеры или браузеры.
Страх и ненависть в RouterOS: что такое сетевое соединение в ядре Linux (часть 1 — теория)

В статье рассмотрено понятие «соединение» для TCP и UDP протоколов в ядре операционной системы Linux на примере работы оборудования MikroTik. Дополнительно рассматриваются особенности работы технологии NAT в указанном контексте. Материалы носят в основном теоретический характер и предназначены для людей, тонко настраивающих Firewall, Qos и маршрутизацию, где им придётся непосредственно работать с рассматриваемыми connections.
В этой части статьи подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В практической части закрепим информацию в результате рассмотрения работы прикладного протокола DNS через подсистемы RouterOS. В заключительной части речь пойдёт о диаграмме потока пакетов, при работе с которой важно понимать сущность рассматриваемого сетевого соединения, а также о не документированной в явном виде особенности работы NAT. Материала достаточно много, и чтобы читатель не потерял смысловую нить к концу статьи, она разделена на 3 части: теория, практика и особенность NAT.
Начнём с того, что разграничим сетевое соединение в ядре операционной системы маршрутизатора и реально существующее клиент-серверное соединение, передающееся насквозь через него. То, соединение, о котором речь пойдёт в статье, существует только в контексте роутера, ровно также, как маркировка трафика. RouterOS построена на базе операционной системы Linux и поэтому имеет высокое сходство с ней. Подсистема обработки сетевых пакетов на оборудовании MikroTik унаследована от ядра Linux (постулат подтверждён обращением в компанию, номер обращения SUP-65046). Это может быть одним из аргументов в сторону изучения работы RouterOS, так как полученные знания легко адаптивны под работу непосредственно с Linux. Так, совсем недавно на Хабре была опубликована статья, посвящённая маршрутизации, в которой достаточно ясно прослеживается указанная взаимосвязь. Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik.
Оставим лирическое отступление и вернёмся к предмету разговора. На оборудовании MikroTik, сетевые соединения в Firewall можно увидеть так:
В Winbox это будет выглядеть более наглядно, однако окно дополнительной информации не содержит:

Показанный инструмент называется Connection tracking. Он визуализирует сетевые соединения, однако существует теоретический риск, что соединение может существовать и быть не отражено в нём, вследствие короткого времени существования. На самом деле это не так, и далее я представлю объяснение. Именно с этими соединениями и работают правила «золотого сечения», с которых всегда начинается классическая настройка Firewall на MikroTik:
Они обеспечивают прохождение пакетов уже установленных соединений, а также связанных с ними, минуя нижестоящие правила Firewall, чем высвобождают ресурсы центрального процессора маршрутизатора. Подробнее, какие соединения являются new, established, related, untracked и invalid можно почитать в официальной документации. Ещё раз повторю, что они не равны в полной мере существующим сетевым соединениям, проходящим через роутер. Интуитивно это можно объяснить и так, что маршрутизатор ведь ничего не знает о содержании передающихся через него пакетов, он не устанавливает эти соединения, не проходит процедуры рукопожатий и т.д. Его дело их пропускать далее по сети. Это очень грубо и не отражает суть понятия сетевое соединение глазами маршрутизатора. Объясню на примере работы транспортных протоколов TCP и UDP.
Начнём по порядку. Каждое реально существующее TCP соединение имеет уникальный (случайный) Sequence number, который генерируется после трёхстороннего handshakes:

Можно было бы предположить, что каждый Sequence number является уникальным соединением в операционной системе маршрутизатора. Теперь взглянем на заголовок UDP протокола, в котором никакого номера соединения вообще нет:

Однако в роутере существуют и TCP и UDP соединения. Для объяснения происходящего воспользуемся методом аналогии. Откроем в Wireshark дамп обычного сетевого трафика и посмотрим, что содержат заголовки реально существующих пакетов, а не серые картинки с RFC:

Слева представлен заголовок для TCP пакета, справа для UDP пакета. Sequence number уже знакомый параметр, а вот описание Stream index ранее мы не встречали. И как не сложно догадаться, их нет в протоколах. На самом деле Stream index – это параметр, введённый в отображение заголовков пакетов непосредственно программой Wireshark, для удобства работы с трафиком. Он присваивается каждой паре сокетов, начиная с единицы, и инкрементально увеличивается отдельно для каждого типа протоколов. Здесь появляется новый термин – сокет. Под ним понимается совокупность пар: IP адрес отправителя и номер порта отправителя, а также IP адрес получателя и номера порта получателя. Если вы выполните экспорт только конкретных выбранных (выделенных) пакетов из дампа, то, открыв их, обнаружите, что Stream index будет пересчитан заново, начиная с единицы. Когда выбирается меню Follow -> TCP Stream, то как раз Wireshark и отобразит пакеты, имеющие одинаковое значение Stream index.

Примерно такой же механизм реализован в ядре операционной системы маршрутизатора. Однако в Connection tracking увидеть параметр, аналогичный Stream index в Wireshark, не получится:

Далее по тексту статей я буду нарочно использовать термин Stream index применительно к MikroTik, хотя это и не корректно. Получается, что ядро операционной системы маршрутизатора работает с набором виртуальных сокетов. Встаёт вопрос, каково время их жизни? RouterOS позволяет легко управлять этими параметрами, однако не рекомендую менять их значения по умолчанию, если вы не до конца понимаете, с чем развлекаетесь работаете:
Ранее по тексту было опровергнуто утверждение, что теоретически некоторые соединения могут быть не отражены в Connection tracking. Как видно выше, значения по умолчанию задают достаточно длинные таймауты, что гарантирует визуализацию всех сетевых соединений, даже случайно пролетающих через маршрутизатор. В результате DOS атаки можно попытаться наоткрывать пустых соединений. Все они попадут в Connection tracking.
▍ Заключение
Теоретический материал подошёл к концу. Представленной информации должно хватить для того, чтобы у знакомого с темой читателя сложилось понимание, что такое сетевое соединение в роутере MikroTik, а также других устройствах, работающих под управлением операционной системе, в основу которой положен Linux. Внутри RouterOS понятие сетевое соединение не идентично клиент-серверному соединению, что необходимо для её работы с пакетами. Это важно понимать и знать, ведь работа с этими соединениями не ограничивается только Firewall-ом, но также присутствует в приоритизации трафика (Qos) и маршрутизации. Защита маршрутизатора от DOS атак на L3 уровне также базируется на правилах обработки сетевых соединений.
MikroTik работает с виртуальными сокетами, под которыми следует понимать совокупность пар IP адрес отправителя и номер порта отправителя, а также IP адрес получателя и номера порта получателя, искусственно введенных для обеспечения функционирования устройства. В этом и заключается сущность сетевых соединений глазами роутера. Чтобы всё основательно встало на свои места, мы разберём практическую задачу, но это уже будет в следующей части.
Русские Блоги
Понимание сетевого стека Linux (1): краткое описание стека сетевых протоколов Linux
В этой серии статей описывается сетевой стек Linux, в том числе:
(4) Технология разгрузки сегментации в среде QEMU / KVM + VxLAN (принимающая сторона)
1. Сетевой путь Linux
1.1 отправитель
1.1.1 Уровень приложения
(1) Socket
Различные сетевые приложения на прикладном уровне в основном взаимодействуют со стеком сетевых протоколов пространства ядра через программный интерфейс Linux Socket. Linux Socket разработан на основе BSD Socket, является одной из важных частей операционной системы Linux и основой сетевых приложений. На иерархическом уровне он расположен на уровне приложений и представляет собой API, предоставляемый операционной системой для программистов приложений, через который приложения могут получить доступ к протоколу транспортного уровня.
- Сокет расположен над протоколом транспортного уровня, что позволяет скрыть различия между разными сетевыми протоколами.
- Socket — это вход в сетевое программирование. Он обеспечивает большое количество системных вызовов и составляет основную часть сетевых программ.
- В системе Linux сокеты являются частью файловой системы, а сетевое взаимодействие можно рассматривать как чтение файлов, что делает управление сетью таким же удобным, как управление файлами.
Процесс обработки сокета UDP (источник) Процесс обработки сокета TCP (источник)
(2) Поток обработки на уровне приложений
- Веб-приложение вызывает Socket APIsocket (int family, int type, int protocol) Чтобы создать сокет, вызов в конечном итоге вызовет системный вызов Linux socket () и, наконец, метод sock_create () ядра Linux. Этот метод возвращает файловый дескриптор созданного сокета. Для каждого сокета, созданного сетевым приложением пользовательского пространства, в ядре есть соответствующая структура сокета и структура сокета. Среди них struct sock имеет три очереди (очереди), а именно rx, tx и err. Когда структура sock инициализируется, эти буферные очереди также инициализируются; в процессе приема и отправки квитанций каждая очередь сохраняется для отправки или получения Экземпляр skb структуры данных сетевого стека Linux sk_buffer, соответствующий каждому пакету.
- Для сокета TCP приложение вызывает API connect (), чтобы клиент и сервер установили виртуальное соединение через сокет. В этом процессе стек протокола TCP устанавливает TCP-соединение посредством трехстороннего рукопожатия. По умолчанию API будет ждать, пока квитирование TCP завершит установление соединения, прежде чем вернуться. Важным шагом в процессе установления соединения является определение максимального размера сегмента (MSS), используемого обеими сторонами. Поскольку UDP — протокол без установления соединения, этот шаг не требуется.
- Приложение вызывает API отправки или записи Linux Socket для отправки сообщения принимающей стороне.
- вызывается sock_sendmsg, он использует дескриптор сокета для получения структуры sock и создает заголовок сообщения и сообщение управления сокетом
- Вызывается _sock_sendmsg, и в соответствии с типом протокола сокета вызывается функция отправки соответствующего протокола.
- Для TCP вызовите функцию tcp_sendmsg.
- Для UDP приложение пользовательского пространства может вызвать любой из трех системных вызовов send () / sendto () / sendmsg () для отправки сообщений UDP, и в конечном итоге они вызовут функцию udp_sendmsg () в ядре.
1.1.2 Транспортный уровень
Конечная цель транспортного уровня — предоставить своим пользователям эффективные, надежные и экономичные услуги передачи данных.Основные функции включают (1) построение сегмента TCP (2) вычисление контрольной суммы (3) отправку пакета ответа (ACK) (4) Операция, гарантирующая надежность, например, скользящий отвод. Общий процесс обработки стека протоколов TCP показан на следующем рисунке:
Краткий процесс работы стека TCP:
- Функция tcp_sendmsg сначала проверяет статус установленного TCP-соединения, затем получает MSS соединения и запускает процесс отправки сегмента.
- Создайте загрузку сегмента TCP: он создает экземпляр skb структуры данных sk_buffer пакета в пространстве ядра и копирует данные пакета из буфера пространства пользователя в буфер skb.
- Создайте заголовок TCP.
- Вычислить контрольную сумму TCP (контрольную сумму) и порядковый номер (порядковый номер).
- Контрольная сумма TCP — это сквозная контрольная сумма, вычисляемая отправителем и затем проверяемая получателем. Его цель — обнаруживать любые изменения в заголовке TCP и данных от отправителя к получателю. Если получатель обнаруживает ошибку в контрольной сумме, сегмент TCP будет напрямую отброшен. Контрольная сумма TCP покрывает заголовок TCP и данные TCP.
- Требуется контрольная сумма TCP
Краткий процесс работы стека UDP:
- UDP инкапсулирует сообщение в дейтаграмму UDP
- Вызовите метод ip_append_data (), чтобы отправить пакет на уровень IP для обработки.
1.1.3 IP-сетевой уровень — добавление заголовка и контрольной суммы, обработка маршрутизации, IP-фрагментация
Задача сетевого уровня — выбрать подходящие узлы маршрутизации и коммутации между сетями для обеспечения своевременной передачи данных. Сетевой уровень составляет пакеты данных из кадров, предоставленных канальным уровнем.Заголовок сетевого уровня инкапсулируется в пакет, который содержит информацию о логическом адресе — сетевые адреса исходного сайта и адреса конечного сайта. В его основные задачи входит (1) обработка маршрутизации, то есть выбор следующего перехода (2) добавление IP-заголовка (3) вычисление контрольной суммы IP-заголовка, которая используется для определения того, содержит ли заголовок IP-пакета ошибку во время процесса распространения (4), если возможно, продолжить После обработки IP-фрагментации (5) получите MAC-адрес следующего перехода, установите заголовок канального уровня и затем передайте на канальный уровень для обработки.
Базовый процесс обработки IP-стека показан на следующем рисунке:
- Сначала ip_queue_xmit (skb) проверит информацию о маршрутизации skb-> dst. Если нет, например, первый пакет сокета, используйте ip_route_output () для выбора маршрута.
- Затем заполните различные поля IP-пакета, такие как версия, длина заголовка, TOS и т. Д.
- Некоторые средние фрагменты можно найти в соответствующих документах. Основная идея состоит в том, что когда длина сообщения больше, чем mtu, а длина gso не равна 0, для фрагментации будет вызываться ip_fragment, иначе для отправки данных будет вызван ip_finish_output2. В функции ip_fragment будет проверяться бит флага IP_DF, Если пакет IP-данных, подлежащий фрагментированию, не может быть фрагментирован, вызовите icmp_send () отправляет отправителю причину необходимости Фрагментация и цель установки флага отсутствия фрагментации недоступны Пакеты ICMP и отбросить пакеты, то есть установить статус IP В случае сбоя фрагментации отпустите skb, и возвращаемое сообщение будет слишком длинным код ошибки. Чтобы
- Затем используйте ip_finish_ouput2, чтобы установить заголовок канального уровня. Если буфер заголовка канального уровня есть (то есть hh не пуст), скопируйте его в skb. Если нет, то вызовите neigh_resolve_output и используйте ARP для его получения.
1.1.4 Уровень канала передачи данных
Функционально, на основе услуги потока битов, предоставляемой физическим уровнем, устанавливается канал данных между соседними узлами, обеспечивается безошибочная передача кадров данных (Frame) по каналу посредством контроля ошибок, и выполняются действия в каждой цепи. серии. Уровень канала передачи данных обеспечивает надежную передачу на ненадежных физических носителях. Роль этого уровня включает: адресацию физических адресов, формирование кадров данных, управление потоком, обнаружение ошибок данных, повторную передачу и т. Д. На этом уровне единица данных называется кадром. Представители протоколов уровня звена данных включают: SDLC, HDLC, PPP, STP, Frame Relay и т. Д.
С точки зрения реализации, Linux предоставляет уровень абстракции сетевого устройства, фактически это теперь linux / net / core / dev.c. Конкретные физические сетевые устройства должны реализовывать виртуальные функции в драйвере устройства (driver.c). Уровень абстракции сетевого устройства вызывает функции определенных сетевых устройств.
、
1.1.5 Инкапсуляция и передача физического уровня на физическом уровне
- После получения запроса на отправку физический уровень копирует данные из основной памяти во внутреннюю RAM (буфер) через DMA. В копию данных одновременно добавляются соответствующий заголовок, IFG, преамбула и CRC, соответствующие протоколу Ethernet. Для сетей Ethernet CSMA / CD используется для передачи на физическом уровне, то есть конфликты каналов отслеживаются во время передачи.
- После того, как сетевая карта завершит передачу сообщения, будет сгенерировано прерывание для уведомления ЦП, а затем обработчик прерывания на уровне драйвера может удалить сохраненный skb.
1.1.6 Краткое резюме
(источник)
1.2 Ресивер
1.2.1 Физический уровень и уровень канала данных
- Когда пакет поступает на физический сетевой адаптер машины, когда он получает фрейм данных, он инициирует прерывание и передает его rx_ring в памяти ядра Linux через DMA.
- Сетевая карта выдает прерывание, чтобы уведомить ЦП о наличии пакета, который необходимо обработать. Обработчик прерывания в основном выполняет следующие операции, включая выделение структуры данных skb_buff и копирование полученного кадра данных из порта ввода-вывода сетевого адаптера в буфер skb_buff; извлечение некоторой информации из кадра данных и установка соответствующего skb_buff Параметры, эти параметры будут использоваться сетевым протоколом верхнего уровня, например skb-> protocol;
- После простой обработки программа терминальной обработки отправляет мягкое прерывание (NET_RX_SOFTIRQ), чтобы уведомить ядро о получении нового кадра данных.
- В ядре 2.5 представлен набор новых API-интерфейсов для обработки полученного фрейма данных, а именно NAPI. Следовательно, у драйвера есть два способа уведомить ядро: (1) через предыдущую функцию netif_rx; (2) через механизм NAPI. Обработчик прерывания вызывает функцию netif_rx_schedule сетевого устройства, входит в поток обработки мягкого прерывания, а затем вызывает функцию net_rx_action.
- Эта функция закрывает прерывание, получает все пакеты в rx_ring каждого сетевого устройства, и, наконец, pacakage удаляется из rx_ring и входит в поток обработки netif _receive_skb.
- netif_receive_skb — это последняя станция, на которой канальный уровень принимает дейтаграммы. В соответствии с типами дейтаграмм сетевого уровня, зарегистрированными в глобальных массивах ptype_all и ptype_base, он доставляет датаграммы приемным функциям различных протоколов сетевого уровня (в основном ip_rcv и arp_rcv в домене INET). Эта функция в основном предназначена для вызова функции приема протокола третьего уровня для обработки пакета skb и перехода на третий сетевой уровень для обработки.
1.2.2 Сетевой уровень
- Функция входа уровня IP находится в функции ip_rcv. Эта функция сначала выполняет различные проверки, включая контрольную сумму пакета, и, если необходимо, дефрагментирует IP (объединяет несколько фрагментов), затем пакет вызывает зарегистрированный обработчик netfilter предварительной маршрутизации и, наконец, после завершения достигает функции ip_rcv_finish.
- Функция ip_rcv_finish вызовет функцию ip_router_input для входа в процесс маршрутизации. Сначала он вызовет ip_route_input для обновления маршрута, а затем Найдите маршрут и решите, будет ли пакет отправлен на локальную машину, перенаправлен или отклонен:
- Если он отправляется на локальный компьютер, вызовите функцию ip_local_deliver, которая может де-фрагментировать (объединить несколько IP-пакетов), а затем вызовите функцию ip_local_deliver. Эта функция вызывает интерфейс следующего уровня в соответствии с номером протокола следующего уровня обработки пакета, включая tcp_v4_rcv (TCP), udp_rcv (UDP), icmp_rcv (ICMP), igmp_rcv (IGMP). Для TCP вызывается функция tcp_v4_rcv, так что поток обработки входит в стек TCP.
- Если требуется пересылка, войдите в процесс пересылки. Этот процесс должен обработать TTL, а затем вызвать функцию dst_input. Эта функция (1) обработает Netfilter Hook (2) выполнит IP-фрагментацию (3) вызовет dev_queue_xmit и войдет в поток обработки канального уровня.
1.2.3 Транспортный уровень (TCP / UDP)
- Запись обработки TCP транспортного уровня находится в функции tcp_v4_rcv (находится в файле linux / net / ipv4 / tcp ipv4.c), которая выполняет проверку заголовка TCP и другую обработку.
- Вызовите _tcp_v4_lookup, чтобы найти открытый сокет пакета. Если его не найти, пакет будет удален. Затем проверьте состояние сокета и подключения.
- Если для сокета и соединения все в порядке, вызовите tcp_prequeue, чтобы пакет вошел в пользовательское пространство из ядра и поместил его в очередь приема сокета. Затем сокет будет разбужен, вызовет системный вызов и, наконец, вызовет функцию tcp_recvmsg, чтобы получить сегмент из очереди приема сокета.
1.2.4 Уровень приемника-приложения
- Каждый раз, когда пользовательское приложение вызывает read или recvfrom, этот вызов будет сопоставлен с системным вызовом sys_recv в /net/socket.c и преобразован в вызов sys_recvfrom, а затем будет вызвана функция sock_recgmsg.
- Для сокетов INET будет вызван метод inet_recvmsg в / net / ipv4 / af inet.c, который вызовет метод получения данных соответствующего протокола.
- Для TCP вызовите tcp_recvmsg. Эта функция копирует данные из буфера сокета в пользовательский буфер.
- Для UDP любой из трех системных вызовов recv () / recvfrom () / recvmsg () может быть вызван из пользовательского пространства для получения пакета UDP, и эти системные вызовы в конечном итоге вызовут метод udp_recvmsg в ядре.
1.2.5 Краткое описание процесса получения сообщения
2. Linux структура данных sk_buff struct и очередь (очередь)
2.1 sk_buff
2.1.1 Что такое sk_buff
Когда сетевой пакет обрабатывается ядром, данные нижележащего протокола передаются на более высокий уровень, и при передаче данных процесс меняется на противоположный. Данные (включая заголовок и нагрузку), генерируемые различными протоколами, непрерывно передаются на нижний уровень, пока они не будут окончательно отправлены. Поскольку скорость этих операций критична для производительности сетевого уровня, ядро использует специальную структуру, называемую sk_buff, файл определения которой находится вskbuffer.h. Буферы сокетов используются для обмена данными на уровне реализации сети без копирования или депакетирования пакетов данных — это значительный выигрыш в скорости. Чтобы
- sk_buff — это основная структура данных сети Linux, и ее файл определения находится вskbuffer.h。
- Буфер ядра сокета (skb) — это буфер, используемый сетевым стеком ядра Linux (от L2 до L4) для обработки сетевых пакетов (пакетов), его тип — sk_buffer. Проще говоря, один skb представляет пакет в сетевом стеке Linux; несколько skb, созданных сегментацией TCP, и IP-пакет хранятся в виде списка skb.
- struct sock имеет три очереди skb (очередь sk_buffer): rx, tx и err.
Его основные конструктивные элементы:
2.1.2 Основная операция skb
(1) Размещение skb = alloc_skb (len, GFP_KERNEL)
(2) Добавить полезную нагрузку (skb_put (skb, user_data_len))
(3) Используйте skb-> push, чтобы добавить заголовок протокола, или skb-> pull, чтобы удалить заголовок.
2.2 Очередь драйверов, используемая сетевым стеком Linux (очередь драйверов)
(Выдержки из этой главыQueueing in the Linux Network Stack by Dan Siemon)
2.2.1 Очередь
Между стеком IP и драйвером сетевого адаптера существует очередь драйверов. Обычно он реализуется как кольцевой буфер FIFO, который можно рассматривать просто как фиксированный размер. Эта очередь не содержит пакетных данных. Напротив, она сохраняет только указатель буфера ядра сокета (skb), а использование skb описано в предыдущем разделе на протяжении всей обработки сетевого стека ядра.
Пакеты, обрабатываемые стеком IP при вводе очереди. Эти пакеты либо генерируются приложением на локальном компьютере, либо поступают на локальный компьютер и маршрутизируются. Пакеты, добавленные в очередь IP-стеком, будут извлечены драйвером сетевого устройства (драйвером оборудования) и отправлены на аппаратное устройство NIC через шину данных и переданы.
Если TSO / GSO не используется, длина пакетов, отправленных из IP-стека в эту очередь, должна быть меньше MTU.
2.2.2 размер skb — максимальный размер по умолчанию — NIC MTU
Большинство сетевых карт имеют атрибут фиксированной максимальной единицы передачи (MTU), который представляет собой размер самого большого кадра, который может передать сетевое устройство. Для Ethernet значение по умолчанию составляет 1500 байт, но некоторые сети Ethernet могут поддерживать кадры jumbo размером до 9000 байт. В стеке IP-сети MTU указывает размер самого большого пакета, который может быть отправлен на NIC. Например, если приложение записывает 2000 байтов данных в сокет TCP, стеку IP необходимо создать два IP-пакета, чтобы размер каждого пакета был равен или меньше 1500 байтов. Можно видеть, что для передачи больших объемов данных относительно небольшой MTU приведет к передаче большого количества небольших пакетов в очередь драйвера. Это называется фрагментацией IP.
На следующем рисунке показана фрагментация IP-пакета с полезной нагрузкой 1500 байтов при MTU 1000 и 600:
Сетевые интерфейсы, протоколы и сетевые сокеты Linux
Сетевая подсистема Linux организует сетевой обмен пользовательских приложений и, как следствие, сетевое взаимодействие самих пользователей.
Часть сетевой подсистемы, выполняющаяся в режиме ядра, естественным образом ответственна за управление сетевыми устройствами ввода-вывода, но кроме этого на нее также возложены задачи маршрутизации и транспортировки пересылаемых данных, которые решаются при помощи соответствующих Сетевых протоколов. Таким образом, именно ядерная часть сетевой подсистемы обеспечивает процессы средствами сетевого межпроцессного взаимодействия (network IPC).
Внеядерная часть сетевой подсистемы отвечает за реализацию сетевых служб, предоставляющих пользователям прикладные сетевые услуги, такие как передача файлов, обмен почтовыми сообщениями, удаленный доступ и т. д.
Непосредственное, физическое взаимодействие сетевых узлов через каналы связи между ними реализуется аппаратурой сетевых адаптеров. Сетевые адаптеры, как и любые другие устройства ввода-вывода, управляются соответствующими драйверами, реализующимися в большинстве случаев в виде динамических модулей ядра.
Драйверы сетевых устройств
$ lspci
01:00.0 Network controller: Intel Corporation Centrlno Wireless-N 130 (rev 34)
02:60.0 Ethernet controller: …, Ltd. RTL8111/8168B PCI Express … Ethernet controller …$ lspci -ks 01:00.0
01:00.0 Network controller: Intel Corporation Centrlno Wireless-N 130 (rev 34)
Subsystem Intel Corporation Centrino Wireless-N 130 BGN
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
02:00.0 Ethernet controller: …, Ltd. RTL8111/8168B PCI Express … Ethernet controller …
Subsystem: Samsung Electronics Co Ltd Device c0b6
Kernel driver in use: r8169
$ modinfo iwlwifi r8169 | grep ^description
description: Intel(R) Wireless WiFi driver for Linux
description: RealTek RTL-8169 Gigabit Ethernet driverВ отличие от несетевых устройств, большинство которых имеют специальный файл в каталоге /dev, сетевые устройства представляются в системе своими интерфейсами. Список доступных интерфейсов, их параметры и статистику можно получить при помощи «классической» UNIX-команды ifconfig или специфичной для Linux команды ip.
Сетевые интерфейсы (UNIX ifconfig)
eth0 Link encap:Ethernet HWaddr e8:03:9a:0a:73:40
UP BROADCAST MULTICAST MTU: 1500 Metric: 1lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
wlan0 Link encap:Ethernet HWaddr b8:03:05:a2:28:4e
inet addr:192.168.100.5 Bcast: 192.168.100.255 Mask-.255.255.255.0inet6 addr: fe80::ba03:5ff:fea2:284e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
$ ifconfig wlanO
wlanO Link encap:Ethernet HWaddr b8:03:05:a2:28:4e
inet addr-.192.168.100.5 Beast: 192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80: :ba03:5ff:fea2:284e/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU: 1500 Metric: 1
RX packets:23103842 errors:0 dropped:0 overruns:0 frame:0
TX packets-.15591575 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2010967763 (2.0 GB) TX bytes:2828583098 (2.8 GB)Сетевые интерфейсы (Linux ip)
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWNlink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether e8:03:9a:0a:73:40 brd ff:ff:ff:ff:ff:ff
3: wlan0: «BROADCAST,MULTICAST,UP,L0WER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether b8:03:05:а2:28:4е brd ff:ff:ff:ff:ff:ff
$ ip -s link show dev wlanO
3: wlan0: «BROADCAST,MULTICAST,UP, LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000link/ether b8:03:05:a2:28:4e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2026956879 23261031 0 0 0 0
TX: bytes packets errors dropped carrier collsns
$ ip addr show dev wlanO
3: wlan0: «BROADCAST,MULTICAST,UP,L0WER_UP> mtu 1500 qdisc nq state UP qlen 1000link/ether b8:03:05:a2:28:4e brd ff:ff:ff:ff:ff:ff
inet 192.168.100.5/24 brd 192.168.100.255 scope global wlan0
valid_lft forever preferred_lft foreverinet6 fe80::ba03:5ff: fea2:284e/64 scope link
valid_lft forever preferred_lft forever
За логическое взаимодействие (адресацию, маршрутизацию, обеспечение надежной доставки и пр.) отвечают сетевые протоколы, тоже в большинстве случаев реализующиеся соответствующими модулями ядра.
Нужно отметить, что в примере из листинга ниже показан список динамически загруженных модулей, среди которых присутствует «нестандартный» TCP vegas, но нет IP, TCP, UDP и прочих «стандартных» протоколов стека TCP/IP.
На текущий момент времени сложно вообразить применение Linux без подключения к IP-сети, поэтому модули стандартных протоколов TCP/IP стека скомпонованы в ядро статически и являются частью «стартового» модуля.
Драйверы сетевых протоколов
$ lsmod
Module Size Used by
tcp_vegas 13603 0
esp4 12868 0ah4 12866 0
xfm_algo 14869 2 esp4,ah4
bnep 19167 2
bluetooth 356727 24 bnep,rf com,btusb
mac80211 564463 1 iwldvm$ nodinfo tcp_vegas bnep mac86211 | grep ‘^description
description: TCP Vegas
description: Bluetooth BNEP ver 1.3
description: IEEE 862.11 subsystemДоступ процессов к услугам ядерной части сетевой подсистемы реализует интерфейс сетевых сокетов socket, являющихся основным (и единственным) средством сетевого взаимодействия процессов в Linux.
Разные семейства (address family) сокетов соответствуют различным стекам сетевых протоколов. Например, стек TCP/IP v4 представлен семейством AFJNET, см. ip, стек TCP/IP v6 — семейством AF_INET6, см. ipv6, и даже локальные (файловые) сокеты имеют собственное семейство — AF_L0CAL, см. unix.
Для просмотра статистики по использованию сетевых сокетов применяют «классическую» UNIX-команду netstat или специфичную для Linux команду ss. В листингах ниже иллюстрируется использование этих команд для вывода информации обо всех (-a, all) сокетах протоколов (-u, udp) UDP и (-t, tcp) TCP стека TCP/IP v4 (-4), порты и адреса которых выведены в числовом (-n, numeric) виде, а также изображены процессы (-p, process), их открывшие.
Сетевые сокеты (UNIX netstat)
$ sudo netstat -4autpn
Активные соединения с интернетом (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 0:0.0.0:5900 0.0.0:0:* LISTEN 28880/vino-server
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 5999/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 655/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1064/cupsd
tcp 0 0 192.168.100.5:22 192.168.100.3:57929 ESTABLISHED 15841/sshd: …
udp 0 0 0.0.0.0:5353 0.0.0.0:* 15094/avahi-daemon:
udp 0 0 0.0.0.0546347 0.0.0.0:* 15094/avahi-daemon:
udp 0 0 127.0.0.1:53 0.0.0.0:* 5999/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 5995/dhclientСетевые сокеты идентифицируются парой адресов (собственным, local, и чужим (адрес удаленного приложения, с которым установлено соединение), foreign), принятыми в их семействе. Например, для семейства TCP/IP адрес сокета состоит из (сетевого) IP-адреса и (транспортного) номера порта, причем нули имеют специальное — «неопределенное» значение.
Так для прослушивающего (LISTEN) сокета 0.0.00 в собственном IP-адресе означает, что он принимает соединения, направленные на любой адрес любого сетевого интерфейса, а 0.0.0.0 в чужом адресе указывает на то, что взаимодействие еще не установлено. Прослушивающие сокеты используются «серверными» приложениями, пассивно ожидающими входящие соединения с ними.
Для сокетов с установленным (ESTABLISHED) взаимодействием оба адреса имеют конкретные значения, определяющие участников взаимодействия, например 192.168.100.5:22 и 192.168.100.3:57929.
Сетевые сокеты (Linux ss)
$ sudo ss -4atupn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:5353 *:* users: ((«avahi-daemon»,15094,13))udp UNCONN 0 0 *:46347 *:* users: ((«avahi-daemon»,15094,15))
udp UNCONN 0 0 127.0.0.1:53 *:* users: ((«dnsmasq»,5999,4))
udp UNCONN 0 0 *:68 *:* users: ((«dhcltent”,5995,6))
udp UNCONN 0 0 *:5900 *:* users: ((«vino-server»,28880,14))
udp UNCONN 0 0 127.0.0.1:53 *:* users: ((«dnsmasq»,5999,5))
udp UNCONN 0 0 *:22 *:* users: ((«sshd»,655,4))
udp UNCONN 0 0 127.0.0.1:631 *:* users: ((«cupsd»,1064,10))
udp UNCONN 0 0 127.0.0.1:25 *:* users: ((«master»,2021,12))
Из примеров листингов выше видны 5 «слушающих» (LISTEN) сокетов TCP и 4«несоелииеиных» (UNCONN) сокета UDP, открытых разными службами операционной системы. Например, 22 порт TCP открыл сервер sshd, PID = 655 службы удаленного доступа W:[SSH], а 5900 порт TCP — сервер vino-server, PID = 28880 службы удаленного доступа к рабочему столу пользователя W:[VNC].
Сетевая подсистема ОС Linux чрезвычайно развита на всех ее уровнях — от сетевых интерфейсов и протоколов до прикладных сетевых служб. На сегодняшний день колоссальное количество сетевых устройств работают под управлением Linux — маршрутизаторы, сетевые хранилища, медиаплееры, TV-боксы, планшеты, смартфоны и прочие «встраиваемые» и мобильные устройства.
К сожалению, рассмотреть весь пласт сетевых возможностей в рамках этой статьи, не представляется возможным, т. к. потребует от читателя серьезного понимания устройства и функционирования самих сетевых протоколов стека TCP/IP, что не является предметом настоящего рассмотрения.
Основополагающим результатом должно стать понимание принципов организации сетевого взаимодействия в Linux, необходимое и достаточное в качестве базы для последующего самостоятельного расширенного и углубленного изучения. Не менее полезными в практике администратора и программиста будут навыки использования инструментов трассировки и мониторинга сетевых сокетов, а в особенно «непонятных» ситуациях навыки применения анализаторов пакетов.
Исключительное место (эдакий «швейцарский нож») среди прочих сетевых инструментов Linux займет служба SSH, при распределенном использовании оконной системы X Window System, являющейся основой современного графического интерфейса пользователя.