Pppd dns что это

Обновлено: 03.07.2024

PPP - это протокол, используемый для установки межсетевых соединений через модемы, соединения DSL и многие другие типы соединений точка-точка. Демон pppd работает совместно с драйвером PPP ядра для установки и поддержания соединения PPP с другой системой (называемой партнёром) и согласования IP-адресов для каждого конца соединения. pppd также может аутентифицировать партнёра и/или предоставлять партнёру информацию для аутентификации. PPP можно использовать с другими сетевыми протоколами, отличными от IP, но такое применение становится всё более редким.

ЧАСТО ИСПОЛЬЗУЕМЫЕ ОПЦИИ

ОПЦИИ

ФАЙЛЫ ОПЦИЙ

Опции можно указывать не только в командной строке, но и в файлах. Перед обработкой опций командной строки pppd прочитает опции из файлов /etc/ppp/options,

БЕЗОПАСНОСТЬ

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

По умолчанию pppd разрешает партнёрам, не прошедшим процедуру аутентификации, использовать заданный IP-адрес, только если система уже не имеет маршрута к этому IP-адресу. Например, система с постоянным соединением к сети интернет обычно имеет маршрут по умолчанию, и следовательно при установке соединения все партнёры должны пройти процедуру аутентификации. На таких системах опция auth используется по умолчанию. В случаях если система с PPP-соединением в интернет в штатном режиме не имеет маршрута по умолчанию, партнёру разрешается использовать практически любой IP-адрес без аутентификации.

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

/.ppprc, ни в файла опций, заданном опцией file, даже несмотря на принадлежность исполняемого файла пользователю root и установленный бит setuid. Привилегированные опции могут быть указаны в файле /etc/ppp/options или прочитаны из файла опций, указанного в опции call. Пользователю root разрешается пользоваться любыми привилегированными опциями.

При открытии устройства, pppd использует идентификатор пользователя, запустившего pppd, или идентификатор root (который равен 0), в зависимости от того, было ли указано имя устройства пользователем или системным администратором. Если имя устройства взято из привилегированного источника, например из файла /etc/ppp/options или файла опций, заданного опцией call, pppd откроет устройство от имени пользователя root. Таким образом, при создании соответствующего файла в подкаталоге /etc/ppp/peers, системный администратор может разрешить пользователям устанавливать PPP-соединение через устройство, на доступ к которому у них обычно нет прав. В других случаях для открытия устройства используется реальный идентификатор пользователя, запустившего pppd.

АУТЕНТИФИКАЦИЯ

Аутентификация - это процесс подтверждения личности одним партнёром другому. При этом один партнёр отправляет своё имя другому вместе с секретной информацией, которая может поступить только от настоящего авторизованного пользователя этого имени. В таком обмене первого партнёра можно назвать "клиентом", а другого "сервером". Клиент имеет имя, с помощью которого он идентифицирует себя перед сервером, а сервер - имя, которым он идентифицирует себя перед клиентом. Обычно клиент и сервер имеют некоторый общий пароль, и клиент доказывает свою подлинность знанием этого пароля. Очень часто имена, используемые партнёрами при аутентификации, являются именами узлов в интернете, но это не существенно.

В настоящее время pppd поддерживает три протокола аутентификации: PAP (Password Authentication Protocol - протокол аутентификации по паролю), CHAP (Challenge Handshake Authentication Protocol - протокол аутентификации рукопожатия с откликом), и EAP (Extensible Authentication Protocol - расширяемый протокол аутентификации). PAP подразумевает, что клиент для собственной аутентификации отправляет на сервер своё имя и пароль открытым текстом. В противоположность ему, при использовании протокола CHAP сервер сам инициирует обмен аутентификацией по протоколу CHAP, отправляя клиенту пакет challenge (пакет challenge содержит имя сервера). Чтобы подтвердить знание пароля, клиент должен ответить пакетом response, который включает его имя и значение хэша, полученное из пароля и содержимого пакета challenge. EAP поддерживает аутентификацию в стиле CHAP, а также содержит механизм SRP-SHA1, который противостоит атакам по словарю и не требует хранения пароля открытым текстом на стороне сервера.

Протокол PPP изначально симметричен и позволяет обоим партнёрам требовать друг у друга аутентификации. В этом случае происходят два различных и независимых обмена аутентификацией. Два обмена могут использовать различные протоколы аутентификации, и в принципе, при двух обменах могут использоваться разные имена.

По умолчанию pppd согласен подтвердить свою подлинность, если это запрошено, но не требует аутентификации от партнёра. Однако, pppd откажется подтверждать свою подлинность с помощью определённого протокола, если не располагает паролем для этого протокола.

pppd хранит пароли, используемые для аутентификации, в файлах паролей (/etc/ppp/pap-secrets для PAP, /etc/ppp/chap-secrets для CHAP, MS-CHAP, MS-CHAPv2, EAP MD5-Challenge, и /etc/ppp/srp-secrets для EAP SRP-SHA1). Все файлы паролей имеют одинаковый формат. Файлы паролей могут содержать пароли, которые используются pppd для подтверждения собственной подлинности на других системах, и пароли, используемые pppd для аутентификации других систем.

Каждая строка в файле паролей содержит один пароль. Каждый пароль соответствует определённой паре клиент/сервер и используется только для аутентификации данного клиента на данном сервере. Поэтому каждая строка в файле паролей имеет по крайней мере 3 поля: имя клиента, имя сервера и пароль. Эти поля могут быть дополнены списком IP-адресов, которые данный клиент может использовать при подключении к данному серверу.

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

Если пароль начинается с ‘@’, то за ним следует предполагаемое имя файла, из которого будет прочитан пароль. "*" совпадёт с любым именем клиента или сервера. При выборе секрета pppd выбирает лучшее совпадение, то есть совпадение с наименьшим количеством шаблонов.

Любые последующие слова в той же строке задают список принимаемых IP-адресов этого клиента. Если в строке только 3 слова, или первое слово - это "-", тогда запрещаются все IP-адреса. Для разрешения любого адреса используйте "*". Слово начинающееся с "!" указывает, что данный адрес не принимается. Для указания подсети за адресом может следовать "/" и число n. В таком случае принимаются все адреса, имеющие те же значения n старших бит. В этой форме за адресом может следовать знак плюса ("+"), указывающий что каждый адрес из подсети разрешён для сетевого интерфейса ppp с определённым номером. В этом случае узловая часть адреса будет расчитана как номер интерфейса плюс один.

Файлы пароли содержат пароли обоих типов - для аутентификации других узлов и для подтверждения собственной подлинности. Когда pppd проверяет подлинность партнёра, он выбирает пароль, указанный в строке с именем партнёра в первом поле и именем локальной системы во втором поле. Имя локальной системы по умолчанию - это имя узла. Если используется опция domain, то имя узла будет дополнено доменным именем. Данное поведение по умолчанию можно изменить с помощью опции name, за исключением случаев использования опции usehostname. (Для EAP SRP-SHA1 обратитесь к описанию утилиты srp-entry(8), генерирующей содержимое поля "пароль".)

Когда pppd выбирает пароль для аутентификации у партнёра, то сначала определяется собственное имя, используемое для идентификации. Это имя может быть указано пользователем при помощи опции user. Если эта опция не используется, то по умолчанию будет выбрано имя локальной системы, определённое способом, описанным в предыдущем параграфе. Затем pppd будет искать пароль, соответствующий своему имени в первом поле и имени партнёра во втором поле. При использовании аутентификации CHAP или EAP pppd знает имя партнёра, потому что партнёр посылает своё имя в пакете challenge. Однако при использовании PAP pppd определит имя партнёра по опциям, указанным пользователем. Пользователь может явно указать имя партнёра с помощью опции remotename. В других случаях, если удалённый IP-адрес был указан именем (что предпочтительнее числового вида), это имя будет использоваться в качестве имени партнёра. В случае неудачи pppd в качестве имени партнёра будет использовать пустую строку.

Если партнёр аутентифицируется с помощью PAP, то предоставленный пароль сначала сравнивается с паролем из файла паролей. Если пароли не совпадают, то пароль партнёра шифруется с помощью функции crypt() и сравнивается с паролем из файла снова. Таким образом при необходимости можно хранить пароли для аутентификации партнёра в зашифрованной форме. Если задана опция papcrypt, то для повышения безопасности первоначальное (незашифрованное) сравнение будет пропущено.

Кроме того, при указании опции login, имя пользователя и пароль также будут проверены по системной базе данных паролей. Таким образом, системный администратор может задать в файле pap-secrets имена только тех пользователей, которым разрешено пользоваться PPP и ограничить набор IP-адресов для каждого из них. Обычно при использовании опции login в файл /etc/ppp/pap-secrets прописывается пароль "", который будет совпадать с любым паролем, предоставленным партнёром. Это позволит не прописывать одинаковый пароль в двух местах.

Перед включением IPCP (или любого другого протокола управления сетью (NCP - Network Control Protocol)) аутентификация должна завершиться удачно. Если партнёр требует подтверждения нашей подлинности, но аутентификация завершилась неудачно, то pppd закроет канал (закрытием LCP). IPCP будет закрыт, если согласованный по протоколу IPCP IP-адрес удалённого узла не принимается. Пакеты IP могут отправляться или приниматься только при открытом IPCP.

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

МАРШРУТИЗАЦИЯ

При успешном завершении согласования IPCP, pppd сообщит ядру локальный и удалённый IP-адреса для интерфейса ppp. Этого достаточно для создания маршрута к узлу на удалённом конце канала, чтобы заработал обмен IP-пакетами между партнёрами. Связь с другими машинами обычно требует дальнейшей модификации таблиц маршрутизации и/или таблиц ARP (Address Resolution Protocol). В большинстве случаев для этого достаточно указать опции defaultroute и/или proxyarp, но в некоторых случаях требуется дальнейшее вмешательство с помощью сценария /etc/ppp/ip-up.

Иногда желательно добавить маршрут по умолчанию через удалённый узел, в таких случаях машина будет иметь только соединение с сетью Интернет через интерфейс ppp. Опция defaultroute заставит pppd создать такой маршрут по умолчанию после завершения согласования IPCP, и удалить его при закрытии канала.

В некоторых случаях желательно использовать ARP-прокси, например на серверной машине, подсоединённой к локальной сети, чтобы разрешить другим узлам связываться с удалённым узлом. Опция proxyarp заставит pppd наблюдать за сетевым интерфейсом в той же подсети, что и удалённый узел. Интерфейс должен поддерживать широковещание и ARP, он должен быть активен и не являться петлевым (loopback) интерфейсом или интерфейсом точка-точка. Если такой интерфейс найден, pppd создаст постоянную опубликованную ARP-запись с IP-адресом удалённого узла и аппаратным адресом найденного сетевого интерфейса.

При использовании опции demand, IP-адреса интерфейса уже установлены до согласования IPCP. Если pppd не сможет согласовать тот же адрес, который использовался для настройки интерфейса (например когда партнёр - это Интернет-провайдер, который использует динамическое назначение IP-адресов), pppd изменит IP-адреса интерфейса на согласованные адреса. Не рекомендуется использовать звонок по требованию до партнёра, который назначает IP-адреса динамически, потому что это может нарушить существующие соединения.

МНОГОКАНАЛЬНЫЙ РЕЖИМ

Итак, getty в качестве шелла вызывает /usr/sbin/pppd, поэтому мы не можем задать параметры pppd из командной строки, и зададим все необходимые параметры в файлах /etc/ppp/options и /etc/ppp/options.ttyd0. Напомню, что в первом у нас записано:

Во второй же мы поместим следующее:

Рассмотрим параметры подробнее:

passive При запуске pppd пытается несколько раз установить PPP-соединение, если же все попытки оказались неудачными, pppd завершает работу. Этот параметр указывает pppd не завершать работу, а пассивно ожидать попытки установления соединения, исходящие с удалённой стороны.

192.168.1.1:192.168.1.200 Этот параметр задает соответственно локальный и удалённый адреса для данного соединения, то есть локальный адрес равен 192.168.1.1, а адрес удалённой стороны - 192.168.1.200. В принципе, адреса могут быть выбраны совершенно от балды, например, 192.168.100.1:10.0.0.1 - между нашим и удалённым компьютером будет работать PPP-соединение. Проблемы начнутся, когда удалённый компьютер будет использовать наш в качестве маршрутизатора для доступа к другим компьютерам. Тут нам придется попотеть с таблицей маршрутизации. Но если удалённой стороне нужно выделить только один адрес без всяких сетей, то существует способ избежать этого. Для этого удалённой стороне нужно назначить адрес, входящий в нашу локальную сеть, и указать pppd параметр proxyarp, описанный чуть ниже. Кстати, адрес локальной стороны может совпадать с адресом одной из сетевых карт на этом же компьютере.

После того, как к нам позвонят и pppd установит соединение, выполним команду

Мы увидим, что сетевому интерфейсу ppp1 назначен адрес 192.168.1.1:

А выполнив команду

мы удостоверимся, что удалённой стороне назначен адрес 192.168.1.200:

proxyarp Каждый компьютер в сети хранит таблицу соответствия локальных IP-адресов и физических адресов, например, ethernet'овских. Исходя из этой таблицы, сетевой драйвер определяет по какому физический адресу нужно послать пакет с заданным IP-адресом. Эта таблица динамически обновляется с помощью протокола ARP.

Если мы выбрали для удалённой стороны адреса, которые входят в нашу локальную сеть, то имеет смысл использовать параметр proxyarp. Этот параметр указывает pppd создать запись в этой таблице для адреса удалённой стороны (в нашем примере - 192.168.1.200) и поставить ему в соответствие физический адрес одной из сетевых карт, установленных на локальном компьютере. В результате, все компьютеры в нашей локальной сети (кроме того, на который позвонили) будут считать, что адрес 192.168.1.200 находится на этом компьютере и, таким образом, проблемы с маршрутизацией с нашей стороны не возникает.

После успешного соединения выполним команду

и увидим, что pppd создал для удалённой стороны с адресом 192.168.1.200 запись в нашей таблице с физическим адресом "0:40:c7:95:38:72":

Выполнив на соседнем компьютере ту же команду

мы увидим, что для него наши два адреса вообще никак не отличаются:

ms-dns 192.168.1.2 и ms-dns 192.168.1.4 Windows 95 и NT 4.0 при установлении PPP-соединения запрашивает адреса двух DNS серверов. Первый параметр задает адрес первого DNS сервера, а второй, понятно, второго. Если у Вас только один DNS сервер, то укажите параметр только один раз.

Этот параметр никак не влияет на адреса DNS клиента, если клиентом выступает pppd. В старых версиях pppd этому параметру соответствовали два других - dns1 и dns2, но, очевидно, эти названия неоднократно вводили публику в заблуждение относительно их применения и параметр переименовали.

debug Это параметр указывает pppd вести подробный протокол соединения.

В два других файла /etc/ppp/options.ttyd2 и /etc/ppp/options.ttyd3 мы запишем то же самое, за исключением адреса удалённой стороны - он будет другой - соответственно 192.168.1.1:192.168.1.201 и 192.168.1.1:192.168.1.202. Локальный же адрес во всех соединениях мы будем использовать один и тот же.

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

Из файла /etc/ppp/options.
Записывать что-то сюда - занятие достаточно бессмысленное. Правда, сюда можно поместить адрес локальной стороны - 192.168.1.1:, так как он у нас одинаков для всех входящих соединений. Но поскольку у нас есть одно исходящее соединение к нашему провайдеру, лучше этого не делать.

/.ppprc, находящегося в домашнем каталоге пользователя, который запустил pppd.
От этого файла тоже мало пользы. Поскольку, либо нам придется каждому пользователю выделять по отдельному адресу, либо эти адреса всё равно будут переопределены следующим файлом. Кроме того, если мы будем использовать PAP или CHAP аутентификацию, то pppd будет всегда запускаться от root'а. В этом случае, лучше назначать адреса с помощью secrets-файлов.

Из файла /etc/ppp/options.ttyd0.
Наиболее действенный способ, которым мы и вспользовались. Каждому порту выделяется свой адрес.

Из командной строки pppd.
Для этого нам нужно записать pppd с нужными нам параметрами в файл:

В руководстве приведены примеры редактирования конфигурационных файлов с помощью текстовых редакторов «nano» и «gedit». Обратите внимание на то, что первый редактор запускается в терминале и может быть использован как при запуске Ubuntu с графическим интерфейсом, так и без него, а «gedit» можно использовать только при включенной графической среде.

Требования к системе

Прежде чем Вы начнете, убедитесь, что:

Различные сетевые утилиты, предназначенные для автоматического конфигурирования сети выключены. Например, тут Вы можете прочитать, как отключить установленный по умолчанию в Ubuntu сетевой помощник Network Manager. Различные сетевые фильтры (например iptables), и утилиты их конфигурирования (например, Firestarter) отключены/правильно настроены и не вмешиваются в работу сети. У Вас есть все необходимые параметры для подключения в Вашей сети (например, IP-адрес, маска подсети и шлюз по умолчанию для соединения с использованием статического IP). Устройства сети осуществляющие фильтрацию по MAC-адресу правильно настроены и «знают» Ваш сетевой интерфейс. Драйвер Вашего сетевого устройства корректно установлен, кабель (при проводном соединении) исправен и подсоединен.

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

Она позволяет посмотреть подключенные сетевые устройства.

Пример вывода команды:

Обратите внимание на строку:

eth0 - это и есть искомое имя сетевого интерфейса.

Имя eth0 будет далее применяться для настройки именно данной сетевой карты. Где eth обозначает что используется Ethernet интерфейс, а 0 - номер устройства. Если у вас установлено несколько сетевых устройств, то, соответственно, им будут присвоены имена: eth0 , eth1 , eth2 и т.д.

После внедрения SystemD (начиная с Ubuntu 15.04) сетевые интерфейсы могут иметь другие имена (не ethX). Сделано это для того, что бы имена сетевых устройств не менялись при подключении к машине новых адаптеров (в последнее время, некоторые USB модемы выступают в роли сетевого адаптера). В результате eth0 может называться например enp0s4 или eno1, или даже enx78e7d1ea46da. Именно это имя сетевого адаптера и нужно использовать в настройке сети.

Более подробно о наименовании сетевых интерфейсов в SystemD можно почитать тут (англ.).

Такое переименование можно отключить добавив в /etc/default/grub, в строку с переменной GRUB_CMDLINE_LINUX_DEFAULT строку net.ifnames=0. После этого нужно выполнить sudo update-grub

Настройка проводной сети

Настройка IP-адреса, шлюза по умолчанию, маски подсети

Отредактируйте файл конфигурации /etc/network/interfaces , например так:

И допишите в него:
Для статического IP:

iface eth0 inet static - указывает, что интерфейс ( iface eth0 ) находится в диапазоне адресов IPv4 ( inet ) со статическим ip ( static ); address 192.168.0.1 - указывает что IP адрес (address) нашей сетевой карты 192.168.0.1; netmask 255.255.255.0 - указывает что наша маска подсети (netmask) имеет значение 255.255.255.0; gateway 192.168.0.254 - адрес шлюза ( gateway ) по умолчанию 192.168.0.254; auto eth0 - указывет системе что интерфейс eth0 необходимо включать автоматически при загрузке системы с вышеуказанными параметрами.

eth0 - имя подключаемого своего интерфейса. Список интерфейсов можно посмотреть набрав:

В итоге файл /etc/network/interfaces должен выглядеть примерно так:
(для одного проводного соединения со статическим IP)

Сохраните файл и закройте редактор. В данном примере (редактор nano) - нажмите Ctrl + X , затем Y , убедитесь, что «Имя файла для записи» - /etc/network/interfaces и нажмите Enter .

Более подробно про синтаксис файла /etc/network/interfaces можно прочитать в документации.

Пример конфигурации для динамического IP:

Временная настройка IP-адреса и маски подсети

При необходимости задать пробные настройки, выполните:

Где 192.168.0.1 - наш IP-адрес, /24 - число бит в префиксной части адреса (соответствует маске подсети 255.255.255.0).
eth0 - подключаемый сетевой интерфейс.

Данные настройки пропадут после перезагрузки системы и не повлияют на файл /etc/network/interfaces

Настройка DNS

Обратите внимание - в /etc/resolv.conf, при записи нескольких серверов используется несколько ключей nameserver, а в /etc/network/interfaces все адреса DNS серверов записывались в одну строчку после ключа dns-nameservers, разделенные пробелами.

В итоге описание статического интерфейса в /etc/network/interfaces должно выглядеть примерно так:

Ubuntu до версии 12.04

В более старых версиях ubuntu, когда есть необходимость указать статические адреса DNS серверов (если они не выдаются автоматически) выполните:

Настройка соединений ppp

За создание соединений типа «точка-точка» в Ubuntu отвечает демон pppd , более подробная информация о котором доступна в документации. В рамках данного руководства будут рассмотрены примеры создания PPPoE подключения через DSL модем, подключения PPTP (VPN-подключения) и DIAL-UP подключения через обычный модем.

Соединение PPPoE

В стандартную установку Ubuntu входит утилита для настройки PPPoE соединений – pppoeconf , для ее запуска наберите:

Появится «псевдографическое» 2) окно в терминале. Утилита произведет поиск сетевых устройств и выведет их на экран, далее она произведет поиск модема 3) на этих устройствах. Если на этом этапе pppoeconf выдаст отрицательный результат - проверьте правильность подключения, питание модема. Следующий шаг - выбор «популярных параметров» - в большинстве случаев стоит согласиться. Далее утилита запросит Ваш логин, а затем - пароль. Теперь - выбор способа указания DNS серверов. Опять же, в большинстве случаев следует согласиться на получение адресов DNS серверов автоматически. Далее Вам предложат ограничить размер MSS до 1452-х байт - как правило, стоит согласиться. Следующий вопрос - устанавливать ли подключение автоматически при загрузке компьютера. Последний вопрос утилиты - установить ли соединение сейчас. pppoeconf по умолчанию создает для подключения имя dsl-provider. Управлять подключением Вы можете при помощи команд:

Если в Вашем случае опций, предоставляемых утилитой pppoeconf недостаточно - обратитесь к документации по pppd или pppoeconf.

Замечание: при настройке соединения с помощью pppoeconf часть настроек записывается в /etc/network/interfaces , в результате чего Network Manager больше не может управлять сетью. Выход: либо использовать только NM, либо только консоль+конфиги. Вернуть управление Network Manager можно следующим образом. Приведите /etc/network/interfaces к следующему виду (лишнее не обязательно удалять, достаточно закомментировать):

Перезагрузитесь или перезапустите Network Manager:

Соединение PPTP

И добавьте туда опции подключения, например такие:

Далее - отредактируйте файл /etc/chap-secrets 4) и добавьте туда:

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

Процесс настройки VPN-соединения может сильно облегчить скрипт-помощник.

Настройка DIAL-UP подключения

Для настройки модемного соединения можно использовать встроенный конфигуратор pppd - pppconfig или специальную утилиту wvdial .

При помощи pppconfig

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

Управлять соединением можно так:

Где my-provider - имя, присвоенное Вами соединению при настройке.

При помощи wvdial

В некоторых случаях (например при подключении с использованием мобильного телефона), удобнее использовать wvdial . Для этого нужно его сначала установить. Например так:

В состав пакета wvdial входит утилита автоматического конфигурирования - wvdialconf .

Вывод будет примерно следующим:

Теперь остается только отредактировать файл /etc/wvdial.conf и добавить в него номер телефона, логин и пароль.

В данном примере я дополнительно добавил несколько опций. См. комментарии.

Файл /etc/wvdial.conf разбит на секции, в качестве разделителей которых выступают сами названия секций, предварённые словом Dialer, в квадратных скобках. Если исполнять команду без параметров, то в дело пойдут установки, перечисленные в секции Defaults. В противном случае дополнительно будут исполнены указанные в добавочных секциях команды.

Теперь, когда все настроено, соединение можно установить набрав:

Если потребуется запустить wvdial с набором номера в импульсном режиме, то это можно сделать командой

Прервать соединение можно прервав выполнение команды wvdial , т.е. в том же терминале нужно нажать Ctrl + C .

Автоматическое подключение

Отредактируйте файл конфигурации /etc/network/interfaces , например так:

И допишите в него:
Для pppoe , pptp , и модемного подключения без использования wvdial :

Где my-provider - название вашего соединения.
При использовании wvdial :

Теперь при перезапуске сетевых служб соединение будет автоматически установлено.

Ручная настройка роутинга

Если Вы не получаете адрес шлюза по-умолчанию от сервера, к которому подключаетесь, или по какой-либо иной причине Вам необходимо указать маршруты вручную - Вы можете создать свой скрипт в /etc/ppp/ip-up.d/ , либо по рекомендации официальной документации создать /etc/ppp/ip-up.local например так:

со следующим кодом:

Далее - сделайте этот скрипт исполняемым, например так:

Теперь маршруты будут автоматически подключаться при установлении ppp-соединения.

Установка MTU и TTL

MTU (Maximum Transfer Unit) - параметр определяет величину максимальной единицы передачи. Это максимальное количество октетов (байт), которое интерфейс способен поддерживать за одну операцию приема/передачи. Для Ethernet это значение по умолчанию составляет 1500 (максимальный размер пакета Ethernet).

TTL (Time To Live) - время жизни ip-пакета в секундах. Нужен чтобы избежать перегрузки сети пакетами. Обычно каждый роутер, через которого прошел пакет, уменьшает TTL на еденицу. Если TTL=0, пакет из системы удаляется. Изначально TTL=128 (для Windows) и TTL=64 (для Ubuntu). Для DNS -записей TTL определяет время актуальности данных при кешировании запросов.

Для изменения величины MTU, отредактируем файл конфигурации /etc/network/interfaces , например так:

Для изменения величины TTL наберите:

Значение TTL меняется только с правами администратора, для выхода из аккаунта администратора введите exit

Настройка WiFi

Настройка Wi-Fi при помощи wpa-supplicant и /etc/network/interfaces

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

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

Замечания

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

После установки всех необходимых пакетов, кабель проводной сети лучше отсоединить. Некоторые устройства (или их драйвера, например Madwifi) не поддерживают WPA2 (AES). Если соединение WPA2 установить не удается, можно попробовать WPA1 (TKIP). Если у Вас RTxxx (Ralink) с драйверами Serialmonkey - этот способ Вам не поможет. Вам следует либо установить пакет ndiswrapper , заменяющий Serialmonkey, либо попробовать другой способ.

Подготовка

Установите пакеты wpa-supplicant и wireless-tools
Например так:

Теперь убедитесь в том, что Ваше беспроводное устройство (в данном примере это «wlan0») работает и «видит» беспроводные сети. Команда

должна выдать примерно такой результат:

а доступные сети можно посмотреть командой

которая должна выдать примерно такой результат:

Ничего страшного, просто введите команду

соответственно выключить устройство можно командой

Настройка

Редактируем /etc/network/interfaces , например так:

Удаляем (или комментируем) все упоминания нашего беспроводного интерфейса и добавляем свои:

Генерация ключей

Теперь нам нужно сконвертировать нашу ключевую фразу (WPA ASCII ) в hex-ключ:

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

hex-ключ это все символы после «psk=».

Нужно его скопировать в буфер обмена и вставить в файл /etc/network/interfaces в поле wpa-psk.

Теперь можно сохранить файл и перезагрузить сеть. Должно установиться соединение. Однако иногда этого сразу не происходит. Если это так - перезагружаем машину.

Дополнительно

Отключаем чтение файла /etc/network/interfaces для others во избежания попадания пароля от сети к третьим лицам.

Примеры конфигураций

WPA2 + статический IP, скрытый ESSID.

Другие способы работы Wi-Fi оборудования

При помощи Wi-Fi адаптера также возможно установить децентрализованную сеть ad-hoc или сделать из компьютера под управлением Ubuntu точку доступа. Поскольку описание данных способов Wi-Fi подключения выходит за рамки этого руководства - обратитесь к соответствующим разделам. Ссылки на эти разделы см. в разделе Cсылки .

Решение проблем

Не устанавливается соединение по Wi-Fi/Ethernet с точкой доступа/маршрутизатором

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

будет выводиться в консоль похожий текст

Причиной проблемы может быть то, что материнская плата полностью не обесточивается при выключении компьютера. При этом вероятно не обесточивается и некоторое периферийное оборудование, в т.ч. могут не обесточиваться usb порты. Если вы используете, например, Wi-Fi usb-адаптер, то в таком случае можно заметить горящий на адаптере светодиод (если он им оборудован). Вероятно проблема возникает из-за того, что сетевое оборудование в этом режиме работает не совсем корректно.

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

Сложное решение проблемы состоит в настройке параметров BIOS-а на полное обесточиваение сетевого оборудования при выключении компьютера.

Иногда наглухо пропадает соединение по Wi-Fi с точкой доступа/маршрутизатором

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

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

Причиной проблемы может быть то, что некоторые маршрутизаторы произвольно выбирают номер рабочего канала, игнорируя номер канала выбранный в настройках маршрутизатора. Если в файле /etc/network/interfaces номер канала для беспроводного интерфейса указан, то вероятно проблема состоит именно в этом. Номер 6 канала указывается в файле примерно так:

Простое решение проблемы состоит в комментировании этого параметра, чтобы адаптер не был ограничен только этим каналом, и перезапуске сети

Сложное решение проблемы состоит в регистрации бага на сайте производителя маршрутизатора (прошивки для него) и обновление прошивки маршрутизатора после (в случае) его исправления.

Перезапуск сети

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

Теперь, при запуске команды ip addr должно отобразиться подключение eth0 с выставленными параметрами. Если подключение отображается, но параметры не такие, какие были указаны в файле /etc/network/interfaces , либо возникают любые другие ошибки, перепроверьте этот файл на наличие неточностей и опечаток и попробуйте ещё раз перезапустить сеть.

FAQ по сетям

Как зайти на мой компьютер извне (через интернет)?

Для начала надо узнать, какой IP-адрес даёт провайдер — серый или белый (не путать со статическим/динамическим). Если серый, то ничего не получится. Если белый, то возможны два варианта:

Роутера нет или он работает в режиме бриджа (моста). В этом случае белый IP-адрес присваивается самому компьютеру. Вводим адрес — попадаем на комп, всё просто. Белый адрес присваивается роутеру. Соответственно, по этому адресу мы попадаем на роутер, а не на компьютер. Чтобы попасть на компьютер, на роутере нужно пробросить порты (см. ниже).

Мне кажется, у меня слишком медленно работает сеть!

Измерьте скорость сети между двумя компьютера с помощью iperf . Можно воспользоваться этой инструкцией. В ней предлагают скомпиллировать программу из исходников, но можно просто установить её из репозитория. Если iperf покажет значение немного меньшее, чем ожидаемое, то с сетью всё в порядке, проблема может быть в железе (жёсткий диск/процессор не могут обеспечить большую скорость), в способе передачи (например, scp и ftp весьма неторопливы), в настройках (скорость может быть ограничена, например, настройками FTP -сервера) или в чём-то ещё. Если iperf показал величину, которая в разы меньше желаемой, то да - с сетью проблемы. Стоит посмотреть, в нужном ли режиме работает карта (например, с помощью ethtool ), проверить наличие «errors» в выводе ifconfig и протестировать скорость подключения к какому-нибудь третьему компьютеру.

Как узнать, какие программы слушают порты на моём компьютере?

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

Для вывода информации о конкретном порте можно использовать grep . Например, для 80 порта:

Из вывода netstat не всегда понятно, о какой программе идёт речь (например, 2671/python), подробнее о процессе расскажет ps :

Как присвоить два IP-адреса одной сетевой карте?

Например, интерфейсу eth0 нужно добавить адрес 192.168.1.1. Кратковременно, до перезапуска сети:

Навсегда — добавить в /etc/network/interfaces следующее:

Как пробросить порт?

Например, нужно пробросить порт 8081. Адрес, на который обращается клиент, назовём внешний_ip, а адрес, на который он должен попасть — внутренний_ip.

ppp (Paul's PPP Package) — пакет с открытым исходным кодом, который реализует протокол соединения точка-точка (PPP) для систем Linux и Solaris. Пакет предоставляет демон pppd, который может быть использован вместе с xl2tpd , pptpd и netctl.

Протоколы 3G, L2TP и PPPoE работают на основе PPP, поэтому они также могут контролироваться ppp.

Contents

Установка

Убедитесь, что ядро вашей системы скомпилировано с поддержкой PPPoE (верно для стандартной сборки):

Настройка

PPPoE

Создайте файл настроек соединения:

Если задана опция usepeerdns , при соединении pppd создаст файл /etc/ppp/resolv.conf с полученными адресами DNS-серверов. По умолчанию скрипт /etc/ppp/ip-up.d/00_dns перемещает этот файл в /etc/resolv.conf , чтобы система могла использовать эти DNS-серверы. Если это поведение является нежелательным (например, установлен локальный кэширующий DNS), отредактируйте /etc/ppp/ip-up.d/00_dns.sh под ваши нужды.

Добавьте запись с паролем соединения в /etc/ppp/pap-secrets или /etc/ppp/chap-secrets , в зависимости от типа аутентификации, используемого вашим провайдером. Если вы не уверены, можно добавить запись в оба файла, pppd выберет нужный самостоятельно. Запись выглядит следующим образом:

Имя пользователя должно совпадать с именем, указанным в опции name . Оно также используется для аутентификации, если не переопределено другим значением с помощью опции user .

Теперь вы можете попробовать установить соединение командой:

где имя_соединения — имя файла настроек, созданного в /etc/ppp/peers .

Чтобы убедиться, что соединение PPPoE установлено, проверьте вывод pppd в системном логе:

При успешном соединении вы увидите что-то наподобие следующих строк:

Файл настроек /etc/ppp/peers/provider используется по умолчанию, если при вызове pppd не было указано имя файла. Вместо явного указания имени файла настроек программе pppd вы также можете просто добавить символическую ссылку на свой файл:

Теперь можно устанавливать соединение одной командой

Чтобы разорвать соединение, выполните

Запуск pppd при старте системы

Выполните следующие шаги:

Дополнительно

Автодозвон

Если pppd запущен, вы можете выполнить сброс соединения, отправив процессу сигнал SIGHUP :

После разрыва соединение будет вновь установлено.

Примечание: Убедитесь, что опция persist включена в ваш файл конфигурации /etc/ppp/peers/provider . Также вы можете добавить параметр holdoff 0 для переподключения без тайм-аута.

Используя cron

Выполните следующие шаги от имени суперпользователя.

Создайте файл скрипта (например, pppd_redial.sh ) со следующим содержимым:

Сохраните файл и дайте ему права на выполнение.

Теперь создайте задачу для cron, используя команду crontab -e . Если появляется ошибка, убедитесь, что установлена переменная окружения EDITOR . По команде откроется редактор — добавьте в него строку, указав правильный путь до вашего скрипта перезапуска соединения:

Сохраните файл и убедитесь, что служба cronie работает. Если это не так, включите и запустите службу cronie .

Теперь ваше соединение будет перезапускаться каждый день в 4 утра.

Используя таймер systemd

Также вы можете настроить таймер systemd для выполнения ежедневного перезапуска соединения. Просто создайте файлы .service и .timer с одинаковыми именами:

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

Решение проблем

Маршрут по умолчанию

При запуске pppd пытается добавить свой системный маршрут по умолчанию (default route). Если перед запуском уже был установлен такой маршрут, pppd не станет его обновлять, и новые соединения во внешнюю сеть направляться не будут. При этом в /var/log/errors.log вы увидите что-то наподобие:

Если это поведение нежелательно, и xxx.xxx.xxx.xxx — совсем не то, что вам нужно, вы можете создать простой скрипт в /etc/ppp/ip-pre-up с таким содержимым:

Не забудьте дать скрипту права на запуск.

Маскарадинг работает, но некоторые сайты не открываются

Проблема решается добавлением правила с PMTU clamping в iptables:

Однако, по некоторой причине, это правило может не попадать в вывод iptables-save. Если у вас тот случай, когда iptables-restore не восстанавливает правило после перезапуска, попробуйте следующее решение.

Создайте файл службы systemd:

И включите эту службу.

Не удается загрузить модуль ядра ppp_generic

Проблема выражается в том, что при запуске процесс pppd не может найти соответствующий модуль:

Руководство по стеку протоколов TCP/IP для начинающих

Cтек протоколов TCP/IP широко распространен. Он используется в качестве основы для глобальной сети интернет. Разбираемся в основных понятиях и принципах работы стека.

Основы TCP/IP

Стек протоколов TCP/IP (Transmission Control Protocol/Internet Protocol, протокол управления передачей/протокол интернета) — сетевая модель, описывающая процесс передачи цифровых данных. Она названа по двум главным протоколам, по этой модели построена глобальная сеть — интернет. Сейчас это кажется невероятным, но в 1970-х информация не могла быть передана из одной сети в другую, с целью обеспечить такую возможность был разработан стек интернет-протоколов также известный как TCP/IP.

Разработкой этих протоколов занималось Министерство обороны США, поэтому иногда модель TCP/IP называют DoD (Department of Defence) модель. Если вы знакомы с моделью OSI, то вам будет проще понять построение модели TCP/IP, потому что обе модели имеют деление на уровни, внутри которых действуют определенные протоколы и выполняются собственные функции. Мы разделили статью на смысловые части, чтобы было проще понять, как устроена модель TCP/IP:


Уровневая модель TCP/IP

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

Канальный уровень (link layer)

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

Этот уровень также вычисляет максимальное расстояние, на которое пакеты возможно передать, частоту сигнала, задержку ответа и т.д. Все это — физические свойства среды передачи информации. На канальном уровне самым распространенным протоколом является Ethernet, но мы рассмотрим его на примере в конце статьи.

Межсетевой уровень (internet layer)

Каждая индивидуальная сеть называется локальной, глобальная сеть интернет позволяет объединить все локальные сети. За объединение локальных сетей в глобальную отвечает сетевой уровень. Он регламентирует передачу информации по множеству локальных сетей, благодаря чему открывается возможность взаимодействия разных сетей.

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

Маска подсети и IP-адреса


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

Протокол интернета — IP (Internet Protocol) используется маршрутизатором, чтобы определить, к какой подсети принадлежит получатель. Свой уникальный IP-адрес есть у каждого сетевого устройства, при этом в глобальной сети не может существовать два устройства с одинаковым IP. Он имеет два подвида, первым был принят IPv4 (IP version 4, версии 4) в 1983 году.

IPv4 предусматривает назначение каждому устройству 32-битного IP-адреса, что ограничивало максимально возможное число уникальных адресов 4 миллиардами (2 32 ). В более привычном для человека десятичном виде IPv4 выглядит как четыре блока (октета) чисел от 0 до 255, разделенных тремя точками. Первый октет IP-адреса означает его класс, классов всего 4: A, B, C, D.

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

Так как IPv6 адреса длинные, их разрешается сокращать по следующим правилам: ведущие нули допускается опускать, например в адресе выше :00FF: позволяется записывать как :FF:, группы нулей, идущие подряд тоже допустимо сокращать и заменять на двойное двоеточие, например, 2DAB:FFFF::01AA:00FF:DD72:2C4A. Допускается делать не больше одного подобного сокращения в адресе IPv6.

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

ICMP и IGMP


ICMP никогда не вызывается сетевыми приложениями пользователя, кроме случаев диагностики сети, к примеру, пинг (ping) или traceroute (tracert). ICMP не передает данные, это отличает его от транспортных TCP и UDP, расположенных на L3, которые переносят любые данные. ICMP работает только с IP четвертой версии, с IPv6 взаимодействует ICMPv6.

Сетевые устройства объединяются в группы при помощи IGMP, используемый хостами и роутерами в IPv4 сетях. IGMP организует multicast-передачу информации, что позволяет сетям направлять информацию только хостам, запросившим ее. Это удобно для онлайн-игр или потоковой передаче мультимедиа. IGMP используется только в IPv4 сетях, в сетях IPv6 используется MLD (Multicast Listener Discovery, протокол поиска групповых слушателей), инкапсулированный в ICMPv6.

Транспортный уровень (transport layer)

Постоянные резиденты транспортного уровня — протоколы TCP и UDP, они занимаются доставкой информации.

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

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

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

Протоколы L3 не интерпретируют информацию, полученную с верхнего или нижних уровней, они служат только как канал передачи, но есть исключения. RSVP (Resource Reservation Protocol, протокол резервирования сетевых ресурсов) может использоваться, например, роутерами или сетевыми экранами в целях анализа трафика и принятия решений о его передаче или отклонении в зависимости от содержимого.

Прикладной уровень (application layer)

В модели TCP/IP отсутствуют дополнительные промежуточные уровни (представления и сеансовый) в отличие от OSI. Функции форматирования и представления данных делегированы библиотекам и программным интерфейсам приложений (API) — своего рода базам знаний. Когда службы или приложения обращаются к библиотеке или API, те в ответ предоставляют набор действий, необходимых для выполнения задачи и полную инструкцию, каким образом эти действия нужно выполнять.

Зачем нужен порт и что означает термин сокет

Приложения прикладного уровня, общаются также с предыдущим, транспортным, но они видят его протоколы как «черные ящики». Для приема-передачи информации они могут работать с TCP или UDP, но понимают только конечный адрес в виде IP и порта, а не принцип их работы.

IP присваивается каждому компьютеру межсетевым уровнем, но обмен данными происходит не между компьютерами, а между приложениями, установленными на них. Чтобы получить доступ к тому или иному сетевому приложению недостаточно только IP, для идентификации приложений применяют порты. Комбинация IP-адреса и порта называется сокетом или гнездом (socket). Поэтому обмен информацией происходит между сокетами. Нередко слово сокет употребляют как синоним для хоста или пользователя, также сокетом называют гнездо подключения процессора.

Из привилегий у приложений на прикладном уровне можно выделить наличие собственных протоколов для обмена данными, а также фиксированный номер порта для обращения к сети. Администрация адресного пространства интернет (IANA), занимающаяся выделением диапазонов IP-адресов, отвечает еще за назначение сетевым приложениям портов.


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

Стек протоколов, снова канальный уровень

О канальном уровне модели TCP/IP мы рассказали меньше всего, давайте вернемся еще раз к началу, чтобы рассмотреть инкапсуляцию протоколов и, что значит «стек».

Большинству пользователей знаком протокол Ethernet. В сети, по стандарту Ethernet, устройства отправителя и адресата имеют определенный MAC-адрес — идентификатор «железа». MAC-адрес инкапсулируется в Ethernet вместе с типом передаваемых данных и самими данными. Фрагмент данных, составленных в соответствии с Ethernet называется фреймом или кадром (frame).

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

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

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

Point-to-Point протоколы


Отдельно расскажем о Point-to-Point (от точки к точке, двухточечный) протоколе также известном как PPP. PPP уникален по своим функциям, он применяется для коммуникации между двумя маршрутизаторами без участия хоста или какой-либо сетевой структуры в промежутке. При необходимости, PPP обеспечивает аутентификацию, шифрование, а также сжатие данных. Он широко используется при построении физических сетей, например, кабельных телефонных, сотовых телефонных, сетей по кабелю последовательной передачи и транк-линий (когда один маршрутизатор подключают к другому для увеличения размера сети).

У PPP есть два подвида — PPPoE (PPP по Ethernet) и PPPoA (PPP через асинхронный способ передачи данных — ATM), интернет-провайдеры часто их используют для DSL соединений.

PPP и его старший аналог SLIP (протокол последовательной межсетевой связи) формально относятся к межсетевому уровню TCP/IP, но в силу особого принципа работы, иногда выделяются в отдельную категорию. Преимущество PPP в том, что для установки соединения не требуется сетевая инфраструктура, а необходимость маршрутизаторов отпадает. Эти факторы обуславливают специфику использования PPP протоколов.

Заключение

Стек TCP/IP регламентирует взаимодействие разных уровней. Ключевым понятием в здесь являются протоколы, формирующие стек, встраиваясь друг в друга с целью передать данные. Рассмотренная модель по сравнению с OSI имеет более простую архитектуру.

Сама модель остается неизменной, в то время как стандарты протоколов могут обновляться, что еще дальше упрощает работу с TCP/IP. Благодаря всем преимуществам стек TCP/IP получил широкое распространение и использовался сначала в качестве основы для создания глобальной сети, а после для описания работы интернета.

Читайте также: