Данная статья является продолжением темы обсуждавшейся в статье «Философия борьбы с NAT» и так же нацелена на сетевых разработчиков, С++ программистов и просто интересующихся тенденциями развития интернет индустрии. Предполагается, что читатель в общих чертах знаком с моделью OSI, с протоколами UDP и TCP, знает что такое NAT, понимает принципы его работы и конечно же читал предыдущую статью.
Фукуяма
Известный философ Фрэнсис Фукуяма в 1992 году объявил о наступлении «конца истории» и начале эры процветания и благоденствия. По его мнению победа западной глобализационной модели над советской должна была снять все ключевые противоречия человечества, упразднить фундаментальные причины для глобальной борьбы. Следующие десятилетия и особенно последние годы наглядно опровергли эту теорию. История не остановилась, борьбы не стало меньше, борьба даже не стала мягче. На самом деле недостаточно просто победить противника, необходимо еще установить контроль над его пространством. А это куда более серьезная проблема на которую нужен значительный ресурс. В старые добрые времена это решали традиционно с помощью армий, оккупационных или колониальных администраций, лоялизацией местных элит или их обнулением, приведением к власти своих «сукиных сынов» и т. п. Попросту говоря с помощью человеческого ресурса, который по определению дорогой, а его эффективность падает с ростом масштаба и сложности системы управления. Во время «холодной войны» наверное впервые основной упор был сделан на социальную инженерию, на управление инстинктами людей, а не силу оружия или админресурс. Тем не менее и этого оказалось мало для безоговорочной победы. Цифровая революция принесла новые возможности. Интернет и социальные сети концентрирующие информацию, прозрачность цифровой жизни людей, все более вытесняющей реальную, эффективность цифровой обработки информации, искусственный интеллект, возможность целевого применения когнитивных технологий — все это создало гигантские возможности для управления и контроля. Тот кто победит на новом витке глобальной борьбы непременно их реализует и тогда вполне может наступить тот самый «конец истории». Но не факт, что наступит благоденствие, а свобода на станет мнимой. С каждым годом мир все больше напоминает нечто среднее между стеклянным городом из романа Замятина «Мы» и виртуальным миром «Матрицы».
Как я упоминал в предыдущей статье проблема вытекает из гиперцентрализованности социального сегмента сети Интернет. Социальные сети это по сути огромные хабы информации подконтрольные частным корпорациям, далеко не всегда социально и политически нейтральным, имеющим собственные интересы. Это создает идеальные условия для сбора, анализа, продажи, кражи информации и вытекающих из этого разнообразных манипуляций. Взломы и скандалы с утечками личных данных стали уже обыденностью. Пора всерьез задуматься над растущей проблемой утраты естественного права человека на защиту своего пространства от постороннего вмешательства.
NAT и TCP
Я уже отмечал, что расширение применения технологий peer‑to‑peer это тот компромисс, который может помочь решить назревающие проблемы, но на его пути стоит камень преткновения под названием NAT. Но нельзя сказать, что NAT это плохо или какой‑то анахронизм. Он, хотя и порожден ограниченным адресным пространством IPv4, вряд ли уйдет вместе с ним. Потому, что не исчезнет потребность в локальных сетях и сетевом фаерволе. Однако границы физических сетей и социальных редко совпадают. В таких случаях NAT является преградой стимулируя использование ресурсов третьих сторон для выстраивания социальных связей. Поведение NAT по отношению к сетевым протоколам не стандартизировано четко, но как правило он лоялен к протоколу UDP в силу его вещательной специфики. Говорят также, что на это повлияли компании предоставляющие услуги IP телефонии, которым невыгодно нагружать трафиком абонентов собственные сервера, что в конечном итоге вылилось в появление протоколов STUN/TURN/ICE, технологии UDP hole punching и поспособствовало развитию p2p. Тем не менее основным протоколом интернета является TCP, а к нему NAT не очень дружелюбен, в чем я лично убедился разрабатывая утилиту plexus. Напомню, что утилита задумывалась как универсальный инструмент позволяющий соединять приложения работающие за NAT. Прекрасно справляется с этим для протокола UDP, но для TCP ожидаемо работает нестабильно. Причина в том, что TCP это протокол с установлением соединения и поддержкой состояния и провайдеры как правило настраивают для него строгие правила на NAT с учетом состояния. Следовательно любой чих, будь то пакет RST, FIN, не пришедший вовремя ACK в ответ на SYN или ошибка ICMP, является достаточным основанием для NAT сбросить текущую запись в таблице. Кроме этого на фаерволе обычно разрешают только исходящие SYN пакеты и пробить «дыру» таким пакетом изнутри, а потом принять входящее соединение тоже не всегда возможно. Прохождение NAT для TCP по аналогии с UDP hole punching работает очень ненадежно. Выходом из положения может быть использование VPN поверх UDP, однако такой подход нельзя назвать универсальным. Это прекрасное решение, если обе стороны соединения полностью доверяют друг другу. В противном случае нужно позаботиться о правилах локального фаервола, чтобы не открыть ненароком чего не следует. С другой стороны VPN не очень удобен в контексте построения пиринговых сетей. Использование центрального сервера нивелирует саму концепцию пиринговых сетей, а создание peer‑to‑peer VPN туннелей между участниками сети требует механизма согласования виртуальных адресов во избежание конфликтов. К этому можно добавить необходимость повышенных привилегий для приложений работающих с виртуальными интерфейсами. Немаловажно и то, что во многих странах ограничивают использование VPN. Решением вопроса мог бы стать сетевой туннель поверх UDP, лишенный избыточности VPN, не требующий привилегий администратора, с встроенной возможностью обфускации. Последнее важно потому, что открытость сетевых протоколов это серьезная фора для киберпреступников. Это я и попытался реализовать в утилите wormhole расширяющей возможности plexus для работы с TCP приложениями.
Кротовые норы
Принцип работы wormhole схож с перенаправлением портов. С той разницей, что порт локального интерфейса связывается не с портом маршрутизатора, а с сервисом удаленной машины основанном на TCP протоколе. Таким образом можно подключаться к удаленной службе так словно она локальная. Работа wormhole под капотом изображена на схеме.
Импортирующий и экспортирующий экземпляры утилиты создают UDP туннель между машинами на указанных эндпоинтах достижимых обеими сторонами. После создания туннеля сторона импортирующая службу удаленного хоста на заданном локальном эндпоинте запускает проксирующий TCP сервер ретранслирующий данные подключающихся клиентов в туннель и обратно клиентам. Экспортирующая сторона обнаруживая в туннеле новые подключения создает для них локальных проксирующих TCP клиентов и ретранслирует через них данные полученные из туннеля к конечной службе и обратно. Типологически это напоминает известную хакерскую технику MITM. Разумеется здесь это безопасно, в чем не трудно убедиться, код проекта открытый. Считаю, что opensource это принципиальное требование для любых сетевых приложений. Код утилиты основан на библиотеке Boost.Asio, тот кто с ней знаком без труда сориентируется.
Учитывая, что в wormhole ретранслируются не пакеты, а данные прикладного уровня, то потеря и гонки пакетов в UDP канале недопустимы. Для туннеля был разработан нехитрый протокол под названием tubus, задачей которого является обеспечение того, что обычно обеспечивает TCP. Это поддержка состояния соединения, гарантия доставки и последовательности данных, двунаправленность потоков. Свое название он получил за возможность самообфускации. Достигается это с помощью 64-битного PSK (pre‑shared key) ключа. При использовании wormhole вместе с plexus в качестве ключа можно использовать идентификационный ключ, который вычисляется plexus в процедуре преодоления NAT. Нужно отметить, что это нельзя рассматривать как шифрование канала. Размер ключа для этого явно маловат, а алгоритм обфускации нацелен исключительно на то, чтобы сделать протокол и структуру передаваемых данных непрозрачными в рантайме. Ответственность за шифрование данных лежит на службах использующих туннель, на wormhole такие задачи не возлагаются.
Параметры коммандной строки wormhole:
--purpose=export|import — задает роль для локального экземпляра приложения;
--service=ip:port — эндпоинт экспортируемой или прокси импортируемой службы;
--gateway=ip:port — эндпоинт udp туннеля локального хоста;
--faraway=ip:port — эндпоинт udp туннеля удаленного хоста;
--obscure=number — 64-битный ключ обфускации udp туннеля.
Представим, что сисадмину Иванову нужно предоставить внешний доступ по ssh юзеру Петрову к внутренней машине корпоративной сети, но Петров находится в командировке в экзотической стране где плохо относятся к VPN.
Пример конфигурации plexus на стороне экспортирующей ssh сервер с утилитой wormhole в качестве полезной нагрузки.
~$: cat ssh_export.plex
accept=1
host-id=ivanov_ssh_server
peer-id=petrov_ssh_client
email-smtps=smtp.company.su:465
email-imaps=imap.company.su:993
email-login=ivanov@company.su
email-passwd=ivanov12345 # очень криптостойкий пароль сисадмина Иванова
email-from=ivanov@company.su
email-to=petrov@company.su
stun-ip=stun.ekiga.net
bind-ip=192.168.1.101
bind-port=5000
exec-command=wormhole # утилита wormhole в качестве полезной нагрузки
exec-args=--purpose=export --service=127.0.0.1:22 --gateway=%innerip%:%innerport% --faraway=%peerip%:%peerport% --obscure=%secret% --log-level=infoЗапуск...
~$: plexus --config=./ssh_export.plexПример зеркальной конфигурации plexus на стороне импортирующей ssh сервер.
~$: cat ssh_import.plex
accept=0
host-id=petrov_ssh_client
peer-id=ivanov_ssh_server
email-smtps=smtp.company.su:465
email-imaps=imap.company.su:993
email-login=petrov@company.su
email-passwd=petrov12345 # очень криптостойкий пароль юзера Петрова
email-from=petrov@company.su
email-to=ivanov@company.su
stun-ip=stun.ekiga.net
bind-ip=192.168.0.101
bind-port=5000
exec-command=wormhole # утилита wormhole в качестве полезной нагрузки
exec-args=--purpose=import --service=127.0.0.1:2222 --gateway=%innerip%:%innerport% --faraway=%peerip%:%peerport% --obscure=%secret% --log-level=infoЗапуск...
~$: plexus --config=./ssh_import.plexЕсли все прошло успешно, то в консолях можно будет увидеть записи о старте приложения с описанием заданных параметров, об успешном создании туннеля и об ожидании подключения очередного TCP‑клиента на импортирующей стороне. Можно запускать параллельную консоль и подключаться к импортированной службе.
~$: ssh -p 2222 petrov@127.0.0.1При возможности и необходимости ничто не мешает использовать wormhole автономно.
Проект plexus: https://github.com/novemus/plexus
Расширение wormhole: https://github.com/novemus/wormhole
При обнаружении изъянов и багов смело открывайте тикеты в репозиториях.
Спасибо за внимание.
Комментарии (24)
qw1
00.00.0000 00:00NAT-устройства, допускающие Hole Punching, впору заносить в Красную книгу.
Что дешёвый массовый DIR-615, который провайдеры всем абонентам бесплатно раздают, что роутеры Mikrotik для настоящих эстетов — всё это не пробивается.
Интересно, автор свою библиотеку на каком ретро-железе тестирует?
novemix Автор
00.00.0000 00:00Автор тестирует на самом обычном железе, в том числе на дешевых роутерах раздающихся провайдерами. Но при чем здесь домашние роутеры. Комментатор видимо плохо ориентируется в вопросе.
qw1
00.00.0000 00:00Когда-то давно я пробовал запускать тесты STUN, у меня не получалось ни каком оборудовании, и я запомнил, что nat-ы сейчас плохо пробиваются и на это нельзя расчитывать. Возможно, я что-то делал неправильно.
novemix Автор
00.00.0000 00:00+1У вас есть шанс без танцев с бубном проверить это сейчас. А, если что-то пойдет не так, собрать сессию wireshark, отладочные логи plexus, открыть тикет в репозитории. Буду признателен.
qw1
00.00.0000 00:00Сейчас я на Mikrotik наблюдаю «Port restricted NAT». А ведь когда-то был Symmetric. Из-за обновления версии OS, возможно.
novemix Автор
00.00.0000 00:00На самом деле и Symmetric не приговор, если на NAT политика отображения внутреннего порта на внешний Independed. То есть при выходе в интернет с одного локального порта на разные адреса всегда выдается один и тот же внешний эндпоинт.
fk0
Не VPN, но по-сути -- тот же VPN.
Вопрос пробивки NAT не рассмотрен. Как я понимаю, в отдельных случаях он просто не решаемый. В других требует чудовищных усилий (перебрать 64к портов и попасть в нужный). Тут кто-то писал на эту тему.
Вариант же из прошлой статьи, со STUN-сервером, очевидный и одновременно чаще бесполезный. Во-первых нужен сервер (в децентрализованной сети...) Во-вторых запросто не сработает, не для "full cone" NAT, как помнится.
И в-третьих в модели обслуживания провайдером ты должен ходить и смотреть иви, рутуб, мейл.ру и вконтакт. А не обмениваться файлами. Поэтому траффик между абонентами можно принудительно заблокировать в фаерволе. И для обмена между абонентами одного опсоса, например, потребуется кто-то третий, на стороне, выступающий в роли прокси. Маршруты не обязательно должны быть прямыми.
Будь так просто, любой школьник клал бы выходной узел любого интернет провайдера, просто рассылая подходящие пакеты. А там не просто, там надо, чтоб многое совпало.
novemix Автор
Это было рассмотрено в прошлой статье. Для TCP подход почти тот же, но он работает так себе.
Интерсно, на чем основаны такие безаппеляционные утверждения. Просто потролить.
Работает и для симметричного NAT. Но смотря что вы понимаете под "full cone".
Вот здесь вашу мысль совсем не уловил. Какая связь между "иви, рутуб, мейл.ру и вконтакт" и проблемой преодоления NAT для, к примеру, удаленного доступа к машине за NAT.
homeles
так у провайдеров тоже NAT есть - 99% домашнего народа ходят в инет под одним внешним адресом из "Нижнего Новгорода"... "Поэтому траффик между абонентами можно принудительно заблокировать в фаерволе " - элементарно, очень многое количество точек доступа WiFi имеют дефолтное правило на запрет прямых коммуникаций между двумя подключенными беспроводными абонентами. Так и с провайдерами - изоляцию портов никто не отменял. Да и не отменят просто так, а то получат иски - "меня соседский Вася взломал,а вы почему это допустили"
P.S. - двойной NAT тоже неплохо практикуется... Как начнешь traceroute делать - так из своей 192.168.... подсетки через пару-тройку других подсеток маршрут идет....
novemix Автор
Спора нет. Функцию hairpin не все провайдеры реализуют. Но это ведь не повод отступать. Само собой 100%-ю надежность без вспомогательных релейных сервисов не обеспечить. В конечном счете пути движения трафика менее важны, чем безопасность коммуникаций, внешние службы должны быть заменяемыми, играть чисто техническую роль.
homeles
так в чем у вас преимущество ??? VPN вы вроде как не переплюнули.... По необходимости - народ таки допилит Ethernet-over-IP (на уровне L2) - спрос вроде есть. "Проходимца" через NAT - так есть и TeamViewer, Hamachi и т.п. Не во всех случаях нужен прямой "коннект" между сетями
novemix Автор
Преимущество перед чем? С VPN я не конкурирую, а указал, что он не удобен в контексте решений для построения p2p сетей, как альтернативы централизованным, что и является предметом моих изысканий. Мотивацию я изложил ясно. Разумеется такой сложный вопрос не может быть решен в пару утилит, которые по сути лаборатория, proof of concept. Но все реки начинаются с ручьев. Как убежденный сторонник opensorce делюсь с сообществом. Кому интересно, пользуйтесь и развивайте.
fk0
Для обхода ограничения на hairpin именно сервер релейный не нужен. Достаточно третьего "клиента", согласившегося прокачать траффик между двумя другими, если они неудачно оказались в одной провайдерской сети. Ну и если NAT между всеми тремя удалось пробить.
KanuTaH
Это не говорит о том, что там есть NAT.
novemix Автор
Чем так проблематичен двойной NAT? По сути он почти всегда двойной. Первый на домашнем роутере.
fk0
Может возникнуть ситуация, что две машины находящиеся в сети одного оператора связи не смогут в принципе соединиться напрямую. Потому, что с точки зрения бизнес-логики такие соединения во-первых не нужны вовсе: оператор связи подразумевает связь не между любыми абонентами, как в телефонной сети, а связь абонента с организациями-поставщиками развлекательных и телевизионных услуг, очевидно же.
Связь между абонентами нужна только для бизнес-клиентов (VPN между филиалами организаций, сайты, организация сама может быть "поставщиком услуг" и т.п.) Домашнему пользователю это всё ни к чему.
Во-вторых траффик между абонентами представляют только проблему: например, когда только появился GPRS, опсосы ничего не фаерволили, но исправно считали траффик, и из-за виндовой вирусни у соседних абонентов у себя траффика набегало немеряно, а за него платить -- сейчас такой проблемы нет, как решили не знаю. Было бы интересно, чтоб кто-то просветил. Ну и очевидно, что зарезав траффик между абонентами провайдер эффективно избавляется от любителей торрентов и прочих проблемных клиентов (от которых денег как и остальных, а канал забивают -- в 100 раз больше).
Имел ввиду симметричный NAT. Читал предыдущую статью (https://habr.com/ru/post/681432/), но всё равно ничего не понял: на стадии 4, когда отправляется пакет с малым TTL, сам отправитель не знает с какого порта он отправится. Значит и ответный пакет на шаге 6 может быть откинут на зелёном NAT'е. Потому, что внешний адрес совпал, а порт в который слать надо -- не известен. И он запросто может не совпадать с портом на шаге 3.
Там же в статье есть заметка, что:
Но если мы посмотрим определение symmetric NAT в Wikipedia, например, то увидим, что полностью симметричный NAT не совсем соответсвует определению из википедии:
The combination of one internal IP address plus a destination IP address and port is mapped to a single unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used.
(https://en.wikipedia.org/wiki/Network_address_translation).
В переводе на русский:
Symmetric NAT. До недавнего времени это была наиболее распространённая реализация. Его характерная особенность – в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 – ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже."
Для преодоления симметричных NAT существуют какие-то мрачные методы основанные на массовом спуфинге (https://www.researchgate.net/profile/Yuan-Wei-24/publication/228411948_A_New_Method_for_Symmetric_NAT_Traversal_in_UDP_and_TCP/links/00b49534cb243e3062000000/A-New-Method-for-Symmetric-NAT-Traversal-in-UDP-and-TCP.pdf?origin=publication_detail).
Или манипуляциями с ICMP: https://samy.pl/pwnat/
На хабре же была статья (https://habr.com/ru/post/155803/), где утверждалось, что:
Выглядит не очень...
novemix Автор
В википедии и вообще в сети, особенно в рунете о типах NAT информация довольно устаревшая. Четыре известных типа описывают политику фильтрации по отношению к входящим пакетам. И здесь ничего не поменялось, причем symmetric по прежнему наиболее частный. Кроме политики фильтрации, есть еще и политика назначения адреса-порта. Ключевой момент предсказуемость, не обязательно с первого захода. Когда вы обращаетесь к внешней службе NAT назначает вам внешний адрес. Если вы повторно обратитесь к другой внешней службе, но с того же локального адреса-порта какой адрес-порт выдаст вам NAT? Практика, на доступных мне 4-5 провайдерах показала, что все выдают тот же адрес-порт, что был выдан для первого раза. А некоторые провайдеры даже стараются выдать такой же номер порта как и локальный. Порты могут совместно использоваться, для UDP это норма самого протокола. Разумеется, провайдеры могут настроить иное поведение, но как я выше указал, пока с подобным не сталкивался. Надеюсь на обратную связь всех кто будет использовать plexus, чтобы составить более объективную картину.
Случай, когда обе стороны находятся в сети одного провайдера называется hairpin. И действительно, редко провайдеры дают такую возможность. Для таких случаев естественно нужны альтернативные решения.
fk0
Но это же не провайдером определяется, а используемой аппаратурой (маршрутизаторами) и программным обеспечением. И вот в статье по ссылке автор показал как в обычном линуксе можно сделать всё совсем не так с помощью обычного iptables (https://www.man7.org/linux/man-pages/man8/iptables-extensions.8.html#TARGET_EXTENSIONS, опция --random).
И в каких-нибудь сейчас массово закупленных цисках нет рандомизации. Завтра цисок продавать не будут (санкции) и вместо цисок будет линукс. И там кто-то впишет --random...
А вот что juniper пишет для своих роутеров:
Так что рандомизация есть более-менее массово и где-то используется, где-то нет. Там же пишется, что мол рандомизация ведёт к деградации перформанса и использования памяти. Вот потому и выключают.
В целом на отсутствие рандомизации положиться нельзя, я думаю.
Более того, сейчас нас прочитают сотрудники провайдеров и им придёт в голову светлая мысль, что включение рандомизации позволит прижать хвост любителям торрентов.
novemix Автор
Рандомизация как правило у всех провайдеров, но для первого обращения вовне. Вопрос в том как NAT реагирует, если прежний маппинг для вашего эндпоинта еще жив. Вот здесь я с рандомизацией пока не сталкивался. Не факт, что ее не существует. Но надо понимать, что, если провайдеры прикроют эту лазейку, то Роскомнадзор или кто там за это отвечает будет завален жалобами от компаний IP телефонии, мессенджеров и т.п., а это не шарашкины конторы, ибо им придется весь трафик абонентов гонять через свои сервера. Слышал, что именно поставщики IP телефонии и пролоббировали эту лазейку. На самом деле Udp hole punching много где и успешно используется. Разумеется не всегда можно обойтись без релейных ресурсов.
qw1
fk0
Опсосы которые одновременно являются провайдерами с радостью прижмут всю ип-телефонию. Только дай возможность. Иди на мобильный тариф и звони по межгороду. Только вот как раз проксировать весь SIP-траффик через собственные серевра -- не велика задача. За него же абонент платит. Проблема это там, где бесплатно. Мессенджеры -- аналогично, только там деньги через рекламу и т.п. P2P там нет давно. P2P был в Скайпе, когда он был эстонским.Лет 15 тому назад. Ну и всякие файлообменные сети. Ну так они без внешнего IP и работают плохо.
Для иностранных поставщиков IP-телефонии и систем видеоконференций может быть немножко неудобно -- серверов в РФ нет, а голосовой и видео-траффик гонять в Америку и обратно -- задержки. Им наверное удобны прямые соединения и фоллбэк на работу через сервер. Но куда их пошлёт любой связьнадзор -- понятно.
Кто отвечает -- да никто. Прогнозирую, что в будущем "интернета" вообще не будет. Как в IPTV продают подписки с доступом к разным каналам, так и интернет-провайдеры будут продавать подписку на гугол, подписку на ютуб, а вконтакт и мейл.ру будут входить в ряд бесплатных государственных сайтов. А подписка на торренты будет в 10 раз дороже. Оно же уже началось у некоторых провайдеров. "В Yota можно подключить безлимит для ВКонтакте за 20 рублей..." У Мегафона тоже "акция безлимит на соцсети". Чем это кончится? Безлимитчики выжрут весь траффик на последней миле, после чего у остальных абонентов, которые больше платят за полноценный интернет, ничего загружаться не будет.
Проблема сетевого нейтралитета ой как остро стоит, просто пока технические возможности не позволяют всё описанное устроить. У многих не фиксированные адреса.
В том-то и дело что при соединеннии с коммерческим поставщиком услуг никакие трюки с пробиванием NAT не нужны. Тот всегда имеет белые адреса и большие сервера. Оно нужно там, где некому платить ни за дефицитный IPv4 адрес, ни за сервер.
Пока ещё, к счастью, потребитель может голосовать рублём. Пробиваемый NAT во многом остаётся из-за многопользовательских онлайн игр. Там своя специфика: фирма хоть и может наставить массу серверов по всему миру, но игроки ловят миллисекунды и неизбежно лучше гонять траффик напрямую. А конкретно в РФ -- игры все иностранные и серверов в РФ нет, без прямых соединений было бы очень печально, до Европы запросто можно получить уже 80мс. Очевидно, что если игрушка "лажает", то в следующем месяце и дальше будет деньги получать другой провайдер. И таким образом провайдеры заинтересованы сделать так, чтоб NAT отлично пробивался. Думаю даже, у крупных провайдеров есть штатная должность инженера, который проверяет работоспособность популярных игр и других приложений, и выясняет как нужно настроить маршрутизаторы чтоб всё работало на отлично.
novemix Автор
Отличный комментарий. Таких бы побольше. Качественный обмен мнениями взаимно обогащает.