Земеля Опубліковано: 19 жовтня, 2019 Опубліковано: 19 жовтня, 2019 8 минут назад, WideAreaNetwork сказал: Раз тут о капчах то спрошу может кто знает, есть абон который жалуется на карту но как выяснилось эта капча у него дома только на его компе рабочем, все остальные девайсы норм, как это победить? Себя также перекидывал на ту айпишку, пару дней сижу полет нормальный вируса ?
WideAreaNetwork Опубліковано: 19 жовтня, 2019 Опубліковано: 19 жовтня, 2019 1 час назад, Земеля сказал: вируса ? сначала также подумал, но когда он переходит на мобильный инет то полет нормальный
Земеля Опубліковано: 19 жовтня, 2019 Опубліковано: 19 жовтня, 2019 2 минуты назад, WideAreaNetwork сказал: сначала также подумал, но когда он переходит на мобильный инет то полет нормальный через мобильный еще не успел заспамить тот ай-пи что выдал мобильный оператор. если на порту оборудование все ок, то все остальное проблема аборигена Или вы еще занимаетесь бесплатно ремонтом пк\ ноутов \ тв ? 2
WideAreaNetwork Опубліковано: 20 жовтня, 2019 Опубліковано: 20 жовтня, 2019 15 часов назад, Земеля сказал: через мобильный еще не успел заспамить тот ай-пи что выдал мобильный оператор 17 часов назад, WideAreaNetwork сказал: Себя также перекидывал на ту айпишку, пару дней сижу полет нормальный а может капчу кидать на учетку, а не на айпи? проблема у него конкретно с одним сайтом где он зареган
prototip Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 (відредаговано) В 18.10.2019 в 21:39, KaYot сказал: Это пережитки прошлого в виде freeBsd и необходимости держать открытые порты для NAT. Linux использует другой механизм отслеживания соединений без таких тупых ограничений, 10М+ отслеживаемых одновременно соединений вполне нормально нынче. Вылезайте из криокапсулы. Нет, это сила чтения форумов и личного опыта) Will our LAN be limited to 65536 (or some other theoretical limit) concurrent connections to the outside world through a single public IP address? No, because one port NAT IP can be used for multiple connections: cat /proc/net/ip_conntrack | grep 51380 tcp 6 191 ESTABLISHED src=10.1.8.5 dst=17.133.254.23 sport=51380 dport=5223 src=17.133.254.23 dst=my.nat.pub.ip sport=5223 dport=51380 [ASSURED] mark=0 use=2 tcp 6 24 CLOSE_WAIT src=10.1.26.1 dst=80.68.255.71 sport=51380 dport=80 src=80.68.255.71 Вы правы , но к сожалению отчасти , да 65535 не жесткое определение и таки да количество соединений может быть теоретически и практически несколько большим , но не значительно . Відредаговано 21 жовтня, 2019 prototip
KaYot Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 26 минут назад, prototip сказал: Вы правы , но к сожалению отчасти Не совсем Какая-то из реализаций НАТа(PF?) во фре когда-то требовала выделения порта под каждый коннект и иначе никак. Вероятно вместо таблицы состояний тупо использовались открытые порты. Нынче никакой связи с портами маршрутизатора нет, могут отслеживаться десятки миллионов соединений. В linux и МТ точно так, думаю и во фре давно все изменилось.
prototip Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 Ну как же нет связи с портами маршрутизатора ? Просто iptables позволяет совместное использование одних и тех же портов то да . Я согласен вылезти из своей криокамеры и просветиться - ткните носом в ман или ссыль плиз .
KaYot Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 (відредаговано) Да тут криокамера не при чем. Какие порты должен у себя открывать маршрутизатор и зачем? Трафик к нему в input/output вообще не попадает, он транзитный. Дело маршрутизатора переложить пакет из интерфейса в интерфейс, и уменьшить ему TTL на 1. Если используется НАТ - заменить src и dst адрес в пакете согласно записям в таблице трекинга. Если записи нет и есть флаги SYN/NEW - добавить запись. Если записи нет и флагов нет - дропнуть пакет, не наш он. Відредаговано 21 жовтня, 2019 KaYot
KaYot Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 (відредаговано) Самому стало интересно в чем же разница. Гугель говорит - НАТ в BSD отслеживал только адрес назначения, что б вернуть пакет отправителю нужно однозначное соответствие "порт на который пришел трафик - локальный ИП". Итого 65к tcp + 65k udp трансляций на IP. Линукс же изначально отслеживает все 4 параметра SRC, DST, sport, dport - нет нужды подменять порты и нет ограничения числа трансляций на 1 ИП. Думаю этой ереси и в БСД давно нет, да и НАТов там несколько разновидностей. Відредаговано 21 жовтня, 2019 KaYot
prototip Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 https://serverfault.com/questions/541699/nat-gateway-maximum-connection-limit
prototip Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 На самом деле это очень интересный вопрос .
KaYot Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 (відредаговано) Все верно написано. Лимит в 65к соединений можно получить только для обращения 1 источника к 1 получателю, и это не открытые порты роутера. Количество вариаций src-port источника . В любых других ситуациях лимита соединений нет. Відредаговано 21 жовтня, 2019 KaYot 1
Туйон Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 Если было бы 65к на всех, думаю, 1 белый на 1000 серых схема точно не работала бы. Торренты, обновлялки и вирусня много могут открыть соединений.
l1ght Опубліковано: 21 жовтня, 2019 Опубліковано: 21 жовтня, 2019 20 минут назад, KaYot сказал: Все верно написано. Лимит в 65к соединений можно получить только для обращения 1 источника к 1 получателю, и это не открытые порты роутера. Количество вариаций src-port источника . В любых других ситуациях лимита соединений нет. не 65к, даже меньше, но упрется не в нат, а в лимит исходящих соединений с клиентской стороны # cat /proc/sys/net/ipv4/ip_local_port_range 32768 60999 ну теоретический лимит это (примерно) все айпи адреса - 4294967296 исключаем пулы rfc1918 192.168.0.0/16 - 65534 172.16.10.0/12 - 1048574 10.0.0.0/8 - 16777214 исключаем пул для CG-NAT 100.64.0.0/10 - 4194302 well-known not routed 0.0.0.0/8 - 16777214 127.0.0.0/8 - 16777214 198.18.0.0/15 - 131070 240.0.0.0/4 - 268435454 итого на вскидку - 3 970 760 720 по дефолту пул портов для исходящих соединений примерно 30к (от 30 000 до 61 000) итак, теоретический лимит - 3 970 760 720 * 30 000 = 119 122 821 600 000 ну там довольно много неточностей, но в целом думаю понятно 1 час назад, KaYot сказал: НАТ в BSD отслеживал только адрес назначения там есть вредная опция для этого у ipfw nat называется same_ports, её надо включать принудительно и не рекомендуется так делать, да
prototip Опубліковано: 22 жовтня, 2019 Опубліковано: 22 жовтня, 2019 Упрется все в оперативную память вашего роутера ....
ISK Опубліковано: 22 жовтня, 2019 Опубліковано: 22 жовтня, 2019 (відредаговано) 16 часов назад, l1ght сказал: там есть вредная опция для этого у ipfw nat называется same_ports, её надо включать принудительно и не рекомендуется так делать, да OK, тогда объясни пожалуйста, почему в Ubilling она включена по дефолту, если она такая вредная? Это же банальное сохранение портов src и dst... P. S. Флай вот, к примеру, рекомендует ее включать: https://m.habr.com/ru/post/102739/ Відредаговано 22 жовтня, 2019 ISK
l1ght Опубліковано: 22 жовтня, 2019 Опубліковано: 22 жовтня, 2019 (відредаговано) 5 минут назад, ISK сказал: OK, тогда объясни пожалуйста, почему при установке Ubilling она включена по дефолту? спроси у флая сколько лет этим пресетам и зачем это всё и то что оно там из коробки никак не влияет на то что нужно понимать что ты делаешь и статья очень актуальная, на календарь глянь, там 2019 год Відредаговано 22 жовтня, 2019 l1ght
ISK Опубліковано: 22 жовтня, 2019 Опубліковано: 22 жовтня, 2019 (відредаговано) 3 минуты назад, l1ght сказал: и статья очень актуальная, на календарь глянь, там 2019 год Да я-то в курсе, да, но в 1.0.1 до сих пор она есть - специально сейчас проверил на недавно поднятом биллинге:) Вот и спрашиваю... Відредаговано 22 жовтня, 2019 ISK
Sоrk Опубліковано: 22 жовтня, 2019 Опубліковано: 22 жовтня, 2019 В 21.10.2019 в 18:56, l1ght сказал: same_ports про опцию есть тут: http://www.major12.net/2014/05/high-cpu-load-with-freebsd-ipfw-nat.html сам столкнулся, при нагрузке в 2-3 gbit, если появлялся абонент, который начинал очень активно сканировать сеть (регистратор с вирусом) - нагрузка резко выростала до 100% Актуально было для freebsd 11, менялось ли что-то в 12й версии не знаю. Отключение опции решало проблему и не вызывало жалоб у абонентов. без same_ports при 128 внешних IP сервер с 4 Гб оперативной памяти легко держит 1 млн сессий. 1
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас