Может Проснуться на работе LAN над соединением VPN?
1) Существует ли определенное снижение сервиса, если я разделяю хостинг сайта от хостинга базы данных? Как в, прежде чем я даже протестирую возможную задержку, действительно ли это - плохая идея? Кто-либо успешно уже сделал это?
Абсолютно. Я сделал это. Сроком на приблизительно 2 недели затем я быстро понял, что это не собиралось работать.
2) Существует ли хороший способ протестировать ответ SQL Server между теми базами данных, размещенными на том же поставщике по сравнению с размещенными с другим поставщиком? Я не являюсь сведущим в тестировании сайта и ответа базы данных по Интернету, таким образом, я неопределенен на том, где запустить.
Немного трудно сделать это, если Вы не можете копировать набор, не вовлекая себя в контракт. Возможно, попросите 30-дневную пробную версию или доберитесь, прокрутка ежемесячно сокращают и отменяют после первого месяца. Это - то, что я сделал со своим новым поставщиком, и я счастливо все еще с ними.
Что касается того, как протестировать его, SSMS имеет аккуратную функцию, названную "Клиентская Статистика Казни" - это - кнопка на панели задач, когда у Вас есть открытая вкладка запроса. Включите это, затем выполните запрос, и он дает Вам большую разбивку того, сколько трафика было передано, сколько времени он потратил ожидание сервера для ответа и т.д.
Сделайте это на на удаленном сайте-> серверы дб и локальный сайт-> серверы дб и сравните числа.
Обычно не, так как "MagicPacket" на самом деле на уровне 2. Это даже не routable без помощи средств передачи (например, помощник IP).
Я соглашаюсь с user48838 - по определению, волшебный пакет отправляется только по локальной подсети. Однако я ранее использовал сценарий, записанный jpo, который работал от другой подсети через нормальный маршрутизатор. Попробуйте это - YMMV
Старый тред, но я хотел вмешаться, потому что он по-прежнему является самым популярным результатом поиска по запросу "wol over vpn".
Да, волшебный пакет WOL определен в рамках ограничений уровня 2, но это не означает, что он не может содержаться внутри объекта сетевого и транспортного протокола, который затем может использоваться для его маршрутизации через VPN. Причина этого в том, что «волшебная» последовательность может находиться где угодно в пределах полезной нагрузки. Таким образом, по сути, речь идет о доставке обычного маршрутизируемого пакета на целевой хост с «волшебной» последовательностью внутри его полезной нагрузки.
Большинство реализаций волшебного пакета используют порт UDP 9, хотя это действительно не имеет значения, если это так. правильно маршрутизируется и передается в том же широковещательном домене, что и целевой компьютер. Пока у VPN-клиента есть правильные маршруты, он может правильно послать широковещательный пакет, такой как 192.168.1.255 (широковещательный адрес), на шлюз VPN через Интернет.
Таким образом, маршрутизация действительно проста, проблема может заключаться в правильной широковещательной передаче от целевого шлюза VPN. Это означает настройку шлюза VPN / поиск опции для пересылки широковещательного трафика от удаленных клиентов VPN в локальную сеть.
Существует интересный способ построить туннель уровня 2 с SSH, и с этим WOL должен хорошо работать. Поэтому я не вижу причин обходиться без отправки машин в спящий режим.
На основе упоминания @slm я включил важные части источника ниже.
Предварительные требования:
1) на обоих компьютерах должен быть включен вход в систему root . (извините - ваши учетные данные на обоих компьютерах должны позволять вам создавать устройство TAP). Это означает: на системном уровне у root есть пароль;
2) в файле sshd_config хоста, на котором запущен демон ssh, установлены параметры PermitTunnel yes и PermitRootLogin yes;
3) переадресация ip включена в ядре. Используйте команду sysctl, чтобы установить этот параметр: sysctl -w net.ipv4.ip_forwarding = 1; также добавьте строку net.ipv4.ip_forwarding = 1 в ваш файл /etc/sysctl.conf, чтобы параметр сохранялся после перезагрузки. Сделайте это на обоих компьютерах;
4) Вы установили пакет bridge-utils, или иным образом используйте команду brctl на обоих компьютерах.
Создайте туннель:
ssh -w 1: 1 -o Tunnel = ethernet hostname
опция -w устанавливает имя TAP-устройства на любом хосте (здесь tap1 будет создан на обоих концах).
параметр -o предназначен для указания параметра файла конфигурации в командной строке. Мы используем Tunnel = ethernet для настройки туннеля уровня 2.
Эта форма будет держать сеанс ssh открытым на переднем плане. Если вы хотите, чтобы оболочка была отключена после того, как туннель установлен, вы можете использовать параметр -f, чтобы указать, что он должен выполнить ответвление в фоновом режиме. Однако ему нужна команда для разветвления, поэтому вы можете просто использовать фиктивную команду, например true, чтобы заставить ее работать. Вы также можете использовать эту функцию для настройки моста на удаленном конце, но сейчас я не собираюсь вдаваться в подробности. Итак, это будет выглядеть так:
ssh -f -w 1: 1 -o Tunnel = ethernet hostname true
Добавить устройства TAP к мосту:
brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up
вы запускаете это на обоих хостах (обратите внимание, что я не назначал IP). brctl - это команда, используемая для управления устройствами моста. brctl addbr добавляет мост br0, а команда addif присоединяет к нему устройство tap1.
Следующим шагом будет добавление физических интерфейсов Ethernet к устройству моста. То, как вы захотите это сделать, будет различным, поэтому я рассмотрю несколько сценариев. В первом сценарии ваши узлы VPN находятся в одной подсети (т. Е. Между ними нет маршрутизации), а во втором сценарии - через Интернет.
Бесстыдно украдено с: http: //la11111.wordpress. com / 2012/09/24 / layer-2-vpns-using-ssh /
well actually the answer is YES.
I successfully use WOL over PPTP VPN using that app: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
Да, вы можете, вместо того, чтобы посылать пакет WoL на широковещательный адрес в целевой сети, просто послать его на IP-адрес машины, которую вы хотите проснуть. Программы, протестированные с помощью PPTP VPN:
Я проверил это и получил ответ ДА :)
Я нашел в Интернете инструмент, который отправляет пакет WOL как uni-cast на предполагаемый хост, что позволяет избежать передачи широковещательного пакета через маршрутизатор.
Один момент, на который вам нужно обратить внимание при использовании этого решения, - вам нужно поместить статическую запись arp в маршрутизатор, поскольку хост будет отключен и не будет отвечать на ARP-запрос маршрутизатора. Ура!
Есть 2 момента для анализа.
1 - Маршрутизация.
2 - Преобразование ip в mac адрес. (таблица arp)
Большинство людей знают, как маршрутизировать. Что происходит, так это то, что люди правильно маршрутизируют пакеты, но не знают, почему они не могут разбудить устройство по локальной сети. Поскольку протокол arp (протокол разрешения адресов - arp) выполняется автоматически, у людей недостаточно знаний о том, как он работает, чтобы правильно понять проблему.
Я собираюсь использовать очень простое объяснение без лишних подробностей, чтобы было легко понять концепцию. Когда маршрутизатор получает пакет (, значит, маршрутизация уже работает нормально) и ему необходимо отправить пакет на машину, ему необходимо преобразовать IP-адрес в MAC-адрес. Приходит посылка, роутер конвертирует ip в mac, и отправляет на машину.
Что делает роутер, чтобы получить этот Mac? Откуда он знает mac каждой машины?
Он спрашивает! Поэтому, когда он получает пакет на ip 192.168.1.45 в первый раз, пакет отправляется через широковещательную рассылку, и 192.168.1.45 ответит. Когда приходит ответ, адрес попадает в arp-таблицу. Теперь он знает мак-адрес и больше его запрашивать не нужно (в течение 6 часов). Когда приходит пакет для этой машины, он использует MAC-адрес на столе, не спрашивая снова.
Хорошо. Таким образом, маршрутизатор должен знать mac-адрес машины, чтобы иметь возможность отправлять информацию.
Что касается пакета Wake on Lan, в чем проблема?
Роутер не будет иметь mac-адрес машины, которая выключена, и, вероятно, ее больше не будет в таблице arp (по умолчанию адрес на столе в течение 6 часов, прежде чем спросить снова).
Что будет без mac-адреса?
Роутер "спросит" mac-адрес, но машина выключена и не сможет ответить маршрутизатору. Затем маршрутизатор без этой информации сбросит пакет.
Как решить проблему?
Добавив фиксированную запись arp на роутере. Таким образом, маршрутизатор всегда будет знать mac-адрес и сможет отправить пакет на машину, даже если она выключена!
На маршрутизаторе Openwrt вам необходимо использовать пакет ip. И вам нужно установить его в первую очередь.
Для этого примера нам нужно разбудить IP-адрес 192.168.1.45 с mac-адресом 00:de:ad:be:gf:00. Для этого мы будем использовать эту команду (добавьте ее в сценарий запуска с маршрутизатора):
ip neigh add 192.168.1.45 lladdr 00:de:ad:be:gf:00 nud Permanent dev br-lan
Теперь известен mac-адрес машины (в сети br-lan)
Что теперь?
Теперь маршрутизатор попытается направить пакет на выключенную машину и будет в состоянии отправить пакет, так как он знает mac-адрес, который зафиксирован в таблице arp!
Теперь вы можете использовать несколько инструментов, чтобы правильно разбудить машину через vpn!
Wol software:
Windows:
https://www.tweaking4all.com/applications/miniwol2/
Когда вы открываете программу, она отправит пакет wol на настроенные машины, а затем завершит работу.Android:
https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan
WOL без VPN — через Интернет!
Вы также можете отправить его по глобальной сети (через Интернет) без VPN, используя тот же принцип.
- Добавить адрес в arp-таблицу ("ip neigh add" выше)
- Сделать DNAT через порт wan udp 9, указывающий на машину, порт udp 9.