Как перенести сайт на виртуальный сервер


Как перенести сайт на VPS самостоятельно? Установка сайта на VPS

В статье описывается, как перенести сайт с обычного хостинга сайтов Hosting Linux на VPS с ОС Linux. При этом осуществляется только перенос самого сайта. Почта и настройки, добавленные через панель управления, перенесены не будут.

Обратите внимание!

В статье не рассказывается о том, как перенести сайт с денвера на хостинг. Информацию о переносе с денвера (дистрибутивов и сайта, размещенного на локальном ПК) вы можете найти на специализированных форумах.

Перенос сайта на VPS

Данная инструкция описывает только перенос самого сайта.

  1. 1.

    Закажите VPS по необходимому тарифному плану и дождитесь активации услуги.

    Бесплатный SSL

    При заказе VPS вы можете получить бесплатный SSL-сертификат. При этом, если на текущей услуге виртуального хостинга уже установлен бесплатный сертификат, рекомендуем его переиздать.

    При заказе SSL активируйте галочку заказа бесплатного сертификата. Это позволит вам после переноса отказаться от прошлой услуги хостинга и вернуть деньги за неиспользованный период.

  2. 2. Добавьте домен на сервер. Для этого воспользуйтесь статьей Как привязать домен к VPS.
  3. 3. Создайте бэкап сайта на текущей услуге хостинга. Создать и скачать архив сайта можно через Систему резервного копирования. Вы можете сформировать как утренний архив за текущую дату, так и архив в пределах 30 прошедших дней;
  4. 4. Разверните архив сайта на VPS. Инструкция для хостинг-панели ISPmanager: Как разместить сайт в ISPmanager 5;
  5. 5. Проверьте корректность переноса при помощи инструкции;
  6. 6.

    Дождитесь обновления DNS-серверов интернет-провайдеров. Обычно на это уходит около 24 часов.

Для услуг Wordpress Hosting или бесплатный хостинг для сайтов Wordpress процедура переноса будет отличаться. Перенос вордпресс описан в статье: Как перенести сайт на WordPress на другой хостинг?

Помогла ли вам статья?

34 раза уже
помогла

Перенос существующего сайта

В этом руководстве рассматриваются следующие темы:

После того, как вы выбрали домен, вы можете легко перенести существующий сайт в SiteGround на шаге 2 мастера настройки веб-сайта . Чтобы начать перенос сайта, щелкните Выберите в разделе Перенести веб-сайт .

Затем у вас есть возможность выбрать между автоматической миграцией, доступной для сайтов WordPress через наш плагин Migrator, или профессиональной миграцией, выполняемой нашими экспертами.

Перенести существующий сайт с помощью автоматизации WordPress

Если вы решили продолжить автоматический перенос, выберите WordPress Automigration и нажмите Продолжить .

На последнем этапе процесса установки вы увидите ссылку для загрузки нашего плагина Migrator и токен, который вы можете использовать для инициации миграции от вашего администратора WordPress. Подробные инструкции см. В руководстве WordPress Automatic Migrator .

Профессиональная миграция выполняется нашими специалистами

Если вы выберете профессиональный перенос, наша группа технической поддержки выполнит перенос веб-сайта за вас. Мы попросим вас предоставить данные для доступа, такие как URL вашей панели управления или FTP-хост, а также учетные данные для входа, чтобы мы могли получить доступ к вашему сайту и передать его.

Когда вы введете необходимую информацию и оплатите услугу, наша система отправит запрос инженерам службы поддержки, которые сделают все остальное.Обратите внимание, что перенос веб-сайтов может занять до 2-3 рабочих дней в зависимости от размера веб-сайта, ограничений, установленных старым хостом, возможностей подключения и других факторов.

Если вы не уверены, какой веб-сайт хотите создать, или еще не готовы к переносу существующих сайтов, вам все равно необходимо завершить работу мастера установки, нажав Пропустить и создать пустой сайт . Это создаст пустой сайт и панель управления для него, которую вы можете использовать для изучения всех функций и инструментов, которые мы предоставили в ваше распоряжение.

Посетите наши следующие руководства, чтобы узнать, как:

.

Как настроить несколько веб-сайтов с помощью веб-сервера Apache

В моем последнем посте я объяснил, как настроить веб-сервер Apache для одного веб-сайта. Это оказалось очень просто. В этом посте я покажу вам, как обслуживать несколько веб-сайтов с помощью одного экземпляра Apache.

Примечание. Я написал эту статью на виртуальной машине, использующей Fedora 27 с Apache 2.4.29. Если у вас другой дистрибутив или выпуск Fedora, команды, которые вы будете использовать, а также расположение и содержимое файлов конфигурации могут отличаться.

Как упоминалось в моей предыдущей статье, все файлы конфигурации для Apache находятся в / etc / httpd / conf и /etc/httpd/conf.d . Данные для веб-сайтов по умолчанию расположены в / var / www . При наличии нескольких веб-сайтов вам необходимо указать несколько местоположений, по одному для каждого сайта, который вы размещаете.

Виртуальный хостинг на основе имени

С виртуальным хостингом на основе имени вы можете использовать один IP-адрес для нескольких веб-сайтов. Современные веб-серверы, включая Apache, используют часть имени хоста указанного URL-адреса, чтобы определить, какой виртуальный веб-хост отвечает на запрос страницы.Для этого требуется немного больше настроек, чем для одного сайта.

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

Подготовка исходного сайта

Прежде чем настраивать второй веб-сайт, вам необходимо настроить виртуальный хостинг на основе имени, работающий для существующего сайта.Если у вас нет существующего веб-сайта, вернитесь и создайте его сейчас.

Когда у вас есть сайт, добавьте следующий раздел в конец его файла конфигурации /etc/httpd/conf/httpd.conf (добавление этого раздела - единственное изменение, которое вам нужно внести в файл httpd.conf ):

 


DocumentRoot / var / www / html
ServerName www.site1.org

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

Вам также необходимо настроить свои веб-сайты с записями в / etc / hosts , чтобы обеспечить разрешение имен. В прошлый раз мы просто использовали IP-адрес для localhost . Обычно это делается с использованием той службы имен, которую вы используете; например, Google или Godaddy.Для вашего тестового веб-сайта сделайте это, добавив новое имя в строку localhost в / etc / hosts . Добавьте записи для обоих веб-сайтов, чтобы вам больше не нужно было редактировать этот файл позже. Результат выглядит так:

 

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 www.site1.org www.site2.org

Давайте также изменим файл /var/www/html/index.html , чтобы он был более явным. Он должен выглядеть так (с дополнительным текстом, чтобы идентифицировать его как веб-сайт № 1):

 

Перезапустите сервер HTTPD, чтобы внести изменения в конфигурацию httpd .Затем вы можете просматривать веб-сайт с помощью браузера текстового режима Lynx из командной строки.

 [root @ testvm1 ~] # systemctl перезапуск httpd 
[root @ testvm1 ~] # lynx www.site1.org

Hello World
Веб-сайт 1.

Команды: используйте клавиши со стрелками для перемещения, '?' для помощи, «q», чтобы выйти, «<-», чтобы вернуться.
Клавиши со стрелками: вверх и вниз для перемещения. Право перехода по ссылке; Осталось вернуться.
H) elp O) ptions P) rint G) o M) на экране Q) uit / = поиск [удалить] = список истории

Вы можете видеть, что отображается измененное содержимое исходного веб-сайта и что явных ошибок нет.Нажмите клавишу «Q», а затем «Y», чтобы закрыть веб-браузер Lynx.

Настройка второго сайта

Теперь вы готовы создать второй веб-сайт. Создайте новую структуру каталогов веб-сайта с помощью следующей команды:

  [корень @ testvm1 html] # mkdir -p / var / www / html2  

Обратите внимание, что второй веб-сайт - это просто второй каталог html в том же каталоге / var / www , что и первый сайт.

Теперь создайте новый файл индекса, / var / www / html2 / index.html со следующим содержимым (этот индексный файл немного отличается, чтобы отличать его от исходного веб-сайта):

 Привет, мир - снова 

Веб-сайт 2.

Создайте новый раздел конфигурации в httpd.conf для второго веб-сайта и поместите его под предыдущим разделом виртуального хоста (оба должны выглядеть очень похоже). Эта строфа сообщает веб-серверу, где найти HTML-файлы для второго сайта.

 


DocumentRoot / var / www / html2
ServerName www.site2.org

Перезапустите HTTPD еще раз и используйте Lynx для просмотра результатов.

 [root @ testvm1 httpd] # systemctl перезапуск httpd 
[root @ testvm1 httpd] # lynx www.site2.org

Hello World - Again

Веб-сайт 2.


Команды: Используйте клавиши со стрелками для перемещения, '?' для помощи, «q», чтобы выйти, «<-», чтобы вернуться.
Клавиши со стрелками: вверх и вниз для перемещения. Право перехода по ссылке; Осталось вернуться.
H) elp O) ptions P) rint G) o M) на экране Q) uit / = поиск [удалить] = список истории

Здесь я сжал получившийся результат, чтобы уместить это пространство. Разница на странице говорит о том, что это второй сайт. Чтобы показать оба веб-сайта одновременно, откройте другой сеанс терминала и используйте веб-браузер Lynx для просмотра другого сайта.

Прочие соображения

Этот простой пример показывает, как обслуживать два веб-сайта с помощью одного экземпляра HTTPD-сервера Apache.Настройка виртуальных хостов становится немного сложнее, если учесть другие факторы.

Например, вы можете захотеть использовать некоторые сценарии CGI для одного или обоих этих веб-сайтов. Для этого вы должны создать каталоги для программ CGI в / var / www : / var / www / cgi-bin и / var / www / cgi-bin2 , чтобы соответствовать именованию каталогов HTML. . Затем вам нужно будет добавить директивы конфигурации в разделы виртуального хоста, чтобы указать расположение каталога для сценариев CGI.На каждом веб-сайте также могут быть каталоги, из которых можно загружать файлы; для этого также потребуются записи в соответствующей секции виртуального хоста.

На веб-сайте Apache описаны другие методы управления несколькими веб-сайтами, а также параметры конфигурации от настройки производительности до безопасности.

Apache - это мощный веб-сервер, который можно использовать для управления веб-сайтами от простых до очень сложных. Хотя его общая доля сокращается, Apache остается единственным наиболее часто используемым HTTPD-сервером в Интернете.

.

Как передать файл на мою виртуальную машину через ssh-соединение

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд
.

Интеграция приложения с виртуальной сетью Azure - Служба приложений Azure

  • 23 минуты на чтение

В этой статье

В этой статье описывается функция интеграции виртуальной сети службы приложений Azure и ее настройка с приложениями в службе приложений Azure. С помощью виртуальной сети Azure (VNets) вы можете разместить многие ресурсы Azure в сети, не маршрутизируемой через Интернет.Функция интеграции с виртуальной сетью позволяет вашим приложениям получать доступ к ресурсам в виртуальной сети или через нее. Интеграция с виртуальной сетью не позволяет получить частный доступ к вашим приложениям.

Служба приложений Azure имеет два варианта функции интеграции с виртуальной сетью:

  • Мультитенантные системы, поддерживающие полный спектр тарифных планов, кроме изолированных.
  • Среда службы приложений, которая развертывается в вашей виртуальной сети и поддерживает приложения с изолированным тарифным планом.

Функция интеграции виртуальной сети используется в многопользовательских приложениях.Если ваше приложение находится в среде службы приложений, значит, оно уже находится в виртуальной сети и не требует использования функции интеграции виртуальной сети для доступа к ресурсам в той же виртуальной сети. Дополнительные сведения обо всех сетевых функциях см. В разделе Сетевые функции службы приложений.

VNet Integration предоставляет вашему приложению доступ к ресурсам в вашей виртуальной сети, но не предоставляет входящий частный доступ к вашему приложению из виртуальной сети. Доступ к частному сайту означает обеспечение доступа к приложению только из частной сети, например из виртуальной сети Azure.Интеграция с виртуальной сетью используется только для исходящих вызовов из вашего приложения в виртуальную сеть. Функция интеграции виртуальной сети ведет себя по-разному, когда она используется с виртуальной сетью в том же регионе и с виртуальной сетью в других регионах. Функция интеграции с виртуальной сетью имеет два варианта:

  • Региональная интеграция виртуальной сети : при подключении к виртуальным сетям Azure Resource Manager в том же регионе у вас должна быть выделенная подсеть в виртуальной сети, с которой вы интегрируетесь.
  • Требуется шлюз для интеграции виртуальной сети : при подключении к виртуальной сети в других регионах или к классической виртуальной сети в том же регионе вам потребуется шлюз виртуальной сети Azure, подготовленный в целевой виртуальной сети.

Возможности интеграции с виртуальной сетью:

  • Требуется тарифный план Standard, Premium, PremiumV2 или Elastic Premium.
  • Поддержка TCP и UDP.
  • Работа с приложениями службы приложений Azure и приложениями-функциями.

Есть некоторые вещи, которые интеграция с виртуальной сетью не поддерживает, например:

  • Монтаж привода.
  • Интеграция с Active Directory.
  • NetBIOS.

Интеграция виртуальной сети, требующей шлюза, обеспечивает доступ к ресурсам только в целевой виртуальной сети или в сетях, подключенных к целевой виртуальной сети с помощью пиринга или виртуальных частных сетей.Интеграция виртуальной сети, требующей шлюза, не обеспечивает доступ к ресурсам, доступным через подключения Azure ExpressRoute, и не работает с конечными точками служб.

Независимо от используемой версии, интеграция виртуальной сети предоставляет вашему приложению доступ к ресурсам в виртуальной сети, но не предоставляет входящий частный доступ к вашему приложению из виртуальной сети. Доступ к частному сайту означает, что ваше приложение будет доступно только из частной сети, например из виртуальной сети Azure. Интеграция с виртуальной сетью предназначена только для исходящих вызовов из вашего приложения в виртуальную сеть.

Включить интеграцию с виртуальной сетью

  1. Перейдите к пользовательскому интерфейсу Networking на портале службы приложений. В VNet Integration выберите Щелкните здесь, чтобы настроить .

  2. Выберите Добавить виртуальную сеть .

  3. В раскрывающемся списке содержатся все виртуальные сети Azure Resource Manager в вашей подписке в том же регионе. Под ним находится список виртуальных сетей Resource Manager во всех других регионах.Выберите виртуальную сеть, с которой хотите интегрироваться.

    • Если виртуальная сеть находится в том же регионе, либо создайте новую подсеть, либо выберите пустую уже существующую подсеть.
    • Чтобы выбрать виртуальную сеть в другом регионе, необходимо подготовить шлюз виртуальной сети с включенной функцией «точка-сайт».
    • Для интеграции с классической виртуальной сетью вместо раскрывающегося списка Virtual Network выберите Щелкните здесь, чтобы подключиться к классической виртуальной сети . Выберите нужную классическую виртуальную сеть.В целевой виртуальной сети уже должен быть настроен шлюз виртуальной сети с включенной функцией «точка-сеть».

Во время интеграции ваше приложение перезапускается. Когда интеграция будет завершена, вы увидите подробную информацию о виртуальной сети, с которой вы интегрированы.

Интеграция региональной виртуальной сети

Использование региональной интеграции виртуальной сети позволяет вашему приложению получить доступ:

  • Ресурсы в виртуальной сети в том же регионе, что и ваше приложение.
  • ресурсов в виртуальных сетях, связанных с виртуальной сетью, с которой интегрировано ваше приложение.
  • Защищенные службы конечной точки службы.
  • ресурсов в подключениях Azure ExpressRoute.
  • ресурсов в виртуальной сети, с которой вы интегрированы.
  • ресурсов для одноранговых подключений, включая подключения Azure ExpressRoute.
  • Частные конечные точки

При использовании интеграции виртуальной сети с виртуальными сетями в том же регионе можно использовать следующие сетевые функции Azure:

  • Группы безопасности сети (NSG) : вы можете заблокировать исходящий трафик с помощью NSG, размещенной в вашей подсети интеграции.Правила для входящих подключений не применяются, потому что вы не можете использовать интеграцию виртуальной сети для предоставления входящего доступа к вашему приложению.
  • Таблицы маршрутов (UDR) : вы можете разместить таблицу маршрутов в подсети интеграции для отправки исходящего трафика в нужное место.

По умолчанию ваше приложение направляет только трафик RFC1918 в вашу виртуальную сеть. Если вы хотите направить весь исходящий трафик в виртуальную сеть, примените параметр приложения WEBSITE_VNET_ROUTE_ALL к своему приложению. Чтобы настроить параметр приложения:

  1. Перейдите к пользовательскому интерфейсу Configuration на портале приложения.Выберите Настройка нового приложения .

  2. Введите WEBSITE_VNET_ROUTE_ALL в поле Имя и введите 1 в поле Значение .

  3. Выбрать ОК .

  4. Выберите Сохранить .

Если вы маршрутизируете весь исходящий трафик в свою виртуальную сеть, он будет зависеть от групп безопасности сети и UDR, которые применяются к вашей подсети интеграции. Когда вы перенаправляете весь исходящий трафик в виртуальную сеть, ваши исходящие адреса по-прежнему остаются исходящими адресами, указанными в свойствах вашего приложения, если вы не укажете маршруты для отправки трафика в другое место.

Существуют некоторые ограничения при использовании интеграции виртуальной сети с виртуальными сетями в том же регионе:

  • Невозможно получить доступ к ресурсам через глобальные пиринговые соединения.
  • Эта функция доступна только в новых масштабируемых модулях службы приложений Azure, которые поддерживают планы службы приложений PremiumV2. Обратите внимание, что это не означает, что ваше приложение должно работать на уровне ценообразования PremiumV2 , только то, что оно должно работать в плане службы приложений, где доступна опция PremiumV2 (что подразумевает, что это более новая масштабируемая единица, в которой используется эта функция интеграции виртуальной сети. тогда тоже в наличии).
  • Подсеть интеграции может использоваться только одним планом службы приложений.
  • Эта функция не может использоваться приложениями изолированного плана, которые находятся в среде службы приложений.
  • Для этой функции требуется неиспользуемая подсеть / 27 с 32 адресами или больше в виртуальной сети Azure Resource Manager.
  • Приложение и виртуальная сеть должны находиться в одном регионе.
  • Невозможно удалить виртуальную сеть с помощью интегрированного приложения. Удалите интеграцию перед удалением виртуальной сети.
  • Вы можете интегрироваться с виртуальными сетями только в той же подписке, что и приложение.
  • У вас может быть только одна региональная интеграция виртуальной сети для каждого плана службы приложений. Несколько приложений в одном плане службы приложений могут использовать одну виртуальную сеть.
  • Вы не можете изменить подписку на приложение или план, пока есть приложение, использующее региональную интеграцию виртуальной сети.
  • Ваше приложение не может разрешать адреса в частных зонах Azure DNS без изменений конфигурации

Для каждого экземпляра плана используется один адрес. Если масштабировать приложение до пяти экземпляров, используется пять адресов.Поскольку размер подсети не может быть изменен после назначения, вы должны использовать подсеть, которая достаточно велика, чтобы вместить любой масштаб, которого может достичь ваше приложение. Рекомендуемый размер - A / 26 с 64 адресами. A / 26 с 64 адресами соответствует плану Premium с 30 экземплярами. Когда вы увеличиваете или уменьшаете масштаб плана, вам нужно вдвое больше адресов на короткий период времени.

Если вы хотите, чтобы ваши приложения из другого плана достигли виртуальной сети, к которой уже подключены приложения из другого плана, выберите подсеть, отличную от той, которая используется существующей интеграцией виртуальной сети.

Эта функция полностью поддерживается веб-приложениями как для Windows, так и для Linux. Все поведения одинаковы для приложений Windows и приложений Linux.

Конечные точки обслуживания

Региональная интеграция виртуальной сети позволяет использовать конечные точки служб. Чтобы использовать конечные точки службы с вашим приложением, используйте интеграцию региональной виртуальной сети для подключения к выбранной виртуальной сети, а затем настройте конечные точки службы с целевой службой в подсети, которую вы использовали для интеграции. Если вы затем хотели получить доступ к службе через конечные точки службы:

  1. Настройка интеграции региональной виртуальной сети с вашим веб-приложением
  2. перейти к целевой службе и настроить конечные точки службы в соответствии с подсетью, используемой для интеграции

Группы безопасности сети

Вы можете использовать группы безопасности сети для блокировки входящего и исходящего трафика к ресурсам в виртуальной сети.Приложение, использующее региональную интеграцию виртуальной сети, может использовать группу безопасности сети для блокировки исходящего трафика к ресурсам в вашей виртуальной сети или в Интернете. Чтобы заблокировать трафик на общедоступные адреса, вы должны установить для параметра приложения WEBSITE_VNET_ROUTE_ALL значение 1. Входящие правила в NSG не применяются к вашему приложению, поскольку интеграция виртуальной сети влияет только на исходящий трафик из вашего приложения.

Для управления входящим трафиком в ваше приложение используйте функцию ограничения доступа. Группа безопасности сети, применяемая к вашей подсети интеграции, действует независимо от любых маршрутов, примененных к вашей подсети интеграции.Если для WEBSITE_VNET_ROUTE_ALL установлено значение 1 и у вас нет маршрутов, влияющих на трафик общедоступных адресов в вашей подсети интеграции, весь ваш исходящий трафик по-прежнему подчиняется группам безопасности сети, назначенным вашей подсети интеграции. Если WEBSITE_VNET_ROUTE_ALL не установлен, группы безопасности сети применяются только к трафику RFC1918.

Маршруты

Вы можете использовать таблицы маршрутизации для маршрутизации исходящего трафика из вашего приложения в любое место. По умолчанию таблицы маршрутов влияют только на трафик назначения RFC1918. Если вы установите WEBSITE_VNET_ROUTE_ALL в 1, это затронет все ваши исходящие вызовы.Маршруты, установленные в вашей подсети интеграции, не повлияют на ответы на входящие запросы приложений. Общие пункты назначения могут включать устройства межсетевого экрана или шлюзы.

Если вы хотите перенаправить весь исходящий трафик локально, вы можете использовать таблицу маршрутизации для отправки всего исходящего трафика на шлюз ExpressRoute. Если вы маршрутизируете трафик на шлюз, обязательно установите маршруты во внешней сети для отправки любых ответов.

Маршруты протокола пограничного шлюза

(BGP) также влияют на трафик вашего приложения. Если у вас есть маршруты BGP от чего-то вроде шлюза ExpressRoute, это повлияет на исходящий трафик вашего приложения.По умолчанию маршруты BGP влияют только на трафик назначения RFC1918. Если для WEBSITE_VNET_ROUTE_ALL установлено значение 1, на весь исходящий трафик могут влиять ваши маршруты BGP.

Частные зоны Azure DNS

После того, как ваше приложение интегрируется с виртуальной сетью, оно будет использовать тот же DNS-сервер, с которым настроена ваша виртуальная сеть. По умолчанию ваше приложение не будет работать с частными зонами Azure DNS. Для работы с частными зонами Azure DNS вам необходимо добавить следующие настройки приложения:

  1. WEBSITE_DNS_SERVER со значением 168.63.129.16
  2. WEBSITE_VNET_ROUTE_ALL со значением 1

Эти параметры будут отправлять все исходящие вызовы из вашего приложения в виртуальную сеть в дополнение к разрешению вашему приложению использовать частные зоны Azure DNS.

Частные конечные точки

Если вы хотите совершать вызовы к частным конечным точкам, вам необходимо либо интегрироваться с частными зонами Azure DNS, либо управлять частной конечной точкой на DNS-сервере, используемом вашим приложением.

Как работает интеграция региональной виртуальной сети

Приложения в службе приложений размещаются в рабочих ролях.Базовые и более высокие тарифные планы - это планы выделенного хостинга, в которых рабочие нагрузки других клиентов не выполняются на одних и тех же сотрудниках. Региональная интеграция виртуальной сети работает путем подключения виртуальных интерфейсов с адресами в делегированной подсети. Поскольку адрес отправителя находится в вашей виртуальной сети, он может получить доступ к большинству вещей в виртуальной сети или через нее, как это делает виртуальная машина в вашей виртуальной сети. Реализация сети отличается от запуска виртуальной машины в вашей виртуальной сети. Вот почему некоторые сетевые функции для этой функции пока недоступны.

Когда включена региональная интеграция виртуальной сети, ваше приложение выполняет исходящие вызовы в Интернет по тем же каналам, что и обычно. Исходящие адреса, перечисленные на портале свойств приложения, по-прежнему используются вашим приложением. Какие изменения для вашего приложения - это вызовы служб, защищенных конечными точками службы, или адреса RFC 1918, поступающие в вашу виртуальную сеть. Если для WEBSITE_VNET_ROUTE_ALL установлено значение 1, весь исходящий трафик может быть отправлен в вашу виртуальную сеть.

Функция поддерживает только один виртуальный интерфейс на одного рабочего.Один виртуальный интерфейс на каждого рабочего означает одну региональную интеграцию виртуальной сети для каждого плана службы приложений. Все приложения в одном плане службы приложений могут использовать одну и ту же интеграцию с виртуальной сетью. Если вам нужно приложение для подключения к дополнительной виртуальной сети, вам необходимо создать другой план службы приложений. Используемый виртуальный интерфейс не является ресурсом, к которому клиенты имеют прямой доступ.

Из-за характера работы этой технологии трафик, используемый с интеграцией виртуальной сети, не отображается в журналах мониторинга сети Azure или в журналах потоков NSG.

Интеграция виртуальной сети, требующей шлюза

Интеграция виртуальной сети, требующей шлюза, поддерживает подключение к виртуальной сети в другом регионе или к классической виртуальной сети. Интеграция виртуальной сети, требующей шлюза:

  • Позволяет приложению подключаться только к одной виртуальной сети за раз.
  • Позволяет интегрировать до пяти виртуальных сетей в план службы приложений.
  • Позволяет использовать одну и ту же виртуальную сеть для нескольких приложений в плане службы приложений, не влияя на общее количество, которое может использоваться планом службы приложений.Если у вас есть шесть приложений, использующих одну и ту же виртуальную сеть в одном плане службы приложений, это считается использованием одной виртуальной сети.
  • Поддерживает 99,9% SLA из-за SLA на шлюзе.
  • Позволяет вашим приложениям использовать DNS, с которым настроена виртуальная сеть.
  • Требуется шлюз на основе маршрутов виртуальной сети, настроенный с помощью SSTP-точка-сеть VPN, прежде чем он может быть подключен к приложению.

Невозможно использовать интеграцию виртуальной сети, требующей шлюза:

  • С виртуальной сетью, подключенной к Azure ExpressRoute.
  • Из приложения Linux
  • Для доступа к защищенным ресурсам конечной точки службы.
  • Со шлюзом сосуществования, который поддерживает как ExpressRoute, так и VPN типа "точка-сеть" или "сеть-сеть".

Настройка шлюза в виртуальной сети Azure

Для создания шлюза:

  1. Создайте подсеть шлюза в своей виртуальной сети.

  2. Создайте шлюз VPN. Выберите тип VPN на основе маршрута.

  3. Задайте адреса «точка-сеть».Если шлюз не входит в базовый SKU, то IKEV2 должен быть отключен в конфигурации точка-сеть и должен быть выбран SSTP. Адресное пространство «точка-сеть» должно находиться в адресных блоках RFC 1918 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.

Если вы создаете шлюз для использования с интеграцией виртуальной сети службы приложений, вам не нужно загружать сертификат. Создание шлюза может занять 30 минут. Вы не сможете интегрировать свое приложение в виртуальную сеть, пока не будет подготовлен шлюз.

Как работает интеграция виртуальной сети, требующей шлюза

Интеграция виртуальной сети, требующей шлюза, построена на основе технологии VPN типа «точка-сеть». VPN-соединения типа «точка-сеть» ограничивают сетевой доступ к виртуальной машине, на которой размещено приложение. Приложения могут отправлять трафик в Интернет только через гибридные подключения или через интеграцию с виртуальной сетью. Когда ваше приложение настроено с порталом для использования интеграции с виртуальной сетью, требующей шлюза, от вашего имени выполняется сложное согласование для создания и назначения сертификатов на шлюзе и на стороне приложения.В результате рабочие, используемые для размещения ваших приложений, могут напрямую подключаться к шлюзу виртуальной сети в выбранной виртуальной сети.

Доступ к локальным ресурсам

Приложения могут получать доступ к локальным ресурсам за счет интеграции с виртуальными сетями, имеющими соединения типа "сеть-сеть". Если вы используете интеграцию виртуальной сети, требующую шлюза, обновите маршруты локального шлюза VPN с помощью блоков адресов точка-сайт. При первой настройке VPN типа "сеть-сеть" сценарии, используемые для ее настройки, должны правильно настраивать маршруты.Если вы добавляете адреса «точка-сеть» после создания VPN-соединения «сеть-сеть», вам необходимо обновить маршруты вручную. Подробные сведения о том, как это сделать, зависят от шлюза и здесь не описаны. Вы не можете настроить BGP с VPN-подключением типа "сеть-сеть".

Для возможности интеграции региональной виртуальной сети через виртуальную сеть с локальными ресурсами дополнительная настройка не требуется. Вам просто нужно подключить виртуальную сеть к локальным ресурсам с помощью ExpressRoute или VPN типа «сеть-сеть».

Примечание

Функция интеграции виртуальной сети, требующей шлюза, не интегрирует приложение с виртуальной сетью, имеющей шлюз ExpressRoute. Даже если шлюз ExpressRoute настроен в режиме сосуществования, интеграция виртуальной сети не работает. Если вам нужно получить доступ к ресурсам через соединение ExpressRoute, используйте функцию интеграции региональной виртуальной сети или среду службы приложений, которая работает в вашей виртуальной сети.

Пиринг

Если вы используете пиринг с региональной интеграцией виртуальной сети, вам не нужно выполнять дополнительную настройку.

Если вы используете интеграцию виртуальной сети, требующей шлюза, с пирингом, вам необходимо настроить несколько дополнительных элементов. Чтобы настроить пиринг для работы с вашим приложением:

  1. Добавьте пиринговое соединение в виртуальную сеть, к которой подключается ваше приложение. При добавлении пирингового соединения включите Разрешить доступ к виртуальной сети и выберите Разрешить перенаправленный трафик и Разрешить транзит шлюза .
  2. Добавьте пиринговое соединение в виртуальной сети, которое будет подключено к виртуальной сети, к которой вы подключены.Когда вы добавляете пиринговое соединение в целевую виртуальную сеть, включите Разрешить доступ к виртуальной сети и выберите Разрешить перенаправленный трафик и Разрешить удаленные шлюзы .
  3. Перейдите к плану службы приложений > Networking > VNet Integration UI на портале. Выберите виртуальную сеть, к которой подключается ваше приложение. В разделе маршрутизации добавьте диапазон адресов виртуальной сети, которая связана с виртуальной сетью, к которой подключено ваше приложение.

Управление интеграцией виртуальной сети

Подключение и отключение от виртуальной сети осуществляется на уровне приложения.Операции, которые могут повлиять на интеграцию виртуальной сети между несколькими приложениями, находятся на уровне плана службы приложений. В приложении> Networking > VNet Integration вы можете получить подробную информацию о своей виртуальной сети. Вы можете увидеть аналогичную информацию на уровне плана службы приложений в плане службы приложений > Сеть > Портал интеграции с виртуальной сетью .

Единственная операция, которую вы можете выполнить в представлении приложения вашего экземпляра интеграции виртуальной сети, - это отключить приложение от виртуальной сети, к которой оно в настоящее время подключено.Чтобы отключить приложение от виртуальной сети, выберите Отключить . Ваше приложение перезапускается при отключении от виртуальной сети. Отключение не меняет вашу виртуальную сеть. Подсеть или шлюз не удаляются. Если затем вы захотите удалить свою виртуальную сеть, сначала отключите приложение от виртуальной сети и удалите в ней ресурсы, например шлюзы.

Пользовательский интерфейс интеграции виртуальной сети плана службы приложений показывает все интеграции виртуальной сети, используемые приложениями в вашем плане службы приложений. Чтобы просмотреть подробную информацию о каждой виртуальной сети, выберите интересующую вас виртуальную сеть.Здесь можно выполнить два действия для интеграции виртуальной сети, требующей шлюза:

  • Сеть синхронизации : операция синхронизации сети используется только для функции интеграции виртуальной сети, зависящей от шлюза. Выполнение сетевой операции синхронизации гарантирует, что ваши сертификаты и сетевая информация синхронизированы. Если вы добавляете или изменяете DNS своей виртуальной сети, выполните операцию синхронизации сети. Эта операция перезапускает все приложения, использующие эту виртуальную сеть. Эта операция не будет работать, если вы используете приложение и виртуальную сеть, принадлежащие разным подпискам.
  • Добавить маршруты : Добавление маршрутов направляет исходящий трафик в вашу виртуальную сеть.

Маршрутизация интеграции виртуальной сети, требующая шлюза

Маршруты, определенные в вашей виртуальной сети, используются для направления трафика в виртуальную сеть из вашего приложения. Чтобы отправить дополнительный исходящий трафик в виртуальную сеть, добавьте сюда эти блоки адресов. Эта возможность работает только с интеграцией виртуальной сети, требующей шлюза. Таблицы маршрутов не влияют на трафик вашего приложения, когда вы используете интеграцию виртуальной сети, требующей шлюза, так же, как они это делают с региональной интеграцией виртуальной сети.

Сертификаты интеграции виртуальной сети, необходимые для шлюза

Когда включена интеграция виртуальной сети, требующей шлюза, требуется обмен сертификатами для обеспечения безопасности соединения. Наряду с сертификатами есть конфигурация DNS, маршруты и другие подобные вещи, описывающие сеть.

Если сертификаты или сетевая информация изменены, выберите Sync Network . Когда вы выбираете Sync Network , вы вызываете кратковременное отключение связи между вашим приложением и виртуальной сетью.Пока ваше приложение не перезапускается, потеря подключения может привести к неправильной работе вашего сайта.

Информация о ценах

За использование функции интеграции региональных виртуальных сетей не взимается дополнительная плата, помимо платы за использование тарифного плана службы приложений.

Три платы связаны с использованием функции интеграции виртуальной сети, необходимой для шлюза:

  • Плата за тарифный план службы приложений : Ваши приложения должны быть в плане службы приложений Standard, Premium или PremiumV2.Дополнительные сведения об этих расходах см. В разделе цены на службу приложений.
  • Стоимость передачи данных : За исходящие данные взимается плата, даже если виртуальная сеть находится в том же центре обработки данных. Эти расходы описаны в подробностях о расценках на передачу данных.
  • Шлюз VPN стоит : Шлюз виртуальной сети требует затрат для VPN типа «точка-сеть». Для получения дополнительной информации см. Цены на VPN-шлюз.

Устранение неисправностей

Эту функцию легко настроить, но это не значит, что у вас не будет проблем.Если у вас возникнут проблемы с доступом к желаемой конечной точке, есть несколько утилит, которые вы можете использовать для проверки подключения из консоли приложения. Вы можете использовать две консоли. Одна - это консоль Kudu, а другая - консоль на портале Azure. Чтобы получить доступ к консоли Kudu из вашего приложения, перейдите в Tools > Kudu . Вы также можете получить доступ к консоли Kudo по адресу [sitename] .scm.azurewebsites.net. После загрузки веб-сайта перейдите на вкладку Debug console . Чтобы перейти к консоли, размещенной на портале Azure, из вашего приложения, перейдите к Tools > Console .

Инструменты

Инструменты ping , nslookup и tracert не работают через консоль из-за ограничений безопасности. Чтобы заполнить пустоту, добавляются два отдельных инструмента. Чтобы проверить работу DNS, мы добавили инструмент под названием nameresolver.exe . Синтаксис:

  nameresolver.exe имя хоста [необязательно: DNS-сервер]  

Вы можете использовать nameresolver, чтобы проверить имена хостов, от которых зависит ваше приложение. Таким образом вы можете проверить, есть ли у вас что-то неправильно настроенное с вашим DNS или, возможно, у вас нет доступа к вашему DNS-серверу.Вы можете увидеть DNS-сервер, который использует ваше приложение, в консоли, посмотрев на переменные среды WEBSITE_DNS_SERVER и WEBSITE_DNS_ALT_SERVER.

Вы можете использовать следующий инструмент для проверки TCP-соединения с комбинацией хоста и порта. Этот инструмент называется tcpping и имеет синтаксис:

  tcpping.exe имя хоста [необязательно: порт]  

Утилита tcpping сообщает вам, можете ли вы достичь определенного хоста и порта. Он может показать успех только в том случае, если есть приложение, которое прослушивает комбинацию хоста и порта, и есть сетевой доступ из вашего приложения к указанному хосту и порту.

Отладочный доступ к ресурсам, размещенным в виртуальной сети

Ряд вещей может помешать вашему приложению достичь определенного хоста и порта. В большинстве случаев это одна из следующих вещей:

  • Брандмауэр мешает. Если вам мешает брандмауэр, вы достигнете таймаута TCP. В этом случае таймаут TCP составляет 21 секунду. Используйте инструмент tcpping для проверки возможности подключения. Таймауты TCP могут быть вызваны многими вещами, помимо брандмауэров, но начните с них.
  • DNS недоступен. Тайм-аут DNS составляет 3 секунды для каждого DNS-сервера. Если у вас два DNS-сервера, тайм-аут составляет 6 секунд. Используйте nameresolver, чтобы узнать, работает ли DNS. Вы не можете использовать nslookup, потому что он не использует DNS, с которым настроена ваша виртуальная сеть. Если он недоступен, возможно, у вас есть брандмауэр или NSG, блокирующие доступ к DNS, или он может быть отключен.

Если эти элементы не решают ваших проблем, сначала обратите внимание на такие вещи, как:

Интеграция региональной виртуальной сети

  • Ваш пункт назначения не является адресом RFC1918, и у вас нет WEBSITE_VNET_ROUTE_ALL, установленного на 1?
  • Есть ли блокировка выхода из подсети интеграции группой безопасности сети?
  • Если вы используете Azure ExpressRoute или VPN, настроен ли ваш локальный шлюз для маршрутизации трафика обратно в Azure? Если вы можете достичь конечных точек в своей виртуальной сети, но не в локальной, проверьте свои маршруты.
  • У вас достаточно разрешений для настройки делегирования в подсети интеграции? Во время региональной настройки интеграции виртуальной сети ваша подсеть интеграции делегируется Microsoft.Web. Пользовательский интерфейс интеграции с виртуальной сетью автоматически делегирует подсеть Microsoft.Web. Если ваша учетная запись не имеет достаточных сетевых разрешений для настройки делегирования, вам понадобится кто-то, кто может устанавливать атрибуты в вашей подсети интеграции, чтобы делегировать подсеть. Чтобы вручную делегировать подсеть интеграции, перейдите в пользовательский интерфейс подсети виртуальной сети Azure и установите делегирование для Microsoft.Интернет.

Требуется шлюз для интеграции виртуальной сети

  • Находится ли диапазон адресов точка-сеть в диапазонах RFC 1918 (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • Шлюз отображается на портале как работающий? Если ваш шлюз не работает, восстановите его.
  • Отображаются ли сертификаты как синхронизированные, или вы подозреваете, что конфигурация сети была изменена? Если ваши сертификаты не синхронизированы или вы подозреваете, что в конфигурацию вашей виртуальной сети было внесено изменение, которое не было синхронизировано с вашими ASP, выберите Sync Network .
  • Если вы используете VPN, настроен ли локальный шлюз для маршрутизации трафика обратно в Azure? Если вы можете достичь конечных точек в своей виртуальной сети, но не в локальной, проверьте свои маршруты.
  • Вы пытаетесь использовать шлюз сосуществования, который поддерживает как точка-сайт, так и ExpressRoute? Шлюзы сосуществования не поддерживаются при интеграции с виртуальными сетями.

Отладка сетевых проблем является сложной задачей, потому что вы не можете увидеть, что блокирует доступ к определенной комбинации хост: порт.Некоторые причины включают:

  • На вашем хосте установлен брандмауэр, который предотвращает доступ к порту приложения из диапазона IP-адресов точка-сеть. Для пересечения подсетей часто требуется общий доступ.
  • Ваш целевой хост не работает.
  • Ваше приложение не работает.
  • У вас неправильный IP-адрес или имя хоста.
  • Ваше приложение прослушивает порт, отличный от ожидаемого. Вы можете сопоставить свой идентификатор процесса с портом прослушивания, используя команду netstat -aon на хосте конечной точки.
  • Группы сетевой безопасности настроены таким образом, что они предотвращают доступ к хосту приложения и порту из диапазона IP-адресов точка-сеть.

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

Дополнительные шаги отладки включают:

  • Подключитесь к виртуальной машине в вашей виртуальной сети и попытайтесь связаться с вашим ресурсным хостом: портом оттуда.Чтобы проверить доступ TCP, используйте команду PowerShell test-netconnection . Синтаксис:
  имя хоста test-netconnection [необязательно: -Port]  
  • Вызовите приложение на виртуальной машине и протестируйте доступ к этому хосту и порту из консоли из вашего приложения, используя tcpping .
Локальные ресурсы

Если ваше приложение не может получить доступ к локальному ресурсу, проверьте, можете ли вы получить доступ к ресурсу из своей виртуальной сети.Используйте команду test-netconnection PowerShell, чтобы проверить доступ TCP. Если ваша виртуальная машина не может получить доступ к локальному ресурсу, возможно, ваше соединение VPN или ExpressRoute настроено неправильно.

Если ваша виртуальная машина, размещенная в виртуальной сети, может подключиться к вашей локальной системе, а ваше приложение не может, причиной, вероятно, является одна из следующих причин:

  • Ваши маршруты не настроены с учетом диапазонов адресов вашей подсети или точка-сеть в локальном шлюзе.
  • Группы безопасности вашей сети блокируют доступ для диапазона IP-адресов точка-сеть.
  • Ваши локальные брандмауэры блокируют трафик из диапазона IP-адресов между точками.
  • Вы пытаетесь получить доступ к адресу, не указанному в RFC 1918, с помощью функции региональной интеграции виртуальной сети.

Автоматика

Поддержка интерфейса командной строки

доступна для региональной интеграции виртуальных сетей. Чтобы получить доступ к следующим командам, установите Azure CLI.

  az webapp vnet-интеграция --help Группа az webapp vnet-integration: методы, которые перечисляют, добавляют и удаляют виртуальную сеть интеграции из веб-приложения.Эта группа команд находится в предварительном просмотре. Он может быть изменен / удален в будущем выпуске. Команды: add: добавить интеграцию региональной виртуальной сети в веб-приложение. list: список интеграций виртуальной сети в веб-приложении. remove: удалить интеграцию региональной виртуальной сети из webapp. az appservice vnet-integration --help Группа az appservice vnet-integration: метод, отображающий виртуальную сеть интеграции, используемые в плане обслуживания приложений. Эта группа команд находится в предварительном просмотре.Он может быть изменен / удален в будущем выпуске. Команды: list: перечислить интеграции виртуальной сети, используемые в плане обслуживания приложений.  

Поддержка Powershell для региональной интеграции виртуальной сети также доступна, но вы должны создать общий ресурс с массивом свойств идентификатора ресурса подсети

  # Параметры $ sitename = "myWebApp" $ resourcegroupname = "myRG" $ VNetname = "myVNet" $ location = "myRegion" $ integrationubnetname = "myIntegrationSubnet" $ subscriptionID = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" #Property массив с SubnetID $ properties = @ { "subnetResourceId" = "/ subscriptions /" + $ subscriptionID + "/ resourceGroups /" + $ resourcegroupname + "/ provider / Microsoft.Сеть / виртуальные сети / "+ $ VNetname +" / subnets / "+ $ integrationsubnetname; } # Создание интеграции VNet $ resourceID = $ sitename + "/ VirtualNetwork" Новый-AzResource -ResourceName $ resourceID ` -Location $ location ` -ResourceGroupName $ resourcegroupname ` -ResourceType Microsoft.Web / sites / networkConfig ` -PropertyObject $ свойства  

Для интеграции виртуальной сети, требующей шлюза, вы можете интегрировать службу приложений с виртуальной сетью Azure с помощью PowerShell. Готовый к запуску сценарий см. В разделе Подключение приложения в службе приложений Azure к виртуальной сети Azure.

.

Смотрите также

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Одноклассники
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий