NAT?

[Земеля 728]

8 минут назад, WideAreaNetwork сказал:

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

Себя также перекидывал на ту айпишку, пару дней сижу полет нормальный

вируса ? 

[WideAreaNetwork 222]

1 час назад, Земеля сказал:

вируса ? 

сначала также подумал, но когда он переходит на мобильный инет то полет нормальный

[Земеля 728]

2 минуты назад, WideAreaNetwork сказал:

сначала также подумал, но когда он переходит на мобильный инет то полет нормальный

через мобильный еще не успел заспамить тот ай-пи что выдал мобильный оператор. если на порту оборудование все ок, то все остальное проблема аборигена

Или вы еще занимаетесь бесплатно ремонтом пк\ ноутов \ тв ? 

[WideAreaNetwork 222]

15 часов назад, Земеля сказал:

через мобильный еще не успел заспамить тот ай-пи что выдал мобильный оператор

 

17 часов назад, WideAreaNetwork сказал:

Себя также перекидывал на ту айпишку, пару дней сижу полет нормальный

 

а может капчу кидать на учетку, а не на айпи? проблема у него конкретно с одним сайтом где он зареган

[prototip 284]

В 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 не жесткое определение и таки да количество соединений может быть теоретически и практически несколько большим , но не значительно . 

Відредаговано 2019-10-21 08:43:45 prototip

[KaYot 3 711]

26 минут назад, prototip сказал:

Вы правы , но к сожалению отчасти

Не совсем

Какая-то из реализаций НАТа(PF?) во фре когда-то требовала выделения порта под каждый коннект и иначе никак. Вероятно вместо таблицы состояний тупо использовались открытые порты.

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

[prototip 284]

Ну как же нет связи с портами маршрутизатора ? Просто iptables позволяет совместное использование одних и тех  же портов то да . Я согласен вылезти из своей криокамеры и просветиться - ткните носом в ман или ссыль плиз .

[KaYot 3 711]

Да тут криокамера не при чем.

Какие порты должен у себя открывать маршрутизатор и зачем? Трафик к нему в input/output вообще не попадает, он транзитный.

Дело маршрутизатора переложить пакет из интерфейса в интерфейс, и уменьшить ему TTL на 1.

Если используется НАТ - заменить src и dst адрес в пакете согласно записям в таблице трекинга. Если записи нет и есть флаги SYN/NEW - добавить запись. Если записи нет и флагов нет - дропнуть пакет, не наш он.

 

Відредаговано 2019-10-21 14:23:31 KaYot

[KaYot 3 711]

Самому стало интересно в чем же разница.

Гугель говорит - НАТ в BSD отслеживал только адрес назначения, что б вернуть пакет отправителю нужно однозначное соответствие "порт на который пришел трафик - локальный ИП". Итого 65к tcp + 65k udp трансляций на IP.

Линукс же изначально отслеживает все 4 параметра SRC, DST, sport, dport - нет нужды подменять порты и нет ограничения числа трансляций на 1 ИП.

Думаю этой ереси и в БСД давно нет, да и НАТов там несколько разновидностей.

Відредаговано 2019-10-21 14:57:43 KaYot

[prototip 284]

https://serverfault.com/questions/541699/nat-gateway-maximum-connection-limit

 

[prototip 284]

На самом деле это очень интересный вопрос .

[KaYot 3 711]

Все верно написано.

Лимит в 65к соединений можно получить только для обращения 1 источника к 1 получателю, и это не открытые порты роутера. Количество вариаций src-port источника .

В любых других ситуациях лимита соединений нет.

Відредаговано 2019-10-21 15:25:43 KaYot

[Туйон 1 266]

Если было бы 65к на всех, думаю, 1 белый на 1000 серых схема точно не работала бы.

Торренты, обновлялки и вирусня много могут открыть соединений.

[l1ght 377]

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 284]

Упрется все в оперативную память вашего роутера ....

[ISK 259]

16 часов назад, l1ght сказал:

там есть вредная опция для этого у ipfw nat называется same_ports, её надо включать принудительно и не рекомендуется так делать, да

OK, тогда объясни пожалуйста, почему в Ubilling она включена по дефолту, если она такая вредная?

Это же банальное сохранение портов src и dst...

 

P. S. Флай вот, к примеру, рекомендует ее включать: https://m.habr.com/ru/post/102739/

Відредаговано 2019-10-22 08:29:03 ISK

[l1ght 377]

5 минут назад, ISK сказал:

OK, тогда объясни пожалуйста, почему при установке Ubilling она включена по дефолту?

спроси у флая сколько лет этим пресетам и зачем это всё

и то что оно там из коробки никак не влияет на то что нужно понимать что ты делаешь

и статья очень актуальная, на календарь глянь, там 2019 год

Відредаговано 2019-10-22 08:29:39 l1ght

[ISK 259]

3 минуты назад, l1ght сказал:

и статья очень актуальная, на календарь глянь, там 2019 год

Да я-то в курсе, да, но в 1.0.1 до сих пор она есть - специально сейчас проверил на недавно поднятом биллинге:)

 

Вот и спрашиваю...

Відредаговано 2019-10-22 08:32:41 ISK

[Sоrk 48]

В 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 млн сессий.