Когда между офисами нужен единый интернет и одинаковые политики доступа, обычных «удалённых подключений» обычно не хватает. Чаще всего выстраивают постоянный VPN-канал, чтобы филиалы обменивались данными так, как будто находятся в одной сети. Но именно на настройке site-to-site люди чаще всего теряются, потому что важно не только «поднять туннель», а сделать так, чтобы маршруты совпали, адреса не конфликтовали и безопасность не просела.
Ниже я проведу сквозной сценарий, на котором можно проверить каждую деталь: у компании два офиса, нужно соединить их по IPsec site-to-site, в филиале около 5–15 пользователей, админ один, а простой и предсказуемый результат важнее экспериментов. Сквозная мысль статьи такая: site-to-site VPN между офисами получается устойчивым только тогда, когда вы заранее фиксируете адресацию, маршруты и параметры криптографии, а настройку делаете по строгой последовательности.
Какие решения подходят для VPN между офисами и где чаще всего ошибаются
Для site-to-site используют два основных семейства подходов: IPsec и SSL VPN. SSL-решения в первую очередь рассчитаны на доступ пользователей или устройств к приложению через веб или выделенный клиент, а вот «сеть к сети» там часто упирается в ограничения по маршрутизации и модели доверия. Поэтому в типичном сценарии «офис с офисом» практичнее брать IPsec, где туннель строится на уровне сети и можно прозрачно прокидывать подсети филиала.
Важное уточнение: под «каналом» люди понимают разное. Один вариант это туннель между двумя VPN-шлюзами, который затем маршрутизирует трафик между подсетями. Второй вариант это просто доступ на конкретные сервисы. При настройке site-to-site vpn туннель между офисами почти всегда нужен именно первый вариант, иначе отделы начнут жаловаться, что бухгалтерия может открыть базу, а принтер по другому адресу не отвечает.
Если говорить о реальных ожиданиях, то на стороне оборудования обычно есть готовые пресеты. Они облегчают старт, но при этом маскируют ошибки в адресах. Я часто вижу, как админы делают так: в двух офисах под разные сегменты назначают одинаковые частные подсети, например 192.168.10.0/24. В результате пакеты не уходят туда, куда вы их ждете, потому что маршрутизаторы путают «локальное» с «удалённым». Эта ошибка не исправляется «тонкой настройкой шифра», она лечится только пересмотром адресного плана.
Чтобы не попасть в ловушку неверных ожиданий, стоит понимать, что в IPsec есть две части, которые отвечают за связность. Это фаза согласования ключей, которую в терминах документации часто описывают как IKE, и затем шифрование трафика в рамках Security Association. В документации StrongSwan прямо сказано: «IKE is used to negotiate the security association for IPsec». StrongSwan, документация проекта, раздел об IKE (документация StrongSwan, актуальна на момент опубликованных материалов проекта).
Если вы сравниваете подходы, то простой критерий такой: если задача именно vpn туннель между офисами, то нужна маршрутизация подсетей через два шлюза. В этом критерии IPsec выигрывает, а SSL VPN чаще проигрывает, потому что проектируется под доступ клиентов. С другой стороны, если филиалы действительно маленькие и вам нужно в основном подключение людей к приложениям, а не полная связность, SSL может быть быстрее к запуску. В нашем сквозном сценарии мы сразу выбираем IPsec site-to-site, чтобы потом не переделывать архитектуру.
Однако даже правильный выбор не спасает от главной ошибки: «подняли туннель, но сети не видят друг друга». Обычно причина не в том, что шифрование «не сошлось», а в маршрутах и политике firewall. С этим как раз связана следующая задача: как правильно собрать план адресов, определить, что будет источником и приемником трафика, и какие маршруты должны появиться на обоих концах.
Как спроектировать адресацию и маршрутизацию, чтобы туннель работал с первого раза
Перед любыми параметрами криптографии я бы зафиксировал адресный план и договорился с собой, кто за что отвечает. В двух офисах должны быть определены две подсети, которые вы хотите связать. Например, в главном офисе используем 10.10.10.0/24, в филиале 10.20.20.0/24. Важно, чтобы эти подсети не пересекались и не совпадали ни с чем локальным на обоих концах, иначе маршрутизатор будет считать трафик «локальным» и не станет отправлять его в VPN.
Следом решают вопрос шлюза. Если у вас две Edge-устройства или два роутера, то у каждого есть внешний интерфейс с публичным адресом. Именно на него направляется переговор IKE, и именно на этот путь ориентируется site-to-site vpn туннель между офисами. На практике это означает, что вы должны знать два публичных IP или DNS-имени, а также понимать, какой NAT стоит на пути, если он есть. Если NAT есть, то чаще всего всё равно можно настроить нормально, но вам нужно будет учитывать, какой адрес указывать в конфигурации и какие порты открыть.
Тут полезно помнить о том, что IPsec не «пробивает интернет по умолчанию». Вам нужно заранее открыть входящие порты и позволить нужные протоколы на внешней границе. Для IKE обычно используется UDP 500, а для NAT-T часто требуется UDP 4500. Эти детали завязаны на конкретный профиль, но принцип один: если снаружи трафик блокируется, туннель не поднимется, даже если криптопара идеальная.
Теперь про маршруты. После согласования IPsec шлюзы должны обмениваться маршрутом так, чтобы трафик между 10.10.10.0/24 и 10.20.20.0/24 попадал в туннель. Самый простой рабочий вариант это статические маршруты на обоих роутерах. На главном офисе вы говорите: подсеть филиала 10.20.20.0/24 доступна через VPN-интерфейс или через следующий хоп, который направляет пакет в шифрованный туннель. На филиале аналогично: 10.10.10.0/24 уходит в VPN. При этом на интерфейсах локальной сети и на межсетевом экране должны быть разрешены соответствующие направления.
И вот где чаще всего ломается связность. Настройка фаз IPsec и политики может быть идеальной, но если на одной стороне firewall забыли разрешить пересылку «внутрь туннеля», вы получите пинг, который иногда отвечает, но потом обрывается, или сервисы открываются только частично. В практическом разборе я бы проверял так: сначала проверяйте, видит ли ваш шлюз удалённую подсеть маршрутом, затем проверяйте политику firewall на шлюзе, и только потом тестируйте клиентами.
В этом месте полезно сравнение двух сценариев: как вы делаете маршрутизацию, статикой или динамикой. Статика проще и предсказуемее, особенно когда филиалов два, а подсетей немного. Динамика через протоколы маршрутизации позволяет масштабироваться, но добавляет ещё один слой ошибок и больше зависимости от правильной настройки обмена маршрутами. В вашем сценарии с 5–15 пользователями и двумя офисами я бы выбирал статические маршруты, потому что это быстрее проверяется и проще отлаживается.
С этим проектированием уже понятно, что будет трафиком и куда его отправлять. Следующий логичный вопрос это: какие именно параметры IPsec выставлять, как согласовать параметры на обоих концах и что проверять, когда туннель поднимается, но связь не проходит.
Как настроить IPsec site-to-site: параметры IKE, SA, PSK и проверки
Когда адреса и маршруты фиксированы, вы переходите к IPsec. На практике ключевой момент это согласование параметров на обоих концах. Даже если туннель называется «одинаково», параметры могут отличаться в деталях, и тогда IKE не сможет согласовать Security Association. Поэтому я советую начинать с самых стабильных комбинаций и держать их одинаковыми на обоих шлюзах, включая версию IKE, режим хеширования и размер ключей.
Обычно в конфигурации есть блок IKE с версией 1 или 2, профиль шифрования, алгоритмы аутентификации и жизненный цикл. Дальше идет блок IPsec SA для данных, где задают набор алгоритмов, например ESP с AES-GCM или AES-CBC плюс HMAC, и также lifetime. В типовой схеме вы настраиваете Phase 1 (IKE) и Phase 2 (IPsec) так, чтобы они совпали. Если у вас обе стороны это одно семейство оборудования или один стек, вы быстрее получите совпадение параметров, но это не отменяет проверку.
Отдельно выбирают механизм аутентификации. Для небольших площадок часто берут PSK. Это быстрее, чем сертификаты, и админ один с этим справится. Но на практике PSK чувствителен к опечаткам и кодировкам, поэтому лучше использовать длинную строку, хранить её безопасно и не менять её «по дороге». При этом сертификаты дают более сложную инфраструктуру, зато уменьшают риск ошибки при смене ключей. В нашем сценарии 5–15 пользователей это обычно оправданный компромисс в пользу PSK.
Про лимиты согласования полезно смотреть на документацию конкретного клиента или сервера. В руководстве strongSwan по конфигурированию IPsec встречается акцент на то, что IKE используется для договоренности SA для IPsec, а это напрямую влияет на то, какие параметры будут проверяться во время настройки. Там сказано: «IKE is used to negotiate the security association for IPsec». StrongSwan, документация, раздел об IKE (актуальность соответствует опубликованной документации проекта).
Теперь про жизненные проверки. Когда вы сделали настройку, я бы не начинал сразу с клиентов. Сначала проверьте логи на шлюзах: есть ли строки о согласовании IKE, как часто идут retransmission, и есть ли сообщения об ошибках предложений, например mismatch transform или no proposal chosen. Затем проверяйте, появилась ли SA для ESP, и есть ли реальная запись в таблицах шифрования. На многих платформах это видно через команду просмотра текущих SA или через экран диагностики в интерфейсе.
Для понимания «почему туннель есть, а связи нет» полезен разбор неудачного сценария. Частая ошибка это неправильные селекторы трафика, то есть traffic selectors или SPD правила. Админы указывают, что шифровать надо трафик из 10.10.10.0/24 в 10.20.20.0/24, но на одной стороне подсеть задают как 10.20.20.0/23 вместо 10.20.20.0/24. В этом случае SA согласуется, но конкретные пакеты могут не попадать под политику шифрования. Результат выглядит как частичное прохождение, а не полный отказ. Исправляется только точной настройкой селекторов.
Если в логах всё чисто, SA для нужных подсетей присутствует, но клиенты всё равно не достучались, переходите к проверке firewall правил на шлюзе. Часто правило разрешает трафик, но забывает про входящие интерфейсы или про то, что политика применяется только к физическому интерфейсу, а не к VPN-интерфейсу. Вот тут обычно всплывает разница между «туннель поднялся» и «туннель пропускает нужный трафик».
Итак, криптографическая часть и селекторы настроены. Остается последний рубеж: как обеспечить безопасность, стабильность и удобство эксплуатации, чтобы этот VPN-канал не превращался в постоянный источник тикетов.
Как сделать VPN-канал между офисами стабильным, безопасным и удобным для поддержки
Стабильность site-to-site зависит не только от IPsec. На практике она держится на трёх вещах: корректных таймерах, контроле MTU и аккуратных правилах на маршрутизаторе. Таймеры это lifetimes в IKE и IPsec, которые должны совпадать по смыслу. Если на одной стороне lifetimes короткие, а на другой длинные, вы получите частые renegotiation и периодические разрывы. В небольших филиалах я бы не гнался за минимальными значениями, но и слишком большие интервалы тоже не выбирал, чтобы не тащить «старые» ключи дольше нужного.
MTU и фрагментация всплывают, когда по туннелю гоняют не только обычный трафик, но и файлы или потоки, где важна скорость и отсутствие потерь. В IPsec накладные расходы на заголовки реальны, и если физический MTU на линке слишком узкий, может появиться фрагментация. На части платформ это лечится настройкой MSS clamp или уменьшением MTU на VPN-интерфейсе. Если вы видите потери при больших пакетах, начинать диагностику лучше с измерения MTU и проверки, как проходит TCP MSS.
Теперь про безопасность. При PSK я бы ужесточил правило доступа к шлюзу: не публиковать диагностику наружу, ограничить адреса, с которых разрешены входящие IKE/ESP-порты, и следить за тем, чтобы не было «any-to-any» внутри. Сам IPsec шифрует трафик, но правила маршрутизатора решают, какие соединения вообще начнут обрабатываться. На практике самый частый компромисс это ограничить разрешения по подсетям: если нужен доступ из 10.10.10.0/24 к 10.20.20.0/24 только для бухгалтерии, это стоит описать в правилах, а не давать полный доступ всему сегменту.
Есть ещё один аспект, который многие пропускают, и он потом портит поддержку. Это журналирование и мониторинг. Без логов вы останетесь с догадками, а с логами вы быстро поймете, почему туннель «то работает, то нет». Я бы настроил просмотр состояния SA, событий IKE и счётчики пакетов на обоих концах, а также оповещения при разрыве. На многих платформах достаточно включить расширенные логи на время ввода в эксплуатацию, а затем оставить базовый уровень постоянно.
Чтобы это не было абстракцией, вернёмся к сквозному сценарию. Два офиса, 10.10.10.0/24 и 10.20.20.0/24, 5–15 пользователей в филиале. Вы подняли IPsec site-to-site с PSK, указали селекторы, проверили SA. Потом на главном офисе разрешили входящий трафик из 10.20.20.0/24 только к нужным сервисам. На филиале сделали то же самое наоборот. В тесте с клиента вы проверяете три вещи: маршрутизация, доступ к сервису и отсутствие потерь при загрузке большого файла. Если всё проходит, вы фиксируете настройки и документируете параметры, чтобы при замене устройства не начинать с нуля.
У этого подхода есть ограничение. Если со временем появятся дополнительные подсети или новые филиалы, статические маршруты и селекторы придётся обновлять. Тогда полезно заранее продумать, как вы будете расширяться: либо остаётесь на статике и аккуратно меняете правила, либо переходите к более динамичной схеме маршрутизации. В маленькой системе это не проблема, но в тот момент, когда подсетей станет больше, вы почувствуете стоимость ручных правок.
В конце вам нужно пройти короткую дорожку, чтобы создание vpn канала между офисами не зависело от удачи. Сначала вы фиксируете адреса подсетей и убеждаетесь, что они не пересекаются. Затем назначаете статические маршруты и правила firewall так, чтобы трафик реально отправлялся в VPN-интерфейс. Потом настраиваете IPsec site-to-site одинаковые параметры IKE и IPsec, задаёте корректные traffic selectors для нужных подсетей и проверяете SA по логам. После этого вы включаете мониторинг, проверяете MTU и задаете минимально необходимые разрешения по доступу. Когда эти шаги закрыты, vpn туннель между офисами начинает работать стабильно, а администрирование превращается в понятную рутину, а не в лотерею.
