В моем центральном офисе у меня есть устройство SonicWALL NSA-2400, выступающее в качестве концентратора для нескольких удаленных офисов. Он настроен на передачу DHCP-запросов моему внутреннему DHCP-серверу. VPN-соединение работает нормально, IP-адреса распределяются по удаленным офисам должным образом, и я очень доволен результатами - за исключением одного удаленного офиса.
В прошлую пятницу я установил младшего брата NSA-2400, NSA-240 в удаленном офисе. Оба брандмауэра всегда сообщают о надежном подключении, и все аспекты подключения к сети через туннель работают хорошо. Моя проблема в том, что до сих пор каждое утро мне звонили из удаленного офиса и говорили, что у них нет доступа к сети. В каждом случае они теряли свои IP-адреса, выданные DHCP-сервером моего корпоративного офиса, и получали «мусорные» адреса 169.xxx.
Перезапуск их брандмауэра и продление аренды DHCP сразу же решает проблему. Не удается продлить аренду DHCP без предварительного перезапуска брандмауэра.
Keep Alive включен на обоих брандмауэрах.
Очевидно, что после некоторого бездействия срок действия IP-адресов истекает. Может ли кто-нибудь пролить свет на это для меня?
ИЗМЕНИТЬ ДЛЯ ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ: На этом этапе я определил, что IP-адреса на удаленном сайте выходят из строя после 8 часов работы. Журналы указывают на сбои пакетов ARP примерно в это время. Повторюсь, даже после 8-часовой отметки туннель стабилен на обоих брандмауэрах, теряются только IP-адреса, назначенные DHCP. Я перезапустил удаленный брандмауэр сегодня утром в 7:45 и попросил их восстановить свои соединения, поэтому я получу от них еще один звонок в 4:45 и сообщу, что их Интернет отключен.
Адреса 169.X.Y.Z APIPA будут появляться только в результате отсутствия связи между вашими компьютерами и DHCP-сервером.
Быстрый обходной путь (но не без проблем) может заключаться в простой настройке статических адресов во время диагностики проблемы.
Чтобы диагностировать, я бы взял один из компьютеров с проблемой и обновил IP-адрес, отслеживая журнал брандмауэра. Или просто проверьте журнал брандмауэра, когда приходят пользователи или когда системы продлевают аренду DHCP.
Спасибо всем, кто помогал устранять неполадки. Вот решение моей проблемы:
Брандмауэр удаленного офиса был настроен с конфликтующими параметрами. С одной стороны, он должен был получать и распространять IP-адреса с моего корпоративного DHCP-сервера через брандмауэр. С другой стороны, он был настроен на предоставление локальных IP-адресов в случае сбоя туннеля.
После дополнительного расследования я пришел к выводу, что удаленные клиенты потеряли свои IP-адреса ровно через 8 часов после того, как я последний раз перезагружал их брандмауэр. 8 часов - это 28 800 секунд, или время жизни туннеля IPSec по умолчанию.
Обычно каждые 8 часов два межсетевых экрана пересматривают свое шифрование. Это повторное согласование займет более 2 секунд, и удаленный межсетевой экран будет думать, что туннель сломан, и попытается передать локальный IP-адрес своим клиентам. Согласование туннеля будет успешным через несколько секунд, туннель будет устойчивым на обоих концах, но удаленные клиенты будут иметь недопустимые IP-адреса.
Хотя я не знаю, почему возникла ваша проблема, я бы посоветовал разделить ваш DHCP, чтобы удаленные устройства обрабатывали определенный сегмент вашей общей области DHCP. Это также обеспечит некоторую резервную копию в случае проблем с подключением между сайтами, по крайней мере, в отношении поддержания работы удаленных сетей.
На сайте поддержки Sonicwall есть документ site_to_site_vpn_troubleshooting_on_sonicwall_security_appliances.pdf
Предоставляет шаги по устранению неполадок в этом типе сценария.