Документы в формате PDF, архив (FTP) и Web-справка открываются в новом окне
Новый сайт — стильный и современный
Содержимое обоих сайтов идентично, различие только в оформлении.
Размер шрифта AAA
Построение VPN на основе IPsec между двумя офисами с резервированием через сотового оператора
Требуется подключить филиал к центральному офису посредством виртуальной частной сети (VPN) на основе технологии IPsec. Основной канал связи — наземная сеть Ethernet. Для резервирования используется сотовая сеть LTE или 3G. Используется устройство NSG–2030 с опцией opt.LTE/3G. В головном офисе может использоваться как устройство NSG (например, NSG–5260), так и программный или аппаратный VPN-шлюз вероятного противника.
Весь остальной трафик из локальной сети филиала надлежит отправлять в Интернет обычным образом.
Основная проблема состоит в том, что порт Ethernet не имеет встроенных средств для контроля соединения выше, чем на физическом уровне. Если связь оборвётся за ближайшим коммутатором или где-либо дальше, то устройство об этом не узнает. Кроме того, пройдёт достаточно большое время, пока IPsec обнаружит потерю связи и переустановит туннель. Поэтому в устройствах NSG для контроля канала предусмотрен механизм netping, работающий на 3 уровне. В зависимости от доступности контрольного хоста, он манипулирует маршрутом по умолчанию. IPsec в данной ситуации рестартует автоматически.
Второй процесс netping следит за состоянием сотового соединения и при необходимости рестратует его. В качестве контрольного хоста для него используется один из DNS Яндекса.
(Предполагается, что данное устройство является в настройках IPsec стороной left.)
Существенные элементы настройки центрального шлюза VPN:
Шлюз должен принимать соединения с IP-адресов клиента в сетях обоих провайдеров (если эти адреса статические), либо с любого адреса (в этом случае адреса могут быть динамическими и приватными в сетях провайдеров).
Если по пути между клиентом и центральным шлюзом где-либо производится NAT, то на сервере должна быть включена поддержка NAT Traversal (NAT–T). На устройстве NSG поддержка NAT–T включена по умолчанию.
Для своевременного удаления мёртвых туннелей должно быть включено Dead Peer Detection (DPD). На устройстве NSG DPD включено по умолчанию с таймаутом 4×30 сек.
Если разрешёно соединение с клиентом по любому адресу, то аутентификация с помощью PSK становится, по существу, однофакторной и на сегодняшний день уже не является достаточно надёжной. Рекомендуется использовать в этом случае аутентификацию на основе асимметричных ключей RSA и сертификатов X.509.
Значение ikelifetime на центральном шлюзе следует устанавливать меньше, чем на клиентах (в NSG Linux 2.0 по умолчанию — 3600 сек.)
Дополнительные замечания:
Обязательно задание пароля для доступа к устройству.
В целях безопасности настоятельно рекомендуется также:
Отключить Telnet и использовать для удалённого управления только SSH
Заблокировать HTTP с помощью фильтров и использовать для удалённого управления только HTTPS
Запретить доступ с любых посторонних IP-адресов с помощью фильтров
NAT применяется к исходящему трафику раньше, чем отбор приватных пакетов в туннель IPsec. Правило nat.POSTROUTING.1 необходимо для того, чтобы исключить эти пакеты из-под действия NAT. Если никакого транзитного трафика в публичную сеть не должно быть вообще (весь трафик из локальной сети направляется только по туннелю в головной офис), то NAT не нужен вообще.
Организацию служб LAN и WLAN в офисе см. в примерах: