Приветствую, коллеги!

В последнее время в одной из контор, которым я ставил DFL-260E, появилось много замечаний по работе Интернета: сайты то открываются, то нет, периодически недоступен почтовик на хостинге, к VPN-серверу снаружи не могут прицепиться, хотя раньше все работало великолепно...

Подключение - Static WAN IP, внешний IP.

Оператор говорит, что ничего не делал, и "его хата скраю" (с)
Рекомендации техподдержки - попробовать заменить оборудование.

Пытаюсь снаружи подключиться по HTTPS на WAN-порт - удалось не с первого раза.
Минут 15-20 работаю, потом железка недоступна... Лечится перезагрузкой по питанию, хотя "самовылечивание" волшебным образом минут через 15-20 тоже имеет место быть, и снова железка становится доступна, но не долго - минут на 10-15.
При этом из локалки интерфейс DFL'ки доступен без проблем, подключаюсь и работаю.

Заглянул в лог. Привлекла внимание достаточно часто повторяющаяся запись: unacceptable_ack (ID: 03300017)
В Log_Reference_Guide.pdf написано:

Log Message:
TCP acknowledgement <ack> is not in the acceptable range
<accstart>-<accend>. Dropping

Explanation:
A TCP segment with an unacceptable acknowledgement number was
received during state SYN_SENT. The packet will be dropped.

Если присмотреться, то действительно, ack не находится в диапазоне accstart - accend.
Нарыл похожую проблему с acknowledgement Nr на форуме: http://forum.dlink.ru/viewtopic.php?p=633622#p633622
суть которой сводится к тому, что
""-странный Acknowledgment number" назначает не дфл, а веб-сервер
-"Странный Acknowledgment number" действительно назначает сервер, а не МЭ. Но так происходит не со всяким сервером, а с достаточно удаленным (по-видимому вне пределов автономной системы провайдера исходящего канала). С близлежащими серверами, расположенными в автономных системах обоих провайдеров (имеющих отношения соседства друг с другом) соединения успешно устанавливаются. Есть подозрение, что при выходе за пределы АС sequence number исходящего пакета преднамеренно искажается маршрутизатором."

Не могу грешить на DFL'ку с аптаймом всего лишь полгода... Тем более явно косяк со стороны WAN-порта. Похоже, Оператора штормит немного...
Кто что скажет?

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

По-моему, рекомендация "заменить оборудование" не лишена смысла, если это возможно.

Это поможет сузить проблему.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

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

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Опции контроля TCP не позволяют ACK проблемы пропускать, только очистить лог от них...
С виду - возвратный трафик в локалку, только не понятно отчего шлюз что-то знает внутренний адрес? Нет NAT?
Я бы снял трафика pcapdump'ом и проанализировал ошибочные пакеты.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Решил проблему.
Косяк был в неправильной адрессации со стороны провайдера.
Тема закрыта.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...