Jump to content
Local
Nubs

NAT?

Recommended Posts

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

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

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

вируса ? 

Share this post


Link to post
Share on other sites
1 час назад, Земеля сказал:

вируса ? 

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

Share this post


Link to post
Share on other sites
2 минуты назад, WideAreaNetwork сказал:

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

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

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

  • Like 2

Share this post


Link to post
Share on other sites
15 часов назад, Земеля сказал:

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

 

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

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

 

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

Share this post


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

Edited by prototip

Share this post


Link to post
Share on other sites
26 минут назад, prototip сказал:

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

Не совсем :)

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

Edited by KaYot

Share this post


Link to post
Share on other sites

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

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

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

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

Edited by KaYot

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by KaYot
  • Like 1

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
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, её надо включать принудительно и не рекомендуется так делать, да

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
16 часов назад, l1ght сказал:

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

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

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

 

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

Edited by ISK

Share this post


Link to post
Share on other sites
5 минут назад, ISK сказал:

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

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

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

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

Edited by l1ght

Share this post


Link to post
Share on other sites
3 минуты назад, l1ght сказал:

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

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

 

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

Edited by ISK

Share this post


Link to post
Share on other sites
В 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 млн сессий.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Amourmort
      Доброго времени суток!
      Был шлюз, настроенный неизвестно когда неизвестным админом. Всё прекрасно работало, интернет людям раздавался, пока не возникла необходимость перейти на другого провайдера.

      У предыдущего провайдера IP шлюзу не выдавался, адрес и шлюз был настроен прямо в rc.conf.
      У нового провайдера PPPoE
      Штатными средствами фряхи у меня поднять соединение не получилось... Вернее, соединение поднималось только вручную, командой /etc/rc.d/ppp start - при перезагрузке соединение автоматически не стартовало.
      Решил использовать утилиту mpd5 для PPPoE. Вот содержимое mpd.conf:
      default: load pppoe_client pppoe_client: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static B1 # set iface enable nat ##NAT is configured elsewhere set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 create link static L1 pppoe set link action bundle B1 set auth authname ******** set auth password ******** set link max-redial 0 set link mtu 1492 set link keep-alive 10 60 set pppoe iface igb0 set pppoe service "" open Внёс правки в rc.conf, добавив туда запуск mpd5 и убрав интерфейс igb0. Так же, убрал строку defaultrouter - она была нужна для работы с предыдущим провайдером, с новым резолвер получает данные автоматически.
      Далее, в качестве фаервола используется PF.
      В /etc/pf.conf, к счастью, использованы переменные для конфигурации. Меняю одну переменную ext_if = "igb0" на ext_if = "ng0" и думаю, что дело сделано. Соединение при перезагрузке поднимается, доступ в интернет есть... Довольный собой уехал с объекта домой.
      Вроде бы всё хорошо.
      Но вдруг оказывается, что доступ есть далеко не к каждому сайту. Например, к укр.нет доступ есть. А к bitrix24.ua - нет.
      Пингую с сервака:
       
      ping bitrix24.ua PING bitrix24.ua (18.232.195.40): 56 data bytes ^C --- bitrix24.ua ping statistics --- 26 packets transmitted, 0 packets received, 100.0% packet loss ЧЗН? Спидтест:
       
      speedtest-cli Retrieving speedtest.net configuration... Testing from LIMANET Ltd. (141.105.132.238)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by ISP Black Sea (Одесса) [0.43 km]: 5034.671 ms Testing download speed................................................................................ Download: 0.00 Mbit/s Testing upload speed................................................................................................ Upload: 0.00 Mbit/s АААААААААААААААААААА!!!! Что это???
       
      ping korinf-group.com PING korinf-group.com (91.234.33.240): 56 data bytes 64 bytes from 91.234.33.240: icmp_seq=0 ttl=58 time=13.654 ms 64 bytes from 91.234.33.240: icmp_seq=1 ttl=58 time=13.475 ms 64 bytes from 91.234.33.240: icmp_seq=2 ttl=58 time=13.332 ms 64 bytes from 91.234.33.240: icmp_seq=3 ttl=58 time=13.913 ms 64 bytes from 91.234.33.240: icmp_seq=4 ttl=58 time=14.873 ms 64 bytes from 91.234.33.240: icmp_seq=5 ttl=58 time=14.033 ms 64 bytes from 91.234.33.240: icmp_seq=6 ttl=58 time=13.743 ms ^C --- korinf-group.com ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 13.332/13.860/14.873/0.469 ms ping google.com.ua PING google.com.ua (216.58.215.67): 56 data bytes 64 bytes from 216.58.215.67: icmp_seq=0 ttl=120 time=27.686 ms 64 bytes from 216.58.215.67: icmp_seq=1 ttl=120 time=27.766 ms 64 bytes from 216.58.215.67: icmp_seq=2 ttl=120 time=27.738 ms 64 bytes from 216.58.215.67: icmp_seq=3 ttl=120 time=27.651 ms 64 bytes from 216.58.215.67: icmp_seq=4 ttl=120 time=27.603 ms 64 bytes from 216.58.215.67: icmp_seq=5 ttl=120 time=27.781 ms 64 bytes from 216.58.215.67: icmp_seq=6 ttl=120 time=27.562 ms ^C --- google.com.ua ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.562/27.684/27.781/0.077 ms Как такое может быть? Куда копать?
      При этом, если на компе юзера включить какой-нибудь "впн", с туннелем через Киев или Берлин, доступ к любым сайтам есть, как положено...
    • By kotqq
      Продам Juniper MX10-T (2 БП), сделан апгрейд до МХ80, BRAS. В комплекте плата mic-3d-20ge-sfp и MS-MIC-16G. Цена за полный комплект 8500$, без NAT - 5500$



    • By kotqq
      Продам очень дешево Juniper QFX3500-48S4Q (48 SFP+/SFP and 4 QSFP). Цена 1250$ 
      з.ы. Блок питания один, установка второго не возможна. Все порты рабочие.
       
      Высокопроизводительные коммутаторы QFX3500 идеально подходят для центров обработки данных, обеспечения обласных вычислений. Свичи поддерживают коммутацию 2 и 3 уровней с очень малой задержкой данных. Данная модель оснащена 48 двухрежимными портами SFP+/SFP с трансиверами и 4 QSFP+ разъемами. Производительность этого коммутатора может достигать 1.28 Тбит/с.



    • By Туйон
      Добрый вечер, коллеги!
      Столкнулся с такой ситуацией.
      Вышестоящий провайдер выдаёт интернет посредством gre-tunnel.
      К серверу (микротику) подключается 5 отдельных локальных подсетей.
      Раньше на этом туннеле был один ай-пи, допустим 111.111.111.111
      В ip - firewall было создано одно правило НАТ, применен scr-nat, в настройках было указано to-address 111.111.111.111
      Всё работало.
      Было принято решение чуть разгрузить это всё и добавлен ещё один внешний ай-пи, отличающийся на 1 цифру допустим 111.111.111.112.
      К слову, оба этих ай-пи прописаны прямо на интерфейс туннеля (в ip - addresses).
      Для того, чтобы две из пяти локальных сети выходили в мир по 111.111.111.111, а три другие по 111.111.111.112, я принял решение создать отдельно 5 правил scr-nat.
      Вот кусок конфига:
       
      /ip firewall nat
      add action=src-nat chain=srcnat dst-address=!192.168.0.0/16 out-interface=gw-a src-address=192.168.0.0/24 src-address-list=Clients to-addresses=111.111.111.111
      add action=src-nat chain=srcnat dst-address=!192.168.0.0/16 out-interface=gw-a src-address=192.168.1.0/24 src-address-list=Clients to-addresses=111.111.111.111
      add action=src-nat chain=srcnat dst-address=!192.168.0.0/16 out-interface=gw-a src-address=192.168.2.0/24 src-address-list=Clients to-addresses=111.111.111.112
      add action=src-nat chain=srcnat dst-address=!192.168.0.0/16 out-interface=gw-a src-address=192.168.3.0/24 src-address-list=Clients to-addresses=111.111.111.112
      add action=src-nat chain=srcnat dst-address=!192.168.0.0/16 out-interface=gw-a src-address=192.168.4.0/24 src-address-list=Clients to-addresses=111.111.111.112
       
      Вроде всё работает, но то ли мне кажется, то ли сайты иногда подвисают.
       
      Посему вопросы:
      1. Правильно ли я разрулил 2 внешних ай-пи на 5 локальных сетей?
      2. Что это такое !192.168.0.0/16. Я понимаю, что это исключение адресного пространства локалки из НАТа, но с какой целью? Надо ли так делать?
      3. Если на туннеле прописаны оба внешника 111.111.111.111 и 111.111.111.112, то если я буду пинговать некий сайт прямо с микротика, с какого из этих двух адресов будут идти запросы на сайт?
    • By Myr4ik
      Здравствуйте, ребята!
      Есть желание пробросить unicast IPTV из сети одного оператора в сеть другого поверх интернета без туннелей.
      Обычно делаю следующую настройку в NAT устройства (mikrotik), которое подключено к оператору, что вещает IPTV:
       
      chain=dstnat action=dst-nat to-addresses="IP UDP-to-HTTP сервера провайдера" to-ports=4022 protocol=tcp in-interface=ether1 dst-port=4321 ether1 - линк с оператором, в который приходит IPTV и интернет, и откуда, разумеется, IPTV уходит во вне с порта 4321.
      UDP-to-HTTP сервер оператора вещает с "IP UDP-to-HTTP сервера провайдера" и порта 4022.
       
       
      После вышеописанного, модифицирую соответствующий плэйлист с каналами на принимающей стороне и вуяля - все работает.
      Но недавно столкнулся с оператором, с которым этот финт не прокатил...
       
      Суть проблемы, как мне кажется, в следующем:
      Оператор, с которым, как я поначалу подумал не заработало правило NAT (а оно заработало вполне корректно), использует для вещания IPTV ПО Astra, которому не нравится в запросе от, например VLC, в поле Host, указание IP-адреса, а не FQDN.
      Изображение недуачной попытки посмотреть ТВ:
       

       
       
      А вот успешный запрос с FQDN, после которого сразу начинается передача-прием потока:
       

       
      Вопрос - есть ли способ модифицировать правило(а) на mikrotik (без создания DNS-записей на принимающей стороне), чтобы стало возможным просматривать IPTV вне сети оператора с Astr`ой? Правильно ли я локализовал "проблему"?
       
      Спасибо.
×