WEBVTT

00:00:00.000 --> 00:00:11.610
(Музыка).

00:00:11.610 --> 00:00:13.680
Привет, все, мое имя
Колин Мерфи.

00:00:13.680 --> 00:00:16.065
Я продукт маркетинга
Менеджер в корпорации Майкрософт,

00:00:16.065 --> 00:00:17.865
и я здесь с Рохитом, чтобы

00:00:17.865 --> 00:00:20.730
обсудить подключение
для базы данных Azure S'L.

00:00:20.730 --> 00:00:24.200
Так что добро пожаловать, Рохит. Так бы
Вы возражаете просто говорю нам

00:00:24.200 --> 00:00:28.700
только основные понятия о том, как вы
подключиться к базе данных Azure S'L?

00:00:28.700 --> 00:00:31.250
Абсолютно. Привет
всех, меня зовут Рохит.

00:00:31.250 --> 00:00:34.300
Я менеджер программы в
группа базы данных S'L.

00:00:34.300 --> 00:00:37.790
Сегодня с Колином, мы
собирается начать и принять вас

00:00:37.790 --> 00:00:41.120
через то, как вы подключаетесь
в базу данных Azure S'L.

00:00:41.120 --> 00:00:43.375
Так что с этим, давайте начнем.

00:00:43.375 --> 00:00:45.525
Итак, первый вопрос.

00:00:45.525 --> 00:00:48.905
Давайте разберемся немного
о нашей архитектуре, прежде чем мы

00:00:48.905 --> 00:00:52.370
перейти к вшивый-грязный о том, как
вы устанавливаете связь.

00:00:52.370 --> 00:00:55.265
Так как клиент, что
Вы должны знать, является

00:00:55.265 --> 00:00:58.080
что у нас есть куча
Шлюзы СЗЛ, которые

00:00:58.080 --> 00:00:59.895
наши передние машины, которые приняты

00:00:59.895 --> 00:01:02.060
входящих соединений более
Интернет, когда вы

00:01:02.060 --> 00:01:06.825
подключение из находины
или за пределами Azure.

00:01:06.825 --> 00:01:08.710
Это всего лишь часть
того прошлого служения.

00:01:08.710 --> 00:01:10.470
Вы можете просто увидеть, если это безрассудно.

00:01:10.470 --> 00:01:13.510
Да, да. Тогда у нас есть куча
бэк-энд машины, где

00:01:13.510 --> 00:01:20.195
фактические базы данных S'L
хостов и ваши данные живет там.

00:01:20.195 --> 00:01:21.610
Хорошо, хорошо.

00:01:21.710 --> 00:01:27.450
Я пытаюсь подключиться к
myserver.database.windows.net,

00:01:27.450 --> 00:01:31.435
это обычный формат
для всех серверов баз данных.

00:01:31.435 --> 00:01:34.045
Как правило, если вы
NsLookup по этому вопросу,

00:01:34.045 --> 00:01:36.370
он решится
этот публичный IP-адрес.

00:01:36.370 --> 00:01:38.680
104.42 ИП

00:01:38.680 --> 00:01:40.870
публичный IP-адрес, и вы

00:01:40.870 --> 00:01:43.615
будет подключение
к тому на порте 1433,

00:01:43.615 --> 00:01:46.055
который является, где мы находимся
прослушивание соединений на.

00:01:46.055 --> 00:01:48.885
При подключении один из

00:01:48.885 --> 00:01:52.380
общие вещи, которые
происходит, мы в основном,

00:01:52.380 --> 00:01:55.395
Шлюз s'L перенаправляет
ваше соединение на,

00:01:55.395 --> 00:01:57.770
так что у вас есть липкий
подключение, проходящие через

00:01:57.770 --> 00:02:00.545
шлюз и подключение
к задней части узла.

00:02:00.545 --> 00:02:03.425
Это называется прокси
политики подключения.

00:02:03.425 --> 00:02:05.570
Так что все шлюз делает это

00:02:05.570 --> 00:02:09.110
руководство в середине передачи на
подключение к бэк-энду.

00:02:09.110 --> 00:02:10.670
Это хорошо, потому что
мы никогда не подвергая

00:02:10.670 --> 00:02:13.130
фактический IP узла S'L.

00:02:13.130 --> 00:02:15.140
Я понял. Так вот как вы

00:02:15.140 --> 00:02:17.330
подключиться при подключении
из-за пределов Лазурного.

00:02:17.330 --> 00:02:20.090
Теперь, при подключении
изнутри Лазурного,

00:02:20.090 --> 00:02:23.915
сказать от ВМ, мы делаем немного
другой способ подключения.

00:02:23.915 --> 00:02:27.170
Таким образом, мы подключаемся к
Шлюз S'L и мы получаем

00:02:27.170 --> 00:02:32.540
фактическое местоположение вашего
База данных S'L в бэк-энде.

00:02:32.540 --> 00:02:35.810
Таким образом, вы увидите этот адрес 13.93.

00:02:35.810 --> 00:02:37.535
Это частный IP-адрес.

00:02:37.535 --> 00:02:40.930
Это не то, что пользователи
может подключиться к непосредственно,

00:02:40.930 --> 00:02:42.815
как, они не знают,
об этом IP-адресе.

00:02:42.815 --> 00:02:43.325
Хорошо, хорошо.

00:02:43.325 --> 00:02:46.385
Затем, чтобы еще больше рандомизировать его,

00:02:46.385 --> 00:02:52.250
есть 11000-11 999 диапазон порта.

00:02:52.250 --> 00:02:53.575
Хорошо, хорошо.

00:02:53.575 --> 00:02:58.885
Так что S'L может слушать на
любой из тех, в пределах этого диапазона.

00:02:58.885 --> 00:03:02.010
Вот где то, что
происходит это называется

00:03:02.010 --> 00:03:06.560
метод перенаправления или перенаправления
является политикой подключения,

00:03:06.560 --> 00:03:08.615
но мы перенаправляем вас в этот узла.

00:03:08.615 --> 00:03:11.345
Таким образом, вы подключаетесь напрямую
в базу данных S'L,

00:03:11.345 --> 00:03:13.400
и шлюз не вступают в

00:03:13.400 --> 00:03:17.040
Картина когда-либо снова
этой связи.

00:03:17.090 --> 00:03:18.525
Хорошо, хорошо.

00:03:18.525 --> 00:03:20.900
Так что это основная архитектура

00:03:20.900 --> 00:03:23.210
и вы понимаете, как подключиться.

00:03:23.210 --> 00:03:24.920
Теперь, позвольте мне взять вас
через то, что происходит

00:03:24.920 --> 00:03:27.410
когда ваше соединение на самом деле
делает его к шлюзу.

00:03:27.410 --> 00:03:28.345
Хорошо, хорошо.

00:03:28.345 --> 00:03:32.235
Это очень, очень просто
на высоком уровне вещи, ничего особенного,

00:03:32.235 --> 00:03:36.520
и это было вокруг в течение веков.

00:03:36.520 --> 00:03:40.375
Таким образом, у вас есть клиент, и вы
есть шлюз машины,

00:03:40.375 --> 00:03:43.350
Первое, что
трехстороннее рукопожатие,

00:03:43.350 --> 00:03:47.835
стандартный PCP вещи, «неразборчиво»
общение с сервером.

00:03:47.835 --> 00:03:50.720
Интересная вещь, что
происходит дальше у вас есть

00:03:50.720 --> 00:03:53.090
прелогин пакет
что клиент посылает,

00:03:53.090 --> 00:03:55.840
и интересные особенности здесь,

00:03:55.840 --> 00:03:57.900
мы хотим, чтобы вы,

00:03:57.900 --> 00:04:00.820
в качестве наилучшей практики, используйте шифрование,

00:04:00.820 --> 00:04:03.425
который устанавливается, поставив

00:04:03.425 --> 00:04:07.490
шифрование равно верно в связи
строка вашего приложения.

00:04:07.490 --> 00:04:10.640
Другая часть, мы хотим, чтобы вы
делать как лучшая практика

00:04:10.640 --> 00:04:13.415
является TrustServerCertificate
равно ложным.

00:04:13.415 --> 00:04:16.940
Таким образом, это заставляет клиента проверить

00:04:16.940 --> 00:04:21.890
сертификат, который вы
получить от шлюза узла.

00:04:21.890 --> 00:04:23.580
Таким образом, вы не будете иметь

00:04:23.580 --> 00:04:28.215
любой шанс подделать или
человек в середине атак.

00:04:28.215 --> 00:04:30.105
Хорошо, это имеет смысл.

00:04:30.105 --> 00:04:32.670
Так что это лучшие практики и

00:04:32.670 --> 00:04:34.860
любой разработчик подключения
СЗЛ найдет

00:04:34.860 --> 00:04:37.285
это на наших страницах документы
или где бы там ни было?

00:04:37.285 --> 00:04:40.080
Да, да. На самом деле, мы
сделать еще один шаг вперед.

00:04:40.080 --> 00:04:42.300
Если вы зайдь в портал и посмотреть на

00:04:42.300 --> 00:04:44.960
ваша база данных и внешний вид
на строке соединения,

00:04:44.960 --> 00:04:46.550
они помещаются туда.

00:04:46.550 --> 00:04:47.735
Все это по умолчанию?

00:04:47.735 --> 00:04:49.340
Да, да. Таким образом, вы положили их в

00:04:49.340 --> 00:04:51.320
там, чтобы убедиться, что
вы защищены.

00:04:51.320 --> 00:04:52.075
Хорошо, хорошо.

00:04:52.075 --> 00:04:53.940
Затем с этого момента,

00:04:53.940 --> 00:04:55.110
предлогия и ответные меры,

00:04:55.110 --> 00:04:57.600
, что снова является частью
протокола TDS,

00:04:57.600 --> 00:05:00.410
и тогда у вас есть
это рукопожатие TLS, которое

00:05:00.410 --> 00:05:02.690
длинный наматывается способ получения

00:05:02.690 --> 00:05:04.820
безопасный канал между
клиента и сервера.

00:05:04.820 --> 00:05:05.320
Хорошо, хорошо.

00:05:05.320 --> 00:05:07.220
Так что по существу, в
конец этого процесса,

00:05:07.220 --> 00:05:09.680
Вы защищены от
протокола,

00:05:09.680 --> 00:05:14.500
а затем начинается
фактический пакет входа, который

00:05:14.500 --> 00:05:16.020
Вы увидите его как

00:05:16.020 --> 00:05:18.200
Войти продажи пакета, если

00:05:18.200 --> 00:05:20.270
Вы сделали бы через удар
или что-то в этом роде.

00:05:20.270 --> 00:05:23.330
Затем, основываясь на том, что вы используете,

00:05:23.330 --> 00:05:26.720
если вы подключаетесь к
нас от проксимальной,

00:05:26.720 --> 00:05:29.215
Вы просто получите
подтверждение назад.

00:05:29.215 --> 00:05:31.985
В противном случае, вы получите то, что
называется токеном перенаправления,

00:05:31.985 --> 00:05:33.485
что является причудливым способом сказать,

00:05:33.485 --> 00:05:35.000
мы расскажем вам частный IP

00:05:35.000 --> 00:05:36.895
адрес, который вы
собирается подключиться к.

00:05:36.895 --> 00:05:39.290
Вау, есть много рукопожатия
идя назад (неразборчиво).

00:05:39.290 --> 00:05:39.980
Да, да.

00:05:39.980 --> 00:05:41.690
Вопрос: Это долгий процесс или?

00:05:41.690 --> 00:05:44.075
Нет, это вопрос миллисекунд.

00:05:44.075 --> 00:05:45.170
О, хорошо.

00:05:45.170 --> 00:05:48.530
Да, мы держим его быстро
даже и мы держим его в безопасности.

00:05:48.530 --> 00:05:50.870
Хорошо, это хорошо.
Быстро и безопасно.

00:05:50.870 --> 00:05:52.720
Да, да. Так что дальше,

00:05:52.720 --> 00:05:55.100
Теперь, когда мы знаем о
архитектуры, и мы знаем,

00:05:55.100 --> 00:05:58.460
об основах подключения,

00:05:58.460 --> 00:06:00.395
Давайте поговорим о том, кто может подключиться.

00:06:00.395 --> 00:06:03.055
Таким образом, вы хотите поставить
некоторые элементы управления о,

00:06:03.055 --> 00:06:05.570
как вы на самом деле фильтр, кто

00:06:05.570 --> 00:06:08.345
может подключиться к
база данных Azure S'L.

00:06:08.345 --> 00:06:11.075
Так что это, и я буду
показать это в демо.

00:06:11.075 --> 00:06:16.055
Это в основном брандмауэр
папка лезвия на портале Azure.

00:06:16.055 --> 00:06:17.900
Так что первое, что вы заметите здесь

00:06:17.900 --> 00:06:19.430
это раздел вверху, что говорит:

00:06:19.430 --> 00:06:22.550
допустить доступ к
Службы Azure, включаемые или выключаемые.

00:06:22.550 --> 00:06:25.340
Так что это очень широкая категория

00:06:25.340 --> 00:06:26.855
разрешения, которое
Вы даете здесь.

00:06:26.855 --> 00:06:28.420
Это в основном говорят,

00:06:28.420 --> 00:06:32.065
может любые другие серверы, которые
работает в Azure,

00:06:32.065 --> 00:06:35.915
сказать, как веб-приложение
или другой Azure VM,

00:06:35.915 --> 00:06:40.815
он может подключиться к вашей
Сервер базы данных S'L или нет?

00:06:40.815 --> 00:06:42.420
Как и в любой точке Лазурного?

00:06:42.420 --> 00:06:42.545
Да, да.

00:06:42.545 --> 00:06:46.245
- Был ли он установлен регионом
или зоны или центра обработки данных?

00:06:46.245 --> 00:06:47.205
Это не имеет значения.

00:06:47.205 --> 00:06:47.940
Это не имеет значения.

00:06:47.940 --> 00:06:49.910
В принципе, это то, что это делает,

00:06:49.910 --> 00:06:52.060
когда вы работаете
услуг и услуг в Azure,

00:06:52.060 --> 00:06:57.605
в каждом регионе или центре обработки данных
набор фиксированных IP-адресов.

00:06:57.605 --> 00:07:00.710
Таким образом, мы в основном, это правило, которое

00:07:00.710 --> 00:07:03.560
говорит все, что
подходит ко мне от идеи.

00:07:03.560 --> 00:07:03.935
Изнутри Azure.

00:07:03.935 --> 00:07:04.205
Да, да.

00:07:04.205 --> 00:07:05.165
Доверенный центр обработки данных.

00:07:05.165 --> 00:07:05.675
Да, да.

00:07:05.675 --> 00:07:07.460
Так я собираюсь принять? Я Вас понял.

00:07:07.460 --> 00:07:10.100
Вопрос: Теперь, конечно, люди
имеют оговорки против

00:07:10.100 --> 00:07:12.875
это потому, что это
немного более широкий охват,

00:07:12.875 --> 00:07:15.215
но в некоторых сценариях,

00:07:15.215 --> 00:07:16.280
Вы должны сделать это.

00:07:16.280 --> 00:07:18.785
Например, веб-приложение является одним из примеров.

00:07:18.785 --> 00:07:21.620
Но постепенно мы
придумывать предложения

00:07:21.620 --> 00:07:25.295
где вы сможете поставить
это ввыключениваю и придумать.

00:07:25.295 --> 00:07:27.650
Я покажу тебе.
различными способами, в которых-

00:07:27.650 --> 00:07:29.285
Я собираюсь сделать
купить тип услуги

00:07:29.285 --> 00:07:30.845
или что-то вроде
веб-приложение или что-то?

00:07:30.845 --> 00:07:31.465
Да, да.

00:07:31.465 --> 00:07:32.985
Затем просто чтобы прояснить,

00:07:32.985 --> 00:07:36.120
когда вы говорите, какой-либо службы в Azure,

00:07:36.120 --> 00:07:38.160
это в пределах ваших собственных
описание, конечно.

00:07:38.160 --> 00:07:38.925
Да, да.

00:07:38.925 --> 00:07:41.115
Просто чтобы прояснить, что для людей.

00:07:41.115 --> 00:07:44.420
Да, да. Таким образом, следующий уровень контроля

00:07:44.420 --> 00:07:47.525
что мы предлагаем это то, что
Брандмауэр на основе IP.

00:07:47.525 --> 00:07:55.080
Так что это, как правило, когда вы
предоставить сервер базы данных Azure S'L,

00:07:55.080 --> 00:07:58.080
список по умолчанию здесь напоминающий.

00:07:58.080 --> 00:08:01.430
Таким образом, никто не может подключиться к нему

00:08:01.430 --> 00:08:04.820
с помощью IP-адреса, если
они находятся в этом списке.

00:08:04.820 --> 00:08:05.580
Я поймала тебя.

00:08:05.580 --> 00:08:07.305
Так что первое, что
Вам нужно сделать, это,

00:08:07.305 --> 00:08:09.195
когда вы идете на портал,

00:08:09.195 --> 00:08:12.125
он покажет вам IP-адрес
что вы откуда.

00:08:12.125 --> 00:08:14.690
Так что, если я иду из моего дома IP,

00:08:14.690 --> 00:08:17.945
вот где он будет отображаться в
этот раздел IP-адреса клиента,

00:08:17.945 --> 00:08:20.810
и мне нужно в белый список, что
для того, чтобы я мог

00:08:20.810 --> 00:08:23.755
подключиться с помощью
Например, студия управления.

00:08:23.755 --> 00:08:25.210
Хорошо, хорошо. Довольно стандартные вещи,

00:08:25.210 --> 00:08:26.840
мы сделали все это по умолчанию.

00:08:26.840 --> 00:08:27.485
Точно.

00:08:27.485 --> 00:08:28.450
Хорошо, хорошо.

00:08:28.450 --> 00:08:30.890
Теперь у нас есть
третий интересный способ

00:08:30.890 --> 00:08:33.845
подключение, которое называется
Правила брандмауэра VNet.

00:08:33.845 --> 00:08:35.785
Это в значительной степени говорят,

00:08:35.785 --> 00:08:37.985
позволяют все Azure VMs

00:08:37.985 --> 00:08:41.390
внутри VNet для подключения
в мою базу данных S'L.

00:08:41.390 --> 00:08:44.030
Теперь могут возникнуть ситуации,
где это полезно,

00:08:44.030 --> 00:08:46.370
сказать, что у вас есть наследие приложение
или ваше приложение, скажем,

00:08:46.370 --> 00:08:47.900
отчетность служб, работающих в

00:08:47.900 --> 00:08:51.060
VM, и вы хотите
подключиться к базе данных S'L,

00:08:51.060 --> 00:08:53.555
это гранулированный способ
делать это, чтобы позволить

00:08:53.555 --> 00:08:56.270
только определенный набор ВМ, которые

00:08:56.270 --> 00:08:58.970
находятся в рамках подсети к
подключиться к базе данных S'L.

00:08:58.970 --> 00:08:59.405
Хорошо, хорошо.

00:08:59.405 --> 00:09:01.565
Так что это
три способа, в которых мы

00:09:01.565 --> 00:09:04.095
контролировать, кто подключается
в базу данных S'L сегодня.

00:09:04.095 --> 00:09:05.570
Да, да. Я вижу,
, что в различных до сих пор

00:09:05.570 --> 00:09:07.430
путем перемещения устаревших приложений.

00:09:07.430 --> 00:09:07.940
Абсолютно.

00:09:07.940 --> 00:09:10.595
Мы получили VMs работает
все в рамках одного VNet.

00:09:10.595 --> 00:09:12.140
Да, да. Так что дальше,

00:09:12.140 --> 00:09:14.105
Я возьму тебя через
детали каждого из них.

00:09:14.105 --> 00:09:18.215
Итак, давайте посмотрим, как
IP-брандмауэр работает.

00:09:18.215 --> 00:09:23.655
Так предположим, что у нас есть сервер с
несколько баз данных DB1 и DB2,

00:09:23.655 --> 00:09:26.220
и вот входящие соединения.

00:09:26.220 --> 00:09:30.080
Конечно, входящие соединения
может быть прокси или перенаправить,

00:09:30.080 --> 00:09:31.535
это не имеет значения этот момент.

00:09:31.535 --> 00:09:34.100
Предположение, что вы получили
мимо шлюза, и вы

00:09:34.100 --> 00:09:36.740
на самом деле идет на
уровень двигателя S'L.

00:09:36.740 --> 00:09:39.050
Первое, что мы
собирается сделать, это мы собираемся

00:09:39.050 --> 00:09:41.630
чтобы проверить против
брандмауэры уровня базы данных.

00:09:41.630 --> 00:09:43.010
Так что это хранится в

00:09:43.010 --> 00:09:47.215
основной базы данных и
sys.database-firewall-rules.

00:09:47.215 --> 00:09:49.590
Это DMV, и все, что он содержит

00:09:49.590 --> 00:09:52.160
представляет собой ряд IP-адресов
которые разрешены.

00:09:52.160 --> 00:09:55.100
Так что если вы здесь,
затем по умолчанию,

00:09:55.100 --> 00:09:58.100
Вы получаете нашу базу данных сферы
доступ к

00:09:58.100 --> 00:10:01.790
в зависимости от базы данных
вы хотите подключиться.

00:10:01.790 --> 00:10:05.390
Если вы не в
правила брандмауэра уровня базы данных,

00:10:05.390 --> 00:10:08.735
Затем следующая проверка происходит
находится на уровне сервера,

00:10:08.735 --> 00:10:11.180
который немного
различные DMV называется

00:10:11.180 --> 00:10:15.440
sys.firewall'rules и это
снова в основной базе данных.

00:10:15.440 --> 00:10:17.420
Если у вас есть доступ сюда,

00:10:17.420 --> 00:10:19.160
то, конечно, у вас есть доступ к

00:10:19.160 --> 00:10:21.965
уровень сервера так
как только вы подключены,

00:10:21.965 --> 00:10:24.635
Вы можете в управлении
Студия выпадение вниз,

00:10:24.635 --> 00:10:26.725
выбрать dB1 и DB2.

00:10:26.725 --> 00:10:29.635
Хорошо, хорошо. Так что, если бы я был
настройка с использованием

00:10:29.635 --> 00:10:33.395
SSMS для настройки
база данных Azure S'L.

00:10:33.395 --> 00:10:37.680
Если я скажу, что брандмауэр
правило на уровне сервера,

00:10:37.680 --> 00:10:39.810
он может просто дать мне
доступ ко всему.

00:10:39.810 --> 00:10:41.130
Получил его.

00:10:41.130 --> 00:10:45.165
Так что мы, вероятно, должны пойти в
Dev тест, но не в лучших практиках.

00:10:45.165 --> 00:10:48.180
Да, да. То есть
большой вопрос, Колин,

00:10:48.180 --> 00:10:53.075
потому что одна из вещей, что
почему у нас есть эти два уровня?

00:10:53.075 --> 00:10:55.560
Это потому, что в производстве,

00:10:55.560 --> 00:10:59.045
если вы хотите использовать то, что
как содержащийся пользователь,

00:10:59.045 --> 00:11:01.595
то лучшая практика,

00:11:01.595 --> 00:11:06.515
содержащийся пользователь только позволяет
настроить содержащегося пользователя для DB1.

00:11:06.515 --> 00:11:11.340
Вся идея содержащегося пользователя
будучи я не могу получить доступ к DB2.

00:11:11.410 --> 00:11:14.780
В сочетании с
правила брандмауэра базы данных,

00:11:14.780 --> 00:11:20.555
Я также могу ограничить IP-адрес
откуда пользователи могут войти.

00:11:20.555 --> 00:11:23.180
Таким образом, по существу,
брандмауэр уровня базы данных

00:11:23.180 --> 00:11:25.010
полезная функция для данных глубины

00:11:25.010 --> 00:11:30.515
для управления областью
плохие люди могут подключиться от.

00:11:30.515 --> 00:11:31.980
Хорошо, хорошо.

00:11:32.260 --> 00:11:35.450
Итак, еще раз, просто помогите мне здесь.

00:11:35.450 --> 00:11:37.430
Не могли бы вы расширить довольно много деталей.

00:11:37.430 --> 00:11:42.650
Таким образом, на брандмауэре правил эти
находятся внутри сервера S'L и

00:11:42.650 --> 00:11:44.750
как, очевидно, то, что мы
покрыты ранее был

00:11:44.750 --> 00:11:48.215
правила брандмауэра для
сети внутри него.

00:11:48.215 --> 00:11:50.630
Да, да. Так что это
два различных понятия.

00:11:50.630 --> 00:11:52.220
Таким образом, в предыдущем слайде я показал

00:11:52.220 --> 00:11:54.155
Вы есть IP-адрес
брандмауэра.

00:11:54.155 --> 00:11:58.820
Это то, что это и
место, где они

00:11:58.820 --> 00:12:03.995
хранятся внутри мастера
базы данных в сервере S'L.

00:12:03.995 --> 00:12:07.050
Они разоблачены через портал.

00:12:07.870 --> 00:12:11.660
Конечно, если вы не встречаетесь
любой из этих критериев, то

00:12:11.660 --> 00:12:15.870
ваше соединение будет отклонено
именно о чем мы говорили.

00:12:16.090 --> 00:12:18.350
Теперь, давайте посмотрим на

00:12:18.350 --> 00:12:21.875
новая интересная часть здесь
который является правилами брандмауэра VNet.

00:12:21.875 --> 00:12:25.235
Итак, позвольте мне создать
сценарий для вас.

00:12:25.235 --> 00:12:27.830
Итак, давайте предположим, что у вас есть
виртуальная машина, которая

00:12:27.830 --> 00:12:32.135
работает сказать Наследие приложение
на iOS или любой другой.

00:12:32.135 --> 00:12:37.100
Виртуальная машина обычно
вы можете настроить то, что называется

00:12:37.100 --> 00:12:42.260
в качестве публичного IP-адреса для него
который является 14,11 адрес,

00:12:42.260 --> 00:12:45.200
и вы также можете иметь
частный IP-адрес, который

00:12:45.200 --> 00:12:48.305
поступает из определенной подсети.

00:12:48.305 --> 00:12:51.020
Таким образом, лучшие практики
всегда убедитесь, что

00:12:51.020 --> 00:12:53.600
ваши частные ИС
исходит от подсетей,

00:12:53.600 --> 00:12:55.490
помогает в сегментации сети

00:12:55.490 --> 00:12:57.920
и это сеть
передовой практики.

00:12:57.920 --> 00:13:00.305
Но я покажу вам, как это помогает.

00:13:00.305 --> 00:13:02.990
Вы, как правило, всегда
установить эти вещи или получить

00:13:02.990 --> 00:13:05.270
сетевой ИТ-профессионал, чтобы установить эти

00:13:05.270 --> 00:13:07.865
вверх, прежде чем вы идете в
другое производство.

00:13:07.865 --> 00:13:10.625
Вы хотите убедиться,
вы получили достаточно IP.

00:13:10.625 --> 00:13:11.930
Да, абсолютно.

00:13:11.930 --> 00:13:13.985
Это хороший момент
что вы воспитываете это

00:13:13.985 --> 00:13:16.985
мы определенно хотим
разделение обязанностей здесь,

00:13:16.985 --> 00:13:20.390
это всегда хорошо планировать
вашей сети заранее.

00:13:20.390 --> 00:13:22.790
Значит, ты не искончишь
IP-адресов и

00:13:22.790 --> 00:13:26.495
то вы, конечно, не
хочу, чтобы DBM мессинг

00:13:26.495 --> 00:13:32.030
вокруг с настройкой этих и
получение размера неправильно или потому, что

00:13:32.030 --> 00:13:37.850
каждый из них это легко
пропустить вещи здесь.

00:13:37.850 --> 00:13:40.280
Да, и как только вы
установить эти диапазоны и

00:13:40.280 --> 00:13:42.995
начал устанавливать вещи
это вы не можете пойти назад.

00:13:42.995 --> 00:13:47.000
Получил его. Так что есть
базовая настройка.

00:13:47.000 --> 00:13:50.930
У меня есть VM, у него есть общественный
IP-адрес и частный IP-адрес.

00:13:50.930 --> 00:13:54.020
Итак, позвольте мне принять вас через
вариант номер один, который является, как

00:13:54.020 --> 00:13:57.350
подключиться ли я к базе данных S'L
с помощью общественности,

00:13:57.350 --> 00:14:01.190
мы обычно называем это
snatted IP-адрес.

00:14:01.190 --> 00:14:04.130
Вариант номер один : давайте начнем с

00:14:04.130 --> 00:14:06.980
Стороны VM, и мы можем определить, что

00:14:06.980 --> 00:14:09.230
называется правилом NSG, которое

00:14:09.230 --> 00:14:12.455
в основном говорит, что я собираюсь
для обеспечения исходящего трафика.

00:14:12.455 --> 00:14:14.630
- NSG, группа сетевой безопасности?

00:14:14.630 --> 00:14:17.170
Группа сетевой безопасности
которые существуют на

00:14:17.170 --> 00:14:21.120
VM на виртуальной машине.

00:14:21.120 --> 00:14:24.305
Это позволяет определить
входящих и исходящих правил.

00:14:24.305 --> 00:14:28.865
Так вот мы определим исходящие
правило для подключения к базе данных S'L.

00:14:28.865 --> 00:14:31.880
То, как мы это сделаем
мы скажем, что мне нужно

00:14:31.880 --> 00:14:35.225
подключиться к 1433, потому что
это мой инициал.

00:14:35.225 --> 00:14:37.460
Помните изначально вы
необходимо подключить к

00:14:37.460 --> 00:14:40.565
шлюз, который
инвестирование в порт 1433.

00:14:40.565 --> 00:14:43.700
Тогда, мне нужно 11000 через

00:14:43.700 --> 00:14:48.170
11,999 диапазон, потому что я
собирается использовать перенаправление.

00:14:48.170 --> 00:14:50.990
Тогда TCP мой протокол.

00:14:50.990 --> 00:14:54.425
Мой IP-адрес 40.112 адрес

00:14:54.425 --> 00:14:57.815
и путь на право
самая интересная часть.

00:14:57.815 --> 00:15:01.355
Я говорю, пусть эта виртуальная машина

00:15:01.355 --> 00:15:04.415
подключиться ко всему в S'L. ВестУС.

00:15:04.415 --> 00:15:08.615
Так что это снова еще одна сеть
концепция называется тегом обслуживания.

00:15:08.615 --> 00:15:12.935
Так что это значит, что я хочу
для подключения к базе данных S'L.

00:15:12.935 --> 00:15:15.410
Я знаю, что моя база данных находится в WestUS,

00:15:15.410 --> 00:15:19.715
позвольте мне просто белый список
в район Западного США.

00:15:19.715 --> 00:15:21.125
Это очень хорошо.

00:15:21.125 --> 00:15:24.455
Таким образом, вы могли бы просто позволить
мне использовать это как или

00:15:24.455 --> 00:15:29.795
только использует, чтобы помочь с
только ваша задержка и трафик.

00:15:29.795 --> 00:15:32.390
Да, я имею в виду
суть в том, что это

00:15:32.390 --> 00:15:36.620
является способом обеспечения
подключения со стороны сети.

00:15:36.620 --> 00:15:38.450
Так что обычно ваш
сетевой админ сделает

00:15:38.450 --> 00:15:41.540
это и это просто делает
управление проще

00:15:41.540 --> 00:15:42.770
для них, потому что когда вы говорите,

00:15:42.770 --> 00:15:46.940
Sql. WestUS вы не должны
белый список отдельных IP-адресов.

00:15:46.940 --> 00:15:49.610
Таким образом, это позволяет
подключиться к чему-либо в

00:15:49.610 --> 00:15:53.180
любая база данных СЗЛ, которая
в регионе Западно-Уси.

00:15:53.180 --> 00:15:55.850
Теперь это также несет

00:15:55.850 --> 00:15:57.845
дополнительные накладные расходы
в том смысле, что

00:15:57.845 --> 00:15:59.990
как только вы закончите с
настройка сети,

00:15:59.990 --> 00:16:02.000
Вы должны прийти на
сторона базы данных S'L

00:16:02.000 --> 00:16:04.655
и снова вспомнить наши
БРАНДмауэр IP-адреса.

00:16:04.655 --> 00:16:06.845
Таким образом, вам нужно добавить IP-адрес здесь.

00:16:06.845 --> 00:16:08.975
Так что это двухэтапный процесс.

00:16:08.975 --> 00:16:12.230
Недостатки этого являются одним

00:16:12.230 --> 00:16:15.440
это вы должны управлять IP-адресом.

00:16:15.440 --> 00:16:19.520
Так, например, в любое время, если вы
цепи общедоступный IP-адрес для

00:16:19.520 --> 00:16:22.280
VM немедленно
это подключение будет

00:16:22.280 --> 00:16:25.400
сломанной, потому что S'L не будет
признать, что IP-адрес.

00:16:25.400 --> 00:16:27.200
Да, потому что не «неразборчиво».

00:16:27.200 --> 00:16:30.740
Да, да. Другая вещь
об этом, что

00:16:30.740 --> 00:16:33.140
некоторые клиенты могут не нравится то

00:16:33.140 --> 00:16:36.155
тег обслуживания по-прежнему
довольно широко открыты.

00:16:36.155 --> 00:16:37.805
Он говорит, позвольте мне подключиться к

00:16:37.805 --> 00:16:41.840
любая база данных СЗЛ в
западно-американский регион.

00:16:41.840 --> 00:16:44.090
Но, конечно, есть улучшения

00:16:44.090 --> 00:16:46.130
ближайшие на стороне сети
, что позволит вам

00:16:46.130 --> 00:16:48.575
ограничить это конкретным ресурсом

00:16:48.575 --> 00:16:51.035
но те находятся в
прогресса на данный момент.

00:16:51.035 --> 00:16:52.820
Но это то, что у нас есть.

00:16:52.820 --> 00:16:58.775
Так что теперь давайте перевернем направление
из которых мы идем сюда.

00:16:58.775 --> 00:17:02.720
Вы видели, как мы настраивались на
ВМ стороны к S'L DB.

00:17:02.720 --> 00:17:05.240
Правило брандмауэра Vnet
то, что вы установили

00:17:05.240 --> 00:17:07.400
выпускной бал на стороне базы данных S'L, как

00:17:07.400 --> 00:17:11.330
это сказать позвольте мне подключиться от

00:17:11.330 --> 00:17:17.135
моя база данных S'L для
частности подсети.

00:17:17.135 --> 00:17:21.005
Таким образом, красота его
это вам не нужно

00:17:21.005 --> 00:17:25.280
в белый список любых IP-адресов
или сделать что-нибудь подобное.

00:17:25.280 --> 00:17:28.460
Все, что ты хочешь сказать, это
открывая путь между

00:17:28.460 --> 00:17:29.960
ваша база данных s'L и

00:17:29.960 --> 00:17:33.620
частности подсети, и вы
с помощью частного IP-адреса.

00:17:33.620 --> 00:17:36.485
Так что есть, что даже
добавил выгоды, которые

00:17:36.485 --> 00:17:42.455
все переживает
магистральная сеть Azure мудрый.

00:17:42.455 --> 00:17:43.970
Это довольно круто.

00:17:43.970 --> 00:17:50.750
Другим преимуществом этого является
нет белого списка требуется, и да,

00:17:50.750 --> 00:17:52.625
это в значительной степени это.

00:17:52.625 --> 00:17:56.420
Прохладный. Так что спасибо вам за это.

00:17:56.420 --> 00:17:58.160
Это действительно хорошее объяснение

00:17:58.160 --> 00:18:01.220
подключение к
База данных Azure S'L.

00:18:01.220 --> 00:18:03.780
Пара других быстрых вопросов,

00:18:03.790 --> 00:18:06.680
это только для Azure
База данных S'L, как и все

00:18:06.680 --> 00:18:08.780
их различные
варианты развертывания.

00:18:08.780 --> 00:18:11.855
Я думаю, что у нас есть один упругий
цель была управляемой экземпляра.

00:18:11.855 --> 00:18:12.290
Абсолютно.

00:18:12.290 --> 00:18:15.360
Вопрос: Это для всех из них это
повлияли на варианты вы объяснили?

00:18:15.360 --> 00:18:18.530
Поэтому, когда мы говорим о
База данных Azure S'L сегодня,

00:18:18.530 --> 00:18:23.180
если вы посмотрите на одного
Базы данных S'L, эластичные бассейны,

00:18:23.180 --> 00:18:26.779
склад данных и
даже базы данных с открытым исходным кодом,

00:18:26.779 --> 00:18:30.200
мы разделяем общий контроль
плоскости, что означает, чтобы

00:18:30.200 --> 00:18:34.640
сказать шлюз S'L, что вы
видел, что компонент является общим.

00:18:34.640 --> 00:18:37.820
Таким образом, это подключение относится к

00:18:37.820 --> 00:18:39.410
все наши предложения, которые находятся под

00:18:39.410 --> 00:18:41.525
зонтик базы данных Azure S'L.

00:18:41.525 --> 00:18:44.690
Это фантастика. Ну, спасибо

00:18:44.690 --> 00:18:47.600
очень много всех для
настройки и дать нам

00:18:47.600 --> 00:18:50.210
как, если вам нравится
этот тип контента

00:18:50.210 --> 00:18:53.300
и подписаться на нас, и мы будем
увидимся позже. Спасибо.

00:18:53.300 --> 00:19:06.000
(МУЗЫКА)