Провайдеры не видят, по каким урлам вы ходите и что вводите в поисковую строку - все крупные сайты давно работают по HTTPS, соответственно - максимум, что видно, это названия доменов, по которым вы ходите.
Воу, воу - какие серверы, какие циски? Девопс - это же руление на высоком уровне (с). Нужно облако, контейнеры, оркестрация с автомасштабированием - иначе это какое-то банальное админство получается, а не модный девопс.
Что нужно предпринять для обеспечения устойчивого соединения между Zabbix и Win Server 2008 по SNMP протоколу 161 порт ???
Процитирую:
1. Настроить службу SNMP на Windows Server, задать правильное имя community
2. Обеспечить доступ по сети с сервера Zabbix на Windows Server
3. Добавить хост в Zabbix.
Ваша инфраструктура - вы и настраивайте, экстрасенсы вернутся в начале сентября.
Заводить для подобных вещей отдельную железку в ваших масштабах - не очень-то оптимально, в том числе с точки зрения стоимости. VDS у любого нормального хостера мне видится более предпочтительным вариантом. Ограничить доступ только из дома можно с помощью VPN.
Нет в США регионов с минимальным пингом, оптику напрямик через ядро ещё никто пока не проложил. Большая часть кабелей идёт из Европы на восточное побережье - там хостинг и ищите.
Использовать для вашей задачи облака с платой за ресурсы - разорение. Ищите именно VDS, опционально - с балансировкой между несколькими, чтобы кратно увеличить лимиты по трафику/полосе.
С какого адреса пакеты уезжают в интернет в соответствии с правилами фаерволла/маршрутизации, такой и будет виден. Мало пробросить адрес в туннель - нужно ещё и сказать на шлюзе, с какого адреса выпускать данные из него в интернет.
Не нужно ничего сниффить, чтобы понять, TCP-пакет пришёл или UDP - он приедут в разные порты, соответственно - можно реализовать и отличающуюся обработку.
Что за впн-то? S2S - это вид конфигурации, а не название ПО. Если это IPSec - в винде есть встроенный клиент. Если что-то другое - наверняка клиент можно скачать.
Во-первых, хорошо было бы решить, по какому интерфейсу будет ехать трафик к шлюзу. Затем - обдумать, не получится ли, что ответ на пакет через один интерфейс уедет через второй - во многих дистрибутивах подобное поведение по умолчанию не обрабатывается.
Причина - размер пакета, который по пути приходится сначала фрагментировать, а на месте склеивать обратно. Чем тупее железка - тем для неё это сложнее. Если нет возможности это настроить на уровне приложения/ОС, можете попробовать прокинуть туннель, который будет сам этим заниматься, отправляя в интернет уже нормального размера пакеты. Стандарт - 1500 (1460) байт.
Я подразумеваю связку: Клиент -------- VPN1 ------- VPN2 -------- Интернет.
На клиенте настраиваете впн-коннект к серверу1, на сервере1 впн-коннект к серверу2 и форвард пакетов с маршрутизацией либо НАТом. Фактически, последнее звено необязательно даже заворачивать в впн - можно просто форвардить трафик с маскарадингом на втором сервере.
Даже если вы вкрячите вместо текущего свитча маршрутизатор - почему бы подсетям между собой не пинговаться, если не настроено (а по умолчанию это именно так) запретительных правил и вланов?
Сколько в линуксе сетевых карт - особо без разницы, виртуальные интерфейсы работают ровно так же, как настоящие. Можете на один физический интерфейс повесить сколько угодно адресов и маршрутизировать на здоровье.