Рубрика «nat»

P2P-форум с нуля | от NAT hole punching до автономной и полностью децентрализованной сети - 1


Многие, кто работают с интернет-сокетами в любой сфере IT, задаются вопросом о пробросе портов. Связано это с тем, что практически во всех домашних/общественных/корпоративных роутерах реализован механизм NAT, который перекрывает прямой доступ к устройствам в этих подсетях извне, общаясь с внешним интернетом от их имени.

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

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

Разнообразные сервисы работают на серверах, т. е. имеют некую ноду, которая имеет белый адрес в интернете (находится не за NAT). Все пользователи же подключаются к этому единому серверу. В таком случае проблема «невидимости» пользователей отпадает. Однако чисто серверное взаимодействие ограничивает скорость участников, так ещё и не отказоустойчиво. Если сервер упадёт, то все клиенты отправятся за ним (считаем, что это одноклеточный сервис не на всяких там kubernetes).

Как вы уже могли были догадаться, даже в реалиях, когда практически все устройства находятся за NATами, P2P реален. Когда вы являетесь участником bittorrent-раздачи, трансфер больших данных осуществляется напрямую. Как это работает? Поиск ответа на этот вопрос завёл меня в глубокие дебри, разгребая которые я написал оверлейную p2p-сеть, где трекерами являются сами её участники. Интересно? Тогда добро пожаловать под кат.Читать полностью »

По мере исчерпания адресов IPv4, многие операторы связи столкнулись с необходимостью организовывать доступ своих клиентов в сеть с помощью трансляции адресов. В этой статье я расскажу, как можно получить производительность уровня Carrier Grade NAT на commodity серверах.
Читать полностью »

Примерно 80% из нас, кто заканчивает университет с какой-либо IT-специальностью, в итоге не становится программистом. Многие устраиваются в техническую поддержку, системными администраторами, мастерами по наладке компьютерных устройств, консультантами-продавцами цифровой техники, менеджерами в it-сферу и так далее.

Эта статья как раз для таких 80%, кто только закончил университет с какой-либо IT-специальностью и уже начал мониторить вакансии, например, на должность системного администратора или его помощника, либо выездного инженера в аутсорсинговую фирму, либо в техническую поддержку 1-й/2-й линии.

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

За время своей трудовой деятельности в сфере IT я столкнулся с такой проблемой, что в университетах не дают самую основную базу касательно сетей. С этим я столкнулся сначала сам, когда, после окончания университета, ходил по собеседованиям в 2016 году и не мог ответить на простые (как мне сейчас кажется) вопросы. Тогда мне конечно показалось, что это я прохалтурил и не доучил в университете. Но как оказалось дело в образовательной программе. Так как сейчас, я также сталкиваюсь с данным пробелом знаний, когда обучаю новых сотрудников.

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

Именно поэтому я решил собрать основные темы в одну статью и объяснить их как можно проще «на пальцах».

Читать полностью »

Это сборник информации, которая мне понадобилась, чтобы реализовать этап установления соединения между участниками сетевой игры типа «равный к равному» (peer-to-peer) с использованием протокола UDP.

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

Опытные геймдевелоперы вряд ли найдут тут для себя что-то новое. Но буду благодарен за замечания и комментарии.

Особенности установления соединения между участниками сетевой игры типа «равный к равному» - 1


Читать полностью »

Отлаживаем сетевые задержки в Kubernetes - 1

Пару лет назад Kubernetes уже обсуждался в официальном блоге GitHub. С тех пор он стал стандартной технологией для развёртывания сервисов. Теперь Kubernetes управляет значительной частью внутренних и публичных служб. Поскольку наши кластеры выросли, а требования к производительности стали более жёсткими, мы стали замечать, что в некоторых службах на Kubernetes спорадически появляются задержки, которые нельзя объяснить нагрузкой самого приложения.

По сути, в приложениях происходит будто случайная сетевая задержка до 100 мс и более, что приводит к тайм-аутам или повторным попыткам. Ожидалось, что службы смогут отвечать на запросы гораздо быстрее 100 мс. Но это невозможно, если само соединение отнимает столько времени. Отдельно мы наблюдали очень быстрые запросы MySQL, которые должны были занимать миллисекунды, и MySQL действительно справлялась за миллисекунды, но с точки зрения запрашивающего приложения ответ занимал 100 мс или больше.
Читать полностью »

Джефф Хастон (Geoff Huston), главный инженер-исследователь интернет-регистратора APNIC, спрогнозировал, что адреса IPv4 закончатся в 2020 году. В новом цикле материалов мы освежим информацию о том, как истощались адреса, у кого они еще остались и почему так получилось.

Ретроспектива: как истощались адреса IPv4 - 1Читать полностью »

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

Проблема была такова. Провайдер предоставляет PPPoE-подключение, я купил белый IP, активно использую интернет в том числе для поднятия своих сервисов под так называемые «pet projects». Первый мой маршрутизатор Zyxel работал несколько лет и приказал долго жить. Купленный взамен аналогичный умер быстрее. Затем я пробвал другие разные китайские поделки из ближайшего магазина, последним стал TP-Link TD-W8151N. Он работал неплохо до тех пор, пока не начиналась приличная входящая активность через NAT, после чего он постепенно вешался и переставал отвечать на запросы. Мне это надоело, и я купил через eBay списанный где-то в Америке маршрутизатор Cisco 857.
Читать полностью »

Привет, меня зовут Максим, я системный администратор. Три года назад мы с коллегами начали переводить продукты на микросервисы, а в качестве платформы решили использовать Openstack, и столкнулись с некоторым количеством неочевидных граблей при автоматизации тестовых схем. Этот пост про нюансы настройки OpenStack, которые с трудом находятся на пятой странице выдачи поисковика (а лучше, чтобы легко находились на первой).

Тонкая настройка OpenStack под высокой нагрузкой - 1
Нагрузка на ядра: было — стало

NAT

В некоторых инстансах мы используем dualstack. Это когда виртуальная машина получает сразу два адреса — IPv4 и IPv6. Сначала мы сделали так, что «плавающий» v4-адрес назначался во внутренней сети через NAT, а v6 машина получала через BGP, но с этим есть пара проблем.

NAT — дополнительный узел в сети, где и без него нужно следить за нормальным распределением нагрузки. Появление NAT в сети почти всегда ведёт к сложностям с отладкой — на хосте один IP, в базе другой, и отследить запрос становится сложно. Начинаются массовые поиски, а разгадка всё равно будет внутри OpenStack.

Ещё NAT не позволяет сделать нормальную сегментацию доступов между проектами. У всех проектов свои подсети, плавающие IP постоянно мигрируют, и с NAT управлять этим становится решительно невозможно. В некоторых инсталляциях говорят об использовании NAT 1 в 1 (внутренний адрес не отличается от внешнего), но это всё равно оставляет лишние звенья в цепочке взаимодействия с внешними сервисами. Мы пришли к мнению, что для нас лучший вариант — это BGP сеть.

Читать полностью »

Как Discord одновременно обслуживает 2,5 млн голосовых чатов с помощью WebRTC - 1

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

В статье рассматриваются различных технологии, которые использует Discord для аудио/видеочатов.

Для ясности всю группу пользователей и каналов мы будем называть «группа» (guild) — в клиенте они называются «серверами». Вместо этого здесь термин «сервер» относится к нашей серверной инфраструктуре.
Читать полностью »

TL;DR: автор печалится о том, что в наступающем счастливом IPv6-будущем единственной приемлемой альтернативой огромным ботнетам IoT является старый добрый NAT на IPv6. К сожалению, конечно.

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

Проблема

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

Почему? Потому что нет последствий.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js