История изменений [назад]

По личному опыту - это болезнь ВСЕХ файрволов, которые используют исходящее соединение PPTP или PPPoE. Механика болезни:

1. Поднятие канала PPTP или PPPoE занимает длительное (с точки зрения компьютера) время. С момента реального поднятия порта и до окончания поднятия всей его обвязки порта проходит 1-4 сек (этакий переходной процесс).

2. Если за это время с клиента пытается установиться соединение, то на него в "мозгах" файрвола создаётся сессия, по которой файрвол отслеживает состояние и разрешает пакеты относящиеся к этой сессии без углублённого их анализа.

3. Если соединение с клиента попытается подняться в момент "переходного процесса", то сессия на него получается кривая. Если TCP быстро отвалится, т.к. сессия реально не установится, то UDP-сессия отваливается только по timeout, который обычно в районе 120 сек (в силу отсутствия в UDP понятия окончания сессии).

Получаем: клиент попал в "переходной процесс", получил кривую UDP-сессию, и постоянно стучится пытаясь аутентифицироваться, постоянно поддерживая timeout этой кривой UDP-сессии, не давая ей умереть.

У кого видел такую болезнь:

1. Аппаратные маршрутизаторы SPI (типа DLink, TPLink, ASUS, LinkSys и т.д.).

2. Программные маршрутизаторы SPI (типа Kerio Winroute Firewall и ему подобные).

Как лечить (варианты):

1. Уйти от PPTP и PPPoE. StaticIP и DHCP этой проблеме вроде не подвержены.

2. Установить время повторных попыток неудачной аутентификации больше времени жизни UDP-сессии на маршрутизаторе с SPI.

3. Отключить на маршрутизаторе SPI.

4. Мониторить состояние VoIP регистраций. Если более 3-4 попыток, попытаться дёрнуть канал PPTP/PPPoE, что бы "убить" кривые UDP-сессии из расчёта, что второй раз наше устройство так не влетит.

5. Убить кривые UDP-сессии на маршрутизаторе, в случае их появления.

По личному опыту - это болезнь ВСЕХ файрволов, файрволов SPI, которые используют исходящее соединение PPTP или PPPoE. Механика болезни:

1. Поднятие канала PPTP или PPPoE занимает длительное (с точки зрения компьютера) время. С момента реального поднятия порта и до окончания поднятия всей его обвязки порта проходит 1-4 сек (этакий переходной процесс).

2. Если за это время с клиента пытается установиться соединение, то на него в "мозгах" файрвола создаётся сессия, по которой файрвол отслеживает состояние и разрешает пакеты относящиеся к этой сессии без углублённого их анализа.

3. Если соединение с клиента попытается подняться в момент "переходного процесса", то сессия на него получается кривая. Если TCP быстро отвалится, т.к. сессия реально не установится, то UDP-сессия отваливается только по timeout, который обычно в районе 120 сек (в силу отсутствия в UDP понятия окончания сессии).

Получаем: клиент попал в "переходной процесс", получил кривую UDP-сессию, и постоянно стучится пытаясь аутентифицироваться, постоянно поддерживая timeout этой кривой UDP-сессии, не давая ей умереть.

У кого видел такую болезнь:

1. Аппаратные маршрутизаторы SPI (типа DLink, TPLink, ASUS, LinkSys и т.д.).

2. Программные маршрутизаторы SPI (типа Kerio Winroute Firewall и ему подобные).

Как лечить (варианты):

1. Уйти от PPTP и PPPoE. StaticIP и DHCP этой проблеме вроде не подвержены.

2. Установить время повторных попыток неудачной аутентификации больше времени жизни UDP-сессии на маршрутизаторе с SPI.

3. Отключить на маршрутизаторе SPI.

4. Мониторить состояние VoIP регистраций. Если более 3-4 попыток, попытаться дёрнуть канал PPTP/PPPoE, что бы "убить" кривые UDP-сессии из расчёта, что второй раз наше устройство так не влетит.

5. Убить кривые UDP-сессии на маршрутизаторе, в случае их появления.