Назад | Перейти на главную страницу

Масштабирование до десятков сотен туннелей IPSec и альтернативные методы безопасных транзакций

Мне может потребоваться добавить (для запуска) 10 туннелей IPSec в конструкции со спицами, в то время как связь является односторонней (лучи -> только концентратор) с целью сбора данных на сервере центральной базы данных. Каждая транзакция имеет небольшой размер, примерно 10 Кбайт в XML-данных, и каждая лучевая система инициирует примерно 10-20 транзакций в час. Также я должен отметить, что у меня нет контроля над лучевыми сетями; все периферийные устройства имеют статический общедоступный IP-адрес; все периферийные устройства на самом деле являются просто хостом за брандмауэром NAT, которому необходимо отправлять данные в центральную базу данных. Центральная база данных находится за брандмауэром NAT и для целей обсуждения находится в подсети 192.168.0.0/24.

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

Тем не менее, меня «убеждают» использовать туннели IPSec, потому что они наиболее «безопасны», но, на мой взгляд, я чувствую, что IPSec отлично подходит для большой доверенной сети или даже для наиболее надежных соединений LAN-LAN. между филиалами, особенно там, где у вас есть полный контроль над топологией сети, но не столько для очень узкой цели, которая (я думаю) может быть достигнута с помощью чего-то вроде туннелей SSH или пакетных заданий SFTP (или, возможно, по запросу / мобильный VPN?).

Если мне нужно использовать IPSec, как мне обрабатывать маршруты? Я имею в виду, что если моя центральная база данных находится в подсети 192.168.0.0/24, и у луча A есть такой же (или, возможно, другой туннель где-то еще с этим), как я смогу решить это? Статические маршруты на каждом «отправляющем» узле могут работать, но что, если этому узлу требуется доступ к той же подсети в другом месте?

Если не IPSec, что бы вы порекомендовали для защиты транзакций от одноранговых узлов к центральному узлу?

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

  1. Я получил форму для заполнения с подробным описанием схемы моей сети, включая подсети, которые потребуются для доступа к нашему новому крупному партнеру.
  2. Они отправили предварительно настроенное и полностью заблокированное устройство VPN.
  3. Я уже назначил ему общедоступный IP-адрес, поэтому я подключил его туда, где он мог бы использовать этот
  4. Моя компания заплатила Sprint небольшую плату за управление

Я знаю, что туннель был заблокирован только для порта (ов), необходимого для приложения.

Вывод для вас, на вашем месте:

  1. Выделите это, если можете. Есть компании, которые могут взять на себя внедрение и управление
  2. Если вы сделаете это самостоятельно, вам понадобится внедрить надежный процесс для привлечения новых партнеров.
  3. Вы также должны стандартизировать часть оборудования на стороне клиента.

Другой вывод - FFS, просто используйте защищенный протокол. SSH / SFTP / HTTPS полностью стандартны и чертовски безопасны - например, есть серверы SFTP, совместимые с FIPS.

Выполнение этого через туннели IPSec будет стоить вашей команде времени (а это деньги) или просто денег на контракт на управление сетью. Если ваш бизнес не в состоянии получить деньги взамен от ваших новых партнеров, просто сделайте продукт / процесс безопасным для начала.

Если вы застряли в этом, не делайте этого самостоятельно, потому что вам в конечном итоге придется поддерживать каждый проклятый маленький магазин, в котором есть маршрутизатор SOHO, и какого-то чувака внутри, которому нравится BitTorrent, а когда маршрутизаторы гадят, они ' Я буду звонить вам, чтобы узнать, почему ваше приложение не работает.

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