LINUX.ORG.RU
ФорумTalks

В интернете опять кто то неправ.

 , , , ,


2

2

Наблюдал я за одной дискуссией и подключился к ней. Суть дискуссии в том что один из оппонентов доказывает то что через NAT можно свободно подключаться к компьютерам внутри сети по UDP протоколу и вообще одного IP адреса хватит всем. Когда я ему задал прямой вопрос «А расскажи как UDP ходят через NAT и как шлюз определяет по внешнему адресу внутренний», он тупо скинул видео на английском, как я понял чувак на том видео говорит о трансляции полученной у провайдера подсети на локалку через шлюз.

Из его постов:

UDP таки свободно работает через NAT. Никаких причин что бы он не работал вообще представить себе не могу.

Он тебе там х*й__м не шлёпнул по ***лу? DNS-сервер W*n*o*s работает только по TCP, например. Трансфер зон идёт там же в сраном бинде.

Подскажите мне специалисты по полемике. Он просто невежественен? Я не понимаю разницы между TCP и UDP? Мы с ним на разных языках говорим? Или он просто зелёный «мотороллер»?

Просто я сейчас стал перечитывать мануалы, нахожу что я совершенно прав в этом споре, но его упёртость заставляет меня сомневаться в моём восприятии и психическом здоровье.

Ответ на: комментарий от sergej

Через конический NAT UDP действительно работает хорошо.

См также TURN и STUN.

sergej ★★★★★
()
Ответ на: комментарий от Solace

Если так хочешь спорить с идиотом - опустись до его уровня.

Или поднимись, как вариант :)

Boba_Fett
()

Как уже сказали выше - идиота не переспорить, он сильнее тебя на этом поле.

dk-
()
Ответ на: комментарий от visual

я в линуксе, не проверял, но думаю, что возможно.


В Linux netfilter есть независимые цепочки PREROUTING (dnat) и POSTROUTING (snat, masquerade). И порядок прохождения пакета не меняется. Даже если использовать source based routing.

sco-killer
()

Он тебе там х*й__м не шлёпнул по ***лу?

я думаю он прав в этом моменте

anonymous_sapiens ★★★★★
()

UDP таки свободно работает через NAT. Никаких причин что бы он не работал вообще представить себе не могу.

Смотря через какой NAT. Смотря что тебе NAT'ят. Смотря какой протокол. В принципе, в некоторых граничных условиях UDP действительно отлично работает через NAT.

DNS-сервер W*n*o*s работает только по TCP, например

ЛПиП. TCP или UDP выбирает клиент, а не сервер :-)

no-dashi ★★★★★
()

UDP вполне работает через нат. Есть такая штука в ядре, называется netfilter connection tracking. Он позволяет отслеживать в том числе и stateless протоколы. И определять related соединения. Пример трекинга related соединения: можно пропустить внутрь сети к клиенту ftp подключение от сервера в активном режиме. Но это уже tcp и к теме не относится.

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 1)

Бывает несколько типов NAT'а. И бывают разные техники для проковыривания в NAT'е отверстий для UDP-пакетов, но работают они далеко не всегда. В общем всё «зависит от», как обычно.

Deleted
()

Завязывай спорить с идиотами.

gadfly ★★
()

DNS-сервер W*n*o*s работает только по TCP, например.

Вот здесь можешь отыграться, например.

thesis ★★★★★
()

NAT знает на какой IP направить трафик с соотв. порта, это указано в его настройках.

flareguner
()

Некоторые проблемы есть, но они в большинстве своём сравнительно легко решаемые страндартными средствами. Вот тебе небольшой обзор с картинками-раскрасками. Прочитай внимательно и потом спрашивай.

auto12884835
()

Спор с идиотом бесполезен. Сначала он опустит тебя до своего уровня, потом задавит авторитетом и опытом.

AiFiLTr0 ★★★★★
()

Автор действительно слабо понимает принципы работы stateless NAT. Более того, автор приводит цитаты двух разных людей, принимая их за одного человека.

P.S. мимопроходящий участник того срача о котором вещает автор

digitalg0d
()

В теории разные варианты могут быть, в общем случае в наше время никаких проблем с NAT нет, ни с UDP, ни с TCP.

Общая схема такова - машина из-за NAT по UDP кидает соединение вовне, на машине с NAT открывается некий порт, который мапится к соответствующему порту машины за NAT, и собственно можно общаться.

yu-boot ★★★★★
()
Ответ на: комментарий от sergej

Нет, там описана глобальная проблема по имени source-routing.

GateKeeper ★★
()
Ответ на: комментарий от sergej

конический

Как я понял это про один IP адрес.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от Black_Shadow

На машине с NAT порт не открывается. Добавляется запись в таблицу conntrack'а.

Открывается в смысле «не закрывается» :)

yu-boot ★★★★★
()
Ответ на: комментарий от yu-boot

Так, тогда ещё вопрос.

Есть глобальный адрес 31.180.232.226

Локалка 192.168.0.*

Настроен обычный NAT (linux-шлюз)

С компьютеров 192.168.0.12 и с 192.168.0.20 начинается передача udp пакетов на условно 81.120.200.100 порт 7888

Как шлюз определит какому хосту который пакет доставить на основании данных из самих пакетов?

http://www.imageup.ru/img240/1143608/ipv4.png и http://www.imageup.ru/img240/1143609/udp.png

Какие поля пакетов и как используются что бы определить адресата внутри локалки?

(по условию изменить настройки шлюза нельзя, что бы имитировать провайдерский nat)

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

На основании сочетаний пар адрес_источника:порт_источника Т.е. 192.168.0.12:43211 и 192.168.0.20:23456 является вполне достаточным условием для идентификации потоков трафика.

digitalg0d
()
Ответ на: комментарий от rezedent12

Как шлюз определит какому хосту который пакет доставить на основании данных из самих пакетов?

NAT разные порты будет использовать на выход, как же ещё. И запоминать, какой порт был использован для какой внутренней машины (грубо и приблизительно, ОК?)

Да, когда кончатся все 65535 одновременно, может быть «ой!»

yu-boot ★★★★★
()
Ответ на: комментарий от digitalg0d

Где изменился номер порта?

Тут

192.168.0.12:43211 и 192.168.0.20:23456

Читаю тут http://hashcode.ru/questions/167582/python-приём-udp-пакетов-за-nat-ом

Не вводите человека в заблуждение. Для UDP hole punching никакого UPnP port mapping'а и прочего port forwarding'а не нужно.

Скайп и торренты пользуются UPnP port mapping если он есть. Если нет — пробивают дыру в NAT'е каким-нибудь STUN'ом. Если, конечно, реализация NAT позволяет пробить дыру.

Как я понял, всё пять же зависит от того какой это всё таки NAT и какие костыли им управляют.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

О боги...

192.168.0.12:43211 и 192.168.0.20:23456 это адреса и порты ИСТОЧНИКОВ трафика. Адрес и порт получателя не меняется. Любой поток трафика TCP/UDP, идентифицируется 4-мя уникальными значениями - source_ip:source_port:destination_ip:destination_port Задача NAT - «спрятать» source_ip в случае когда он находится в локальной сети, преобразовав его в какой-то другой адрес. Как правило при преобразовании source_ip, меняется и source_port.

какой это всё таки NAT

NAT всегда одинаково работает. И по одним и тем же принципам.

digitalg0d
()
Ответ на: комментарий от digitalg0d

Задача NAT - «спрятать» source_ip в случае когда он находится в локальной сети

То что udp пакет проходит сквозь шлюз из локалки в интернеты, это я и так знал.

А если destination_ip это адрес шлюза (компьютер внутри локалки) , как тогда?

-A FORWARD -i ppp1 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i ppp1 -j DROP 
-A FORWARD -i eth0 -o ppp0 -j DROP 
rezedent12 ☆☆☆
() автор топика

то что через NAT можно свободно

Информация к размышлению. Классификация NAT'ов (*-cone, symmetric) была предложена в RFC3489, определяющим STUN. В RFC5389, пришедшему на смену, NAT уже не классифицируется с пометкой «жизнь намного богаче», да и сама аббревиатура расшифровываться по-другому.

Поэтому, обсуждение NAT - есть дисциплина специальной олимпиады: каждая сторона понимает обсуждаемый объект по-своему.

Просто я сейчас стал перечитывать мануалы

Читай лучше мануалы по IPv6.

Macil ★★★★★
()
Последнее исправление: Macil (всего исправлений: 1)
Ответ на: комментарий от rezedent12

А если destination_ip это адрес шлюза (компьютер внутри локалки) , как тогда?

Всё ровным счётом тоже самое. DestinationPort не меняется, меняется DestinationIP.

digitalg0d
()
Ответ на: комментарий от digitalg0d

Провёл тут несколько экспериментов с различными DNS, а так же с прохождением UDP через NAT.

Как сказал товарищ В интернете опять кто то неправ. (комментарий)

Мы действительно спорили немного о разных NAT. И я ошибался приводя в качестве примера устаревший стандарт.

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

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от yu-boot

Открывается в смысле «не закрывается» :)

Я вообще стараюсь не использовать в обиходе понятия открытого/закрытого/незакрытого порта, потому что хрен поймёшь, о чём речь. Если нравится думать, что есть какие-то абстрактные дырочки в количестве 65536, которые могут быть открыты или закрыты, то можно, конечно, допускать такое приближение, но в реальности ничего такого нет. Ядро принимает весь трафик, и обрабатывает весь трафик вне зависимости от того, что там указано в правилах сетевого экрана, и слушает ли какой либо процесс определённый порт на интерфейсе. Просто иной раз не понятно, о чём речь. В правилах iptables легко может быть запрет на входящий трафик по определённому порту в зависимости от разных условий, или запрет на входящий локальный трафик при разрешённом транзитном трафике на том же порту, или запрет на входящий трафик с определённых адресов... Ситуаций множество. И как в этих ситуациях понимать понятия закрытого/открытого порта?

Black_Shadow ★★★★★
()
Ответ на: комментарий от rezedent12

А провайдерские NAT так делают?

Как провайдер говорю - «провайдерский» ничем не отличается от используемого в домашнем D-Link (iptables), кроме мощности CPU и «умных» сетевых карт иногда.

yu-boot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.