О провайдерах

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

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

Да, существовал тогда такой феномен, как домашние сети. Это когда энтузиасты кидали кабель к соседям. Ну, чтобы в игрушки сетевые поиграть. И мемасиками меняться. А те кидали кабель ещё к соседям. И таким образом получалась локальная сеть в пределах одного или нескольких соседних домов. Но без Интернета. Вот мы Интернет в такие сети и проводили.

Выдавали Интернет максимально честным способом. Мы покупали в Америке бэушные управляемые свичи 3Com. На eBay покупали. Тогда это был гораздо более простой челлендж, чем сейчас. Свичи с дюжиной 10-мегабитных портов, и парой «аплинков» на 100-мегабит. В 10-мегабитные порты втыкали компьютеры клиентов. А 100-мегабитные шли к нам, или к соседнему свичу. Да, 10-мегабитный интернет тогда было очень круто.

Управляемый свич — это такой свич, у которого есть свой IP адрес и несколько интерфейсов управления. Веб морда, telnet и чудесный SNMP. Как минимум, можно увидеть, а есть ли вообще линк на порту клиента, не заглядывая в ящик на чердаке, где свич стоит. Как максимум, можно свичом как-то порулить. Помню, мы в админку добавляли отображение статуса порта свича у клиента, получая данные с самого свича по SNMP.

Управляемый свич был нужен ради одной важной функции: автоматической блокировки портов. Свич, как любой нормальный свич, ведёт у себя таблицу MAC адресов. На каком порту какой MAC адрес наблюдается. И, соответственно, на какой порт отправлять Ethernet фреймы, отправленные этому MAC адресу. А в управляемых свичах можно ограничить количество MAC адресов на порту. И даже сделать так, чтобы порт отключался, если на нём появляется слишком много MAC-адресов или какие-то адреса, не запомненные заранее.

Схема такая. Пользователь получает свой статический серый IP адрес. Ручками прописывает его на своей сетевой карте. DHCP мы не использовали, так как в домашних сетях было очень легко, даже случайно, поднять свой DHCP сервер. А так как до нашего, провайдерского, DHCP сервера было сильно дальше, чем до соседей, то нехороший сосед легко мог навыдавать IP адресов через DHCP всем своим соседям. И лишить их Интернета, понятно.

Имеем статический IP адрес. И MAC адрес сетевухи пользователя. MAC адрес прибивается к порту свича через ту самую фишку с блокировкой портов. А на сервере заводится статическая ARP таблица, жёстко задающая соответствие MAC и IP адреса каждого клиента. Доступ к Интернету и учёт трафика происходит по IP адресу. Вуаля.

Весь учёт идёт по IP адресу. Но пользователь не может поменять IP адрес или взять IP адрес другого пользователя, тогда Интернет перестанет работать, потому что на маршрутизаторе этот IP адрес связан с другим MAC адресом. Пользователь также не может взять MAC адрес другого пользователя, потому что в этом случае его порт на умном свиче будет заблокирован.

С точки зрения пользователя всё просто и удобно. Обычный статический IP адрес. Пользователи домашних сетей умели такое настраивать. И MTU полноценный в 1500 байт.

С точки зрения провайдера всё немного непросто. Нужно и свичи управляемые, и настроить их. Нужна статическая ARP таблица. Зато потом простой учёт и блокировка пользователей просто по IP адресам. Ну и NAT нужен, один раз. Зато, если есть более одного аплинка, можно выпускать пользователя куда удобнее, там, где дешевле.

Почти что лучшее подключение к интернетам ever. Лучше только полновесные IPv6 каждому пользователю. Но IPv6 тогда, можно сказать, не было. А белых IPv4 никто юзерам, конечно же, не раздавал.

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

С управляемыми свичами это можно без дополнительных ухищрений. Но управляемые свичи — дорогое удовольствие. Они у нас таки кончились. А когда у тебя на одном управляемом порту висит десяток пользователей, подключенных через неуправляемые свичи, ты уже не можешь их достоверно различить. Поэтому позднее мы водрузили VPN. Не помню, какой именно. Кажется, тот, который работал из коробки в Windows. К VPN мы ещё вернёмся...

Получается, если вы не можете воткнуть каждого пользователя в управляемый порт, вам надо как-то выкручиваться. Всё ещё любимый мною ЭР-Телеком (ака Дом.ру) выкручивается с помощью PPPoE.

Немного вернёмся к основам. PPP, Point-to-Point Protocol — это такой специальный протокол, который позволяет (в частном случае) передавать IP пакеты от одного узла к другому (поэтому Point-to-Point). Этот протокол отвечает за установления соединения (существует понятие коннекта), за аутентификацию (есть механизмы передачи и проверки пароля), за передачу сетевого трафика (не только IP, но нас интересует IP). Ещё через PPP эти самые point получают IP адреса в рамках PPP соединения (отдельный DHCP не нужен).

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

PPP используется во многих VPNах. Например, в OpenVPN именно PPP запускается после того, как установлен туннель между клиентом и сервером, и дальше весь обмен трафиком идёт через PPP. Именно поэтому в OpenVPN нужно явно подключаться к серверу, и отключаться. А вот в других, более «сетевых» «VPN», вроде Tinc или WireGuard, PPP не используется, и нет понятия «установки соединения».

Так вот, PPPoE — это PPP over Ethernet. Не поверх различных IP туннелей, как в VPN. А прямо поверх Ethernet. То есть PPP инкапсулируется в Ethernet фреймы.

Пользователь ставит у себя маршрутизатор, втыкает в него Ethernet кабель. Этот кабель идёт прямо к оборудованию провайдера. И настраивает PPPoE. PPPoE сервер провайдера доступен в той же локальной сети по MAC адресу. Маршрутизатор пользователя подключается к PPPoE серверу провайдера, аутентифицируется там, и начинает гонять IP трафик. Все довольны. Но MTU чуток урезается.

Тут есть нюанс безопасности. Другой пользователь в этой же сети может тоже поднять у себя PPPoE сервер. И тут, как и с DHCP, кто раньше ответит, того и тапки. Конечно, раздавать интернеты через свой PPPoE злобному пользователю довольно бессмысленно. Но вот стащить пароли он может. Поэтому нужно запрещать PAP (где пароль передаётся открытым текстом) и использовать CHAP (где передаётся солёный дайджест пароля).

PPP удобен для провайдера тем, что тут есть сеанс работы пользователя. Который начинается с подключения и аутентификации. И заканчивается разрывом соединения (не было разрывов!) В течение всего этого сеанса за пользователем закреплён не только IP адрес, но и целый сетевой интерфейс (того самого PPP). И на этом интерфейсе очень удобно считать трафик (правда, чаще всего данные снимаются лишь при завершении соединения, отсюда и разрывы раз в сутки). Есть тонны учётного софта, которые заточены именно на учёт PPP сеансов.

PPPoE, по сравнению с более другими настоящими VPN, хорош минимальными издержками. У нас нет ещё одного слоя IP. И мы не гоняем IP поверх IP. Всё просто и логично.

Дом.ру прекрасен вот ещё чем. Если вы захотите (отключите NAT у провайдера в личном кабинете), то через PPPoE он будет выдавать белый IP. То есть на вашем маршрутизаторе будет реальный доступный из интернетов IP адрес. Идеально, если вы хотите держать дома сервер. Ну, правда, адрес каждый раз будет разным, при каждом переподключении. Но это более-менее лечится с помощью dynamic DNS. А за дополнительные деньги вам выдадут и статический адрес. Ну и IPv6 тоже можно, правда, с кривоватыми префиксами.

В таком варианте, когда на ваш домашний маршрутизатор приходит настоящий IP адрес, пусть и через PPPoE, необходим лишь один NAT. Адресов вашей домашней сети в интернеты, на вашем домашнем маршрутизаторе. Или вообще без NAT, если IPv6. Это очень удобно и хорошо. UPnP и раздача торрентов работают идеально.

Но это всё в Омске. А в Астане Дом.ру нет. Тут вообще подозрительно часто встречается ADSL.

xDSL (x Digital Subscriber Line) — так часто называют семейство протоколов для передачи трафика по паре медных проводов. Тех самых, что используются в телефонии. Только в обычных модемах используется частотный диапазон человеческой речи, сигналы модема передаются вместо голоса. В результате максимальная скорость получается лишь 56 кбит/с (я помню, да). Зато с точки зрения телефонного оборудования (АТС), ничего не меняется. Дозвонились до абонента, и затем говорите человеческим голосом или шипите модемом, без разницы.

Но те же самые телефонные провода вполне можно пробросить из точки А в точку Б. Например, арендовать пару проводов в телефонных кабелях, которые протянуты в колодцах по всему городу. Это называется «выделенная линия». И вот на обоих концах этой линии можно подключить SDSL модемы. Symmetric DSL. Скорость там получается уже порядка двух мегабит в секунду, на расстояниях в несколько километров.

Но для подключения обычных частных абонентов используется ADSL. Asymmetric DSL. Есть ATC. От неё к абонентам уже протянут телефонный кабель. А у абонентов уже стоят телефонные аппараты. Когда по телефону никто не разговаривает, эти провода, по сути, лежат без дела. Ну давайте воткнём на АТС специальное сетевое оборудование (так называемый DSLAM, DSL Access Multiplexer). А у абонента поставим ADSL модем. И смотрите, теперь по этим проводам можно гонять сетевой трафик на приличной скорости. И даже одновременно с телефонными разговорами (частотное разделение сигналов).

ADSL — это целое семейство очень хитрых протоколов. Там есть оптимизация, чтобы сигналы в соседних парах одного кабеля не мешали друг другу. Там учитывается то, что кабели расходятся от АТС к абонентам, а значит, наибольшие взаимные помехи наблюдаются ближе к АТС. Отсюда проистекает ассиметричность (буква A в названии) протоколов. Ассиметричность в скорости. От АТС к абоненту (download) получается добиться аж 24 Мбит/с. А вот от абонента к АТС (upload) — лишь 3.5 Мбит/с максимум. Ну, ADSL делали уже с оглядкой на структуру трафика этого нашего Веба. Так что тут всё правильно, что даунлоад быстрее.

Меня всегда удивляло, что внутри ADSL, по какой-то неведомой причине, прижился протокол ATM. Когда-то ATM был перспективным крутым протоколом, который собирался соперничать с Ethernet. Но Ethernet не сдавался и наращивал скорость. И ATM как-то тихо помер. Но остался жить, вот, в ADSL. Там очень много слоёв протоколов. Те же фреймы Ethernet могут передаваться поверх ячеек ATM. И таки где-то сверху снова возникает наш вездесущий PPP.

24 Мбит/с (и это только при правильной фазе Луны) по нынешним временам — ну, не очень быстро. Поэтому, если можно получить интернеты не по телефонной линии, нужно получать не по телефонной линии.

Как правило, к дому тянут оптоволоконный кабель. А дальше по дому либо обычный UTP до каждой квартиры, либо тоже оптику. В любом случае в квартире появляется маршрутизатор, либо с RJ45, либо с каким-то оптическим портом (или внешним конвертером). Так как я оптику у себя в квартире так и не видел, мне сложно понять, какой из вариантов FTTx в реальности используют. Маршрутизатор таки всё равно получает Ethernet.

Возвращаемся к нашим Билайнам. Тут нет PPPoE. А как же происходит аутентификация и учёт трафика? А через L2TP. Нормальный такой VPN. Не хуже OpenVPN. Работает поверх IPsec.

Что тут плохого? Во-первых, полноценный IPsec требует заметных вычислительных ресурсов на маршрутизаторе. Говорят, когда Билайн только начал подключать домашний интернет, пользователи бегали, искали маршрутизаторы помощнее, чтобы L2TP не тормозил. Во-вторых, вот как выглядит подключение на маршрутизаторе:

Сначала поверх Ethernet мы получаем по DHCP некий серый адрес (10.160.х.х в данном случае). TP-Link называет это вторичным подключением. Интернета тут быть не должно. Но должен работать DNS, чтобы отрезолвить имя L2TP сервера (l2tp.internet.beeline.kz). Причём это должны быть какие-то приватные DNS сервера. Ведь у этого L2TP сервера должен быть приватный адрес. Или же нужно проковырять из этой серой сети доступ к L2TP серверу. Во всяком случае, в публичных интернетах вы адрес этого сервера не отрезолвите. Слоожно (с точки зрения организации всего этого).

А теперь, получив адрес и доступ к L2TP серверу, мы к нему подключаемся. Аутентифицируемся логином-паролем, тут же снова PPP у нас.

И, сюрприз-сюрприз, через L2TP/PPP мы получаем ещё один серый адрес (10.215.x.x). И настроек, чтобы это как-то поменять, я не нашёл. Точнее, есть опция со статическим IP адресом, +70% к стоимости тарифа. Дороговато.

Что значит ещё один серый адрес? А это значит, что провайдер будет делать NAT. Всего получается два NATа. Один на нашем домашнем маршрутизаторе, нашу внутреннюю сеть в серый адрес, выданный провайдером. Второй на маршрутизаторе провайдера, серый адрес в настоящий IP.

Чем плох двойной NAT? Во-первых, узнать свой реальный IP можно только извне. Например, через curl ifconfig.me.

Во-вторых, нужно помнить, как работает NAT. Это очень stateful штука. Он отслеживает все IP/TCP/UDP соединения. Помнит, какой клиентский IP/порт каким публичным IP/портом он выставил наружу. Если какие-то хитрые протоколы NAT не может отследить, они через NAT работать не будут. Чтобы помнить все соединения нужна память. И, если домашний маршрутизатор уж как-нибудь справится со всеми пятью домашними устройствами. То маршрутизатору провайдера нужно работать с тысячами клиентов и десятками тысяч соединений.

Когда пакеты долго не ходят, или когда банально маршрутизатору не хватает места для хранения новых соединений, он будет удалять записи. Это приводит к тому, что старые соединения просто отваливаются. У меня, например, стали отваливаться неактивные ssh подключения. Подключился, потом на что-то отвлёкся на полчаса, возвращаешься, а терминал уже ни на что не реагирует, соединение зависло. Решение: добавить в ~/.ssh/config строку ServerAliveInterval 60. Чтобы ssh раз в минуту посылал пустой пакет по сети. Собственно, всякие keep alive штуки во всяких разных протоколах, включая даже VPN, и были добавлены, чтобы бороться с протухающим NAT.

Кстати, залипшее ssh подключение можно принудительно закрыть с помощью комбо: Enter, ~, . (нажать последовательно). Есть и другие последовательности.

Чем Билайн хуже Дом.ру? Относительно «тяжёлый» L2TP вместо «простого» PPPoE. В два раза больше серых IP адресов. Двойной NAT, без покупки статического IP я не могу поднять дома сервер. Отсутствие IPv6. Мне, как айтишнику, обидно.

Зато за те же деньги я получаю ещё и мобильную связь. А при хорошем и грамотно настроенном маршрутизаторе (не экономьте на CPU) разницы при просмотре ютубов, в общем-то, и не будет.