Comments 10
Как-то сумбурно и не очень понятно. Схемы не очень понятны. Дайте ссылок почитать по сабжу!
Вот здесь наглядно/доступно, но с ошибками для общего случая: it.sander.su/udp-hole-punching.php
Конкретно ошибка вот тут: «A и B отправляют аналогичные пакеты на S, и S узнает порты P2 и P4.»
При новом соединении, тем более на другой хост порты сменятся для нормальной реализации NAT.
Конкретно ошибка вот тут: «A и B отправляют аналогичные пакеты на S, и S узнает порты P2 и P4.»
При новом соединении, тем более на другой хост порты сменятся для нормальной реализации NAT.
В этой статье не рассматривается случай с Symmetric NAT.
Но для человека сгодится, если он ленится погуглить. Заменяю но с ошибками для общего случая: на не подходит для симметрик нат, спасибо за замечание.
Эта ссылка лучше: cyberguru.ru/networks/network-security/nat-details.html
Я в курсе. Но она не обяъсняет тему посредника.
А у вас вроде какой-то продукт есть на тему UDP hole punching. Для каких случаев он актуален и работоспособен?
Есть. И статья есть на эту тему habrahabr.ru/post/142858/. Но сейчас схема работы с UDP hole punching стала гораздо проще. После появления поддержки UDP в Windows Azure отпала необходимость в стороннем посреднике. Работоспособность удаленного рабочего стола гарантирована для практически всех натов, кроме симметричных.
Я так и не понял, что за «некий реальный_IP» (ещё пишут серые, белые и т.д.).
О публичных и частных IP-адресах знаю, о «реальных», «нереальных», «серых», «чёрных», «белых» не знаю.
О публичных и частных IP-адресах знаю, о «реальных», «нереальных», «серых», «чёрных», «белых» не знаю.
Sign up to leave a comment.
UDP hole punching для Symmetric NAT: немного теории и почти честный эксперимент