Keep alive в роутере что это

Содержание:

2.4. Preventing disconnection due to network inactivity

The other useful goal of keepalive is to prevent inactivity from
disconnecting the channel. It’s a very common issue, when you are behind a
NAT proxy or a firewall, to be disconnected without a reason. This
behavior is caused by the connection tracking procedures implemented in
proxies and firewalls, which keep track of all connections that pass
through them. Because of the physical limits of these machines, they can
only keep a finite number of connections in their memory. The most common
and logical policy is to keep newest connections and to discard old and
inactive connections first.

Returning to Peers A and B, reconnect them. Once the channel is open, wait
until an event occurs and then communicate this to the other peer. What if
the event verifies after a long period of time? Our connection has its
scope, but it’s unknown to the proxy. So when we finally send data, the
proxy isn’t able to correctly handle it, and the connection breaks up.

Because the normal implementation puts the connection at the top of the
list when one of its packets arrives and selects the last connection in
the queue when it needs to eliminate an entry, periodically sending
packets over the network is a good way to always be in a polar position
with a minor risk of deletion.

Настройка D-Link DIR-300/NRU для сети Авангард | Ком-сервис

Сегодня мы займёмся настройкой роутера D-Link DIR-300/NRU для работы с ADSL-модемом «Авангарда» — ныне «Рослетекома» (у нас его роль исполнял HUAWEI EchoLife HG8504). То есть в нашем случае Wi-Fi роутер был подключен к ADSL-модему, а не напрямую к телефонной линии оператора.

Первое, что нужно сделать после подключения устройства, — зайти на страницу его настройки, а для этого нужно открыть в браузере адрес 192.168.0.1. Оказавшись на странице аутентификации, в формах ввода укажите «Имя пользователя» admin и «Пароль» admin:

Роутер предложит вам сменить административный пароль роутера, что мы настоятельно рекомендуем сделать:

Укажите новый пароль на открывшейся странице. Лучше всего задавать пароль длиной не менее 8 символов, содержащий цифры и буквы разного регистра.

Сохраните пароль и введите его снова на вновь открывшейся странице входа. После этого вы наконец-то окажетесь на главной странице роутера.

Здесь можно заметить ревизию устройства, которая фактически является неотъемлемой частью названия, так как под разными ревизиями скрываются по сути разные устройства. Нам, например, достался D-Link DIR-300NRU rev.B6 с прошивкой 1.3.0:

Настройка сети (интернет-соединения) D-Link DIR-300/NRU

Перейдём к настройке интернет-подключения. Нажмите большую кнопку Настроить вручную и перейдите в раздел Сеть > WAN. Здесь вы увидите созданное роутером подключение с названием «WAN»:

Так как в последнее время большинство новых прошивок D-Link довольно сырые и имеют множество недоработок, то для корректной настройки сети необходимо сначала удалить подключение по умолчанию. Для это нужно кликнуть на название этого подключения (откроется страница с детальным описанием подключения):

и нажать кнопку Удалить, которая находится в правом нижнем углу.

После этого подключение «WAN» должно пропасть из списка соединений:

Теперь нажмите Добавить и укажите следующие настройки нового подключения:

Главные настройкиТип соединения: PPPoEРазрешить: галка должна быть установлена

PPPИмя пользователя: ptnБез авторизации: галка должна быть снятаПароль: ptnПодтверждение пароля: ptnАлгоритм аутентификации: AUTOMTU: 1492 (в большинстве случаев менять не требуется)Keep Alive: галка должна быть установленаLCP интервалы (сек): 30LCP провалы: 3Отладка PPP: галка должна быть установлена (важно!)Проброс PPPoE: галка должна быть установлена (важно!)

РазноеNAT: галка должна быть установленаСетевой экран: галка должна быть установлена

После этого не забудьте нажать кнопку Сохранить. Если вы всё указали правильно, а роутер подключен к модему Авангарда, который работает и подключен к сети провайдера, то примерно через 1-2 минуты роутер подключится к интернету («Состояние» сменится на «Соединено»):

Осталось только задать настройки Wi-Fi.

Настройка Wi-Fi (беспроводной сети) D-Link DIR-300/NRU

Откройте раздел Wi-Fi > подраздел Основные настройки и укажите на этой странице:

SSID: название Wi-Fi сетиКанал: auto (если возникнут проблемы с подключением, попробуйте сменить на 6 или 10)Беспроводной режим: 802.11 B/G/N mixed

Для сохранения настроек нажмите Изменить.

На следующей вкладке — Настройки безопасности — укажите пароль для вашей беспроводной сети:

Сетевая аутентификация: WPA-PSK/WPA2-PSK mixedКлюч шифрования: пароль для подключения, от 8 символов, латинские символы и/или цифры

После завершения настроек и их сохранения мы рекомендуем перезагрузить устройство. Для этого откройте вкладку Система в верхней части страницы и выберите в выпадающем списке пункт Сохр. и Перезагрузить.

После загрузки устройства вы можете подключаться к вашей новой Wi-Fi сети и проверять её работу. Если окажется, что роутер так и не заработал, то для получения помощи в настройке D-Link DIR-300/NRU вы всегда можете обратиться к нам.

Connection Persistence / Re-Use

The HTTP/1.1 Spec states that connections can be re-used if they have not been closed – this is known as connection persistence.

Once a connection is released by the manager it stays open for re-use. When using a BasicHttpClientConnectionManager, which can only mange a single connection, the connection must be released before it is leased back again:

Example 6.1. BasicHttpClientConnectionManager Connection Reuse

Let’s take a look at what happens.

First – notice that we’re using a low-level connection first, just so that we have full control over when the connection gets released, then a normal higher level connection with a HttpClient. The complex low-level logic is not very relevant here – the only thing we care about is the releaseConnection call. That releases the only available connection and allows it to be reused.

Then, the client executes the GET request again with success. If we skip releasing the connection, we will get an IllegalStateException from the HttpClient:

Note that the existing connection isn’t closed, just released and then re-used by the second request.

In contrast to the above example, The PoolingHttpClientConnectionManager allows connection re-use transparently without the need to release a connection implicitly:

Example 6.2. PoolingHttpClientConnectionManager: Re-Using Connections with Threads

The example above has 10 threads, executing 10 requests but only sharing 5 connections.

Of course, this example relies on the server’s Keep-Alive timeout. To make sure the connections don’t die before being re-used it is recommended to configure the client with a Keep-Alive strategy (See Example 5.1.).

Настройка L2TP подключения

Главные настройки

Укажите тип соединения L2TP.

Имя — Имя не меняйте

Разрешить — Оставьте галочку

Физический уровень

Физический интерфейс — Port5

MTU — оставьте без изменений

МАС — Если у провайдера используется привязка по МАС-адресу, пропишите МАС-адрес вашего сетевого адаптера. Если привязки нет, поле МАС; оставьте без изменений.

Остальные Главные настройки и Физический уровень оставьте без изменений.

В поле Настройки PPTP/L2TP:

Соединяться автоматически — поставьте галочку

Как задать имя сервиса — укажите URL или IP

Имя сервиса — пропишите адрес VPN-сервера провайдера

Без авторизации — галочку не ставьте

PPP Имя пользователя — пропишите логин для доступа в интернет, выданный провайдером

Пароль — пропишите пароль для доступа в интернет, выданный провайдером

Подтверждение пароля — повторный ввод пароля

Шифрование — если у провайдера не используется MPPE-шифрование оставьте Без шифрования;. Если шифрование используется, установите MPPE AUTOили уточните тип шифрования у провайдера.

Алгоритм аутентификации — оставьте AUTO

KeepAlive — подключение будет постоянно включенным.

MTU — поменяйте значение на 1450 или меньше

В поле Разное проверьте, чтобы стояли галочки NAT и Сетевой экран.

Если провайдер предоставляет услугу интернет телевидения, поставьте галочку Включить IGMP.

Нажмите Сохранить;.

2.2. Why use TCP keepalive?

You can live quite happily without keepalive, so if you’re reading this,
you may be trying to understand if keepalive is a possible solution for
your problems. Either that or you’ve really got nothing more interesting
to do instead, and that’s okay too. 🙂

Keepalive is non-invasive, and in most cases, if you’re in doubt, you can
turn it on without the risk of doing something wrong. But do remember that
it generates extra network traffic, which can have an impact on routers
and firewalls.

In short, use your brain and be careful.

In the next section we will distinguish between the two target tasks for
keepalive:

Проблемы на линии

Со стороны провайдера могут произойти различные сбои в серверном оборудовании. Горящий индикатор роутера будет указывать на неполадку. Пользователю необходимо позвонить в службу поддержки.

Скорость восстановления сети определяется масштабами:

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

Мы рассказали, какие существуют простые и доступные методы восстановить работоспособность роутера. Если после всех манипуляций неполадка остаётся, настоятельно рекомендуем обратиться к специалистам сервисного центра.

2.3. Checking for dead peers

Keepalive can be used to advise you when your peer dies before it is able
to notify you. This could happen for several reasons, like kernel panic or
a brutal termination of the process handling that peer. Another scenario
that illustrates when you need keepalive to detect peer death is when the
peer is still alive but the network channel between it and you has gone
down. In this scenario, if the network doesn’t become operational again,
you have the equivalent of peer death. This is one of those situations
where normal TCP operations aren’t useful to check the connection status.

Think of a simple TCP connection between Peer A and Peer B: there is the
initial three-way handshake, with one SYN segment from A to B, the SYN/ACK
back from B to A, and the final ACK from A to B. At this time, we’re in a
stable status: connection is established, and now we would normally wait
for someone to send data over the channel. And here comes the problem:
unplug the power supply from B and instantaneously it will go down,
without sending anything over the network to notify A that the connection
is going to be broken. A, from its side, is ready to receive data, and has
no idea that B has crashed. Now restore the power supply to B and wait for
the system to restart. A and B are now back again, but while A knows about
a connection still active with B, B has no idea. The situation resolves
itself when A tries to send data to B over the dead connection, and B
replies with an RST packet, causing A to finally to close the connection.

Keepalive can tell you when another peer becomes unreachable without the
risk of false-positives. In fact, if the problem is in the network between
two peers, the keepalive action is to wait some time and then retry,
sending the keepalive packet before marking the connection as broken.

What is HTTP Keep-Alive

HTTP keep-alive, a.k.a., HTTP persistent connection, is an instruction that allows a single TCP connection to remain open for multiple HTTP requests/responses.

By default, HTTP connections close after each request. When someone visits your site, their browser needs to create new connections to request each of the files that make up your web pages (e.g. images, Javascript, and CSS stylesheets), a process that can lead to high page load times.

Enabling the keep-alive header allows you to serve all web page resources over a single connection. Keep-alive also reduces both CPU and memory usage on your server.

Протокол VRRP

VRRP — это аббревиатура Virtual Redundant Router Protocol. Группа физических маршрутизаторов объединяется в один виртуальный. Каждый участник группы может находиться в 3 состояниях:

неопределенном (initialize)
основном (master)
резервном (backup)

У всех участников группы в настройках присутствует 1 или несколько виртуальных адресов. У основного эти адреса присвоены сетевой карте, а у других — просто ждут своего часа.

Прежде всего надо сказать, что VRRP работает поверх IP, а не напрямую поверх канального уровня. Если быть точным, он использует групповой (multicast) адрес 224.0.0.18. Поскольку multicast по умолчанию не маршрутизируется, взаимодействие возможно только в пределах одной физической сети.

Это значит, что, помимо общего виртуального адреса, каждому маршрутизатору на каждом сетевом интерфейсе, где вы настраиваете VRRP, должен быть присвоен основной, с которого он будет отправлять соседям служебные пакеты.

Надо сразу сказать, что основной (служебный) адрес совсем не должен быть из одной сети с виртуальными. Если у вас недостаточно публичных адресов для тех сетевых карт, которые смотрят в интернет, вы вполне можете использовать частные адреса из RFC 1918 в качестве служебных. Ну, если настройки вашего провайдера этого не запрещают.

У каждой группы маршрутизаторов есть VRID — Virtual Router Identifier. Это просто число в диапазоне от 1 до 255. С каждой такой группой может быть ассоциирован 1 или несколько виртуальных адресов. На уровне протокола список адресов передается, но только для отладочных целей. Процесс VRRP их никак не использует, тем более что передаются они без маски подсети, так что за идентичностью настроек виртуальных адресов надо следить самому.

Группы с разным VRID друг с другом не взаимодействуют, поэтому в одной физической сети может быть любое количество независимых групп резервирования, главное — настроить.

При загрузке или первичной настройке VRRP участники группы оказываются в неопределенном состоянии (initialize) и выбирают, кому быть основным, а кому резервным. В настройках VRRP можно указать приоритет (priority) — маршрутизатор с наибольшим приоритетом выигрывает выборы.

Если приоритет у нескольких маршрутизаторов одинаковый, выигрывает тот, у кого самый большой адрес IP. Я сам стараюсь не полагаться на случай и всегда указываю приоритет явно.

Маршрутизатор, который выбрали основным, присваивает своей сетевой карте виртуальные адреса и начинает посылать остальным пакеты VRRP advertisement. Таким образом он сообщает, что еще функционирует и работоспособен.

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

Что будет, если бывший основной маршрутизатор вернется к жизни? Все зависит от опции в настройках. Если она включена, то он повторно инициирует выборы и вернет себе былую славу. Если нет, так и останется резервным.

Включать или не включать — вам решать. С одной стороны, с этой настройкой легко предсказать, какой маршрутизатор в данный момент основной, а с другой — переключений состояния, а значит, и потерянных пакетов будет больше. Я как правило включаю, но свое мнение никому не навязываю.

3.2. Making changes persistent to reboot

There are several ways to reconfigure your system every time it boots up.
First, remember that every Linux distribution has its own set of init
scripts called by init
(8). The most common
configurations include the /etc/rc.d/ directory, or
the alternative, /etc/init.d/. In any case, you can
set the parameters in any of the startup scripts, because keepalive
rereads the values every time its procedures need them. So if you change
the value of tcp_keepalive_intvl when the connection is
still up, the kernel will use the new value going forward.

There are three spots where the initialization commands should logically
be placed: the first is where your network is configured, the second is
the rc.local script, usually included in all
distributions, which is known as the place where user configuration setups
are done. The third place may already exist in your system. Referring back
to the sysctl
(8) tool, you can see
that the -p switch loads settings from the /etc/sysctl.conf configuration file. In many cases your init
script already performs the sysctl -p
(you can «grep» it in the configuration directory for
confirmation), and so you just have to add the lines in /etc/sysctl.conf to make them load at every boot. For more
information about the syntax of sysctl.conf(5), refer to the manpage.

Шаг 2 — Включение режима Keep-Alive

Существует несколько способов включения режима Keep-Alive и их выбор зависит от вашего сервера или провайдера услуг хостинга. Вот несколько вариантов:

Вариант 1 — Редактирование файла .htaccess

Добавление данного кода в ваш файл .htaccess должно помочь включить режим Keep-Alive. Включение режима Keep-Alive через .htaccess заменит собой любые настройки сервера и включит постоянное соединение.

Этот метод должен работать на большинстве виртуальных хостингов на базе Linux. В случае, если вы не знаете где найти файл .htaccess, обратитесь к этому руководству.

Вариант 2 — Включение режима Keep-Alive в Apache через файл httpd.conf

Если у вас есть доступ к файлу настроек Apache, вы можете включить режим оттуда. Вот как должны выглядеть настройки:

KeepAlive On включает режим Keep-Alive.
MaxKeepAliveRequests устанавливает максимальное количество запросов для одного соединения. 50 запросов для одного соединения считается оптимальным.
KeepAliveTimeout определяет, как долго сервер будет ожидать запрос от клиента. Рекомендуется начать с меньших значений, таких как 5 или 10 секунд и увеличивать их по мере необходимости. Выставление слишком больших значений может увеличить нагрузку на сервер.

Если вы не можете найти файл httpd.conf, запустите следующую команду в командной строке:

Вариант 3 — Включение Keep-Alive в NGINX

В NGINX, Keep-Alive по умолчанию обычно включен. Однако в некоторых случаях он может быть выключен. Вы можете включить его используя HttpCoreModule. Найдите значение keepalive_disable, которое в большинстве случаев является причиной его отключения. Перед внесением каких-либо изменений убедитесь, что узнали причину по которой он был отключен.

Вариант 4 — Сервер Windows (IIS)

Если вы используете сервер на базе Windows, вы можете легко включить режим Keep-Alive используя командную строку.

Данная команда включит режим Keep-Alive:

На случай если вы захотите его отключить используйте эту:

Вы также можете обратиться к официальному руководству от Microsoft на эту тему.

SIP телефоны и NAT

Сегодня мы поговорим о SIP телефонах. А именно, об опыте использования SIP телефонов в локальной сети офиса, которые подключаются к SIP серверу через публичную сеть Интернет. Если вы используете SIP-телефоны вместе с нашим облачным сервисом, то данная заметка будет полезна и поможет избежать основных проблем при работе IP телефонии за NAT.

Что такое NAT?

Начнем с того, а что же такое этот NAT?

Не буду копировать из wiki умные вещи, попробую объяснить проще — NAT (Network Address Translation) — это механизм, который позволяет маршрутизатору (наш сервер, роутер, модем – все, что используем для выхода в Интернет) определять какие сервисы находятся за роутером и должны быть доступны из интернета, чтобы пользователи оттуда могли этими сервисами пользоваться. Так как, в большинстве случаев, у нас всего 1 внешний (белый, публичный – как кому больше нравится) IP адрес, а устройств в сети много, то мы используем локальные (серые) IP адреса. Они не доступны из Интернета, а NAT помогает нам опубликовать в мир какой-то порт из локальной сети.

Надеюсь, что здесь пока все понятно…

Проблема телефонии за NAT

Начнем с голоса. Вряд ли стоит объяснять, почему NAT является проблемой для ого трафика. Если SIP протокол использует 1 статический порт на аппарате, то для голоса такой порт назначается динамически при каждом новом звонке. Как результат, каждый из нас знаком с ситуацией в IP-телефонией, когда голос ходит только в одном направление или вовсе отсутствует.

Сразу следует заметить, что универсального «лекарства» здесь нет: все решения этой проблемы в большей или меньшей степени частные. Впрочем, проблема обхода NAT ым потоком – это лишь одна сторона медали.

Вначале мы рассмотрим, какие препятствия создаёт NAT для сигнальных сообщений (в таких случаях звонок вообще не попадает на телефон за NAT) и какие расширения SIP были разработаны для их преодоления.

Обход NAT SIP-сигнализацией

При использовании UDP протокола, отправка ответа на SIP-запрос осуществляется на тот IP-адрес, с которого запрос был получен. Номер же порта для отправки извлекается из заголовка Via в SIP пакете. В случае использования NAT – это порт, на котором ожидает ответа наш IP телефон, но точно не тот порт, через который происходит NAT-трансляция и на котором NAT ожидает поступления ответа, чтобы его дальше направить уже на телефон. Мы получаем ситуацию, в которой звонок не может достичь SIP телефона:

Для решения этой проблемы SIP умеет отправлять ответ на порт, с которого запрос был получен, вместо порта, взятого из заголовка Via. При этом сам порт заносится в специальный параметр rport-заголовка Via. Это позволяет ответу найти соответствие в таблице NAT и достичь целевого узла. Этот метод называется симметричной маршрутизацией ответов.

Другая проблема заключается в том, что каждая запись в таблице трансляции NAT автоматически удаляется после определенного промежутка времени. Это актуально не только для установления нового соединения, но и во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы была удалена. В таких случаях мы можем наблюдать ситуацию, что звонок разрывается точно на 30-40 секунде.

Для решения данной проблемы, SIP умеет периодически отправлять запросы re-INVITE, OPTIONS, INFO, NOTIFY либо другие. В итоге мы получаем вот такую картинку:

Обход NAT медиатрафиком

Решение проблемы обхода NAT медиатрафиком требует более сложных изменений, поскольку необходимо заменить IP-адрес и номер порта, анонсированные в SDP-сообщении, таковыми, что обеспечат доставку потоков нужному адресату за NAT. Есть несколько способов решения данной проблемы, но, так как данная заметка уже получается довольно большой, я остановлюсь только на прохождении SIP, так как именно с этим чаще всего сталкиваются наши клиенты.

Keep Alive

Включить и отправлять каждые 30 секунд Keep Alive. У других производителей телефонов может называтся: re-INVITE, OPTIONS, INFO, NOTIFY

TCP/TLS

Также можно использовать TCP либо TLS вместо UDP. В некоторых случаях это более надежное решение для обхода NAT

При использовании TLS, следует обратить внимание, что порт подключения к webitel нужно указать 5071, вместо стандартного для UDP/TCP 5070

Отдельная сеть

Хорошей практикой является выделение для SIP телефонов отельной локальной сети с QoS приоритезацией ого трафика. Еще лучше – настроить отдельный VLAN под IP телефонию.

Configure the Connection Manager

The defaults of the pooling connection manager are well chosen but – depending on your use case – may be too small. So – let’s take a look at how we can configure:

the total number of connections
the maximum number of connections per (any) route
the maximum number of connections per a single, specific route

Example 4.1. Increasing the Number of Connections that Can be Open and Managed Beyond the default Limits

Let’s recap the API:

setMaxTotal(int max): Set the maximum number of total open connections.
setDefaultMaxPerRoute(int max): Set the maximum number of concurrent connections per route, which is 2 by default.
setMaxPerRoute(int max): Set the total number of concurrent connections to a specific route, which is 2 by default.

So, without changing the default, we’re going to reach the limits of the connection manager quite easily – let’s see how that looks like:

Example 4.2. Using Threads to Execute Connections

As we’ve already discussed, the per host connection limit is 2 by default. So, in this example, we’re trying to have 3 threads make 3 requests to the same host, but only 2 connections will be allocated in parallel.

Let’s take a look at the logs – we have three threads running but only 2 leased connections:

Достоинства

Ниже загрузка ЦПУ и расход памяти (потому как открывается меньше соединений одновременно).
Можно использовать HTTP pipelining (конвейерную обработку) запросов и ответов.
Снижает вероятность перегрузки сети (меньше TCP соединений).
Уменьшает лаги для последующих запросов (не нужно заново устанавливать TCP соединение).
Ошибки HTTP возвращаются без закрытия соединения — клиенты могут пробовать новые команды, и, если они не поддерживаются сервером, послать повторный запрос в том же соединении, используя старую семантику.

Эти достоинства особенно проявляются для защищённых HTTPS соединений, потому что создание защищённого соединения требует больше процессорного времени и сетевого обмена между клиентом и сервером.