Посмотрите на рисунок. Вот так конфигурируется классический NAT на маршрутизаторе Cisco, допустим там больше ничего не сконфигурировано. А теперь ответьте сами себе на вопрос. Может ли при определенных условиях кто-либо обратиться извне на RDP порт (TCP 3389) супер секретного сервера 192.168.0.250 и попытаться подобать пароль к нему. Уточним, что сервер стоит одиноко в сети и никуда сам не обращается (имеется в виду, что на нем нет никаких троянов, автоматических обновлений и прочих прелестей).

Считаете — нет? Вспомним анекдот.

Лекция по филологии. Старый профессор рассказывает:

— В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но, нет ни одного языка в мире, в котором двойное согласие означает отрицание. Голос с задней парты:

1. Арендуем… что и как?

Ну что же, продолжим. Как говорится, «не все серверы одинаково полезны». Кроме географической расположенности площадки, которая будет влиять на задержку прохождения транслируемых пакетов, самая главная характеристика покупаемого продукта – это система виртуализации.
Скажу честно – не люблю я OpenVZ, да, они дешевле, но на них чувствуешь себя, как в гостях – то низя, это не трогай, а вон то заработает, только если слёзно умолять хозяев дома, они ещё и не разрешат. А по сему, предпочитаю сервера на XEN или KVM. Вот тут-то всё как дома! Работает всё, что надо, виртуализация не чувствуется вообще! Хочешь – свопа добавь из своего дискового пространства, все модули ядра есть, его даже можно пересобрать! Виртуальные сетевые карты всех мастей, все цепочки iptables… ВСЁ!
Из дистрибутивов рекомендую Debian, ну или Ubuntu Server.

Очень часто мы слышим о том, что установить соединение компьютер-компьютер через интернет с динамическими IP – нереально без внешнего сервера.
А также думал, до определенного времени. Потом у меня закрались подозрения… А после мне стало известно очень многое и тайное.

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

Все совпадения случайны, цифры изначально выдуманы.

В настоящее время все мы живем в мире IPv4. И пока процесс перехода на IPv6 затягивается, IP адресов на всех не хватает. В силу отсутствия достаточного количества уникальных IPv4 адресов, большинство пользователей вынуждено получать доступ к Интернету через NAT устройства на стороне провайдера. С недостатками данного подхода сталкивались многие. Прежде всего, это сложности в организации P2P взаимодействия, в том числе игр. Если хочется запустить «свой» игровой сервер, то без внешнего IP, он будет доступен только из локальной сети, если таковая имеется. Для преодоления возникающих с NAT проблем, были разработаны специальные программы, такие как Hamachi, Garena и др. Теперь, после данного небольшого вступления, перейдем непосредственно к описанию проекта.

Хотя свободных адресов IPv4 у ICANN больше не осталось (последние блоки /8 были отданы 3 февраля 2011 года), доля трафика по протоколу IPv6 в интернете составляет всего 0,25% [Arbor Networks]. Хуже того, за последние шесть месяцев объём трафика IPv6 уменьшился в относительном выражении на 12%, тогда как трафик IPv4 вырос на 40–60%. Интернет-провайдеры продолжают извращаться с NAT, игнорируя IPv6.

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

Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.

Описание проблемы

Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.

Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.

Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.

Поделюсь одним случаем из телекоммуникационной практики.
У нас стоит циска 26-й серии (2620XM). На ней заведено около четырёх десятков сабинтерфейсов. Большинство для локальных абонентов, расположенных в том же здании, и есть несколько линков на дальние точки. Среди них аэропорт, кирпичный завод, горнолыжный комплекс, совхоз. «Да это ж старьё непотребное» — скажете вы и будете правы, но так исторически сложилось. Однако суть не в этом.
И вот некоторое время назад оказалось что нагрузка слишком высока. Сначала это проявлялось в некоторых задержках при работе в консоли. Типа набираешь команду, а буквы появляются не сразу а немного с задержкой. Потом периодически стал увеличиваться пинг до циски с удалённых точек. Следующий симптом — иногда отваливающийся канал в интернет (при этом маршрутизация внутри локальной сети работала безупречно и потерь не было). А в логах тем временем жуткая картина о сильно активном использовании CPU. Загрузка процессора не опускается ниже 80%, а большую часть времени 95-99%. Теперь пинг стал теряться даже если ты находишься в той же подсети. Интернет захромал на обе ноги.