Глава 5. Построение сетей Windows Server 2016

Добро пожаловать на тёмную сторону? К сожалению, это то, что многие люди думают об IPv6 на данный момент. Хотя IPv6, несомненно, не является новой вещью, в моей практике это нечто из той области, что почти никто не реализовывал в своих собственных сетевых средах. Работая с сотнями различных компаний по всему миру на протяжении нескольких последних лет, я нашёл только одну организацию, которая работала с IPv6 во всей своей промышленной сетевой среде, причём это даже не была действительно естественная IPv6. Вместо этого они применяли технологию туннелирования, называемую ISATAP во всей своей сетевой среде чтобы сделать все свои сервера и клиенты общающимися между собой с применением пакетов IPv6, однако все эти пакеты всё ещё перемещались в физической сетевой среде IPv4. Почему им кажется настолько сложным поместить IPv6 на своё место? Потому что мы применяли IPv4 начиная с его появления, это то что мы все знаем и понимаем, а также в действительности нет большой потребности переходить на IPv6 внутри наших сетевых сред. Подождите минутку; я полагал, что присутствовала большая паника, которая побудила к побегу от адресов IPv4? Да, это верно для адресов IP в общедоступном Интернете, однако ничего общего не имело нашими внутренними сетевыми средами. Как вы видите, даже если мы завтра выйдем в работе за пределы общедоступных адресов IPv4, наши внутренние сети в наших компаниях не будут иметь никакого воздействия от этого. Мы можем продолжать работать с IPv4 внутри своей сети на протяжении длительного времени, возможно всегда и везде, так долго, пока нам комфортно применять технологии NAT для трансляции обмена назад в IPv4 по мере его получения из Интернета. Мы все применяем NAT в одной или другой наружности почти всё время существования IPv4, поэтому он очевидно очень удобен для некоторых людей.

Позвольте мне внести ясность, я не пытаюсь убедить вас, что застревание с IPv4 является путём в будущее. Я просто излагаю факты, которые для большинства организаций на протяжении последующих нескольких лет просто будут истиной. Причина, по которой я хочу обсудить здесь IPv6 состоит в том, что со временем вам придётся иметь с ним дело. А раз так, вы действительно должны озадачиваться им! Существуют гигантские преимущества, которые IPv6 имеет над IPv4, а именно, несоизмеримо большее количество IP адресов которое вы можете содержать внутри отдельной сетевой среды. Сетевые команды в компаниях по всему миру каждый день борются с потребностью построения всё большего и большего числа сетевых сред IPv4 и связывания их вместе. Подумайте о них, сегодня существует множество компаний с числом сотрудников превосходящим 10 000. Многие имеют намного, многократно, превышающее это значение число. В сегодняшнем технологическом мире каждому необходима технология и доступ к данным. Данные являются новой валютой. Большинство пользователей теперь также имеют по крайней мере по два физических устройства, которые они применяют в своей работе, а иногда и больше. Ноутбук и планшет, ка также сотовый телефон, или настольный компьютер и ноутбук и планшет, вы можете продолжить. В мире IPv4 где вы имеете дело с относительно небольшими диапазонами IP адресов, вы должны быть очень творческими при создании подсетей чтобы размещать все физические устройства, причём каждое из них нуждается в уникальном IP адресе для взаимодействия в общей сетевой среде. Наибольшее преимущество IPv6 состоит в немедленном разрешении всех этих проблем и при этом по умолчанию посредством предоставления возможности иметь намного больше IP адресов в рамках отдельной сетевой среды. О каком количестве адресов мы говорим? Вот некоторые данные для сопоставления, чтобы дать вам небольшую перспективу:

Как вы можете увидеть, адрес IPv4 намного короче, что очевидно означает меньшие возможности для уникальных IP адресов. Когда мы устанавливаем сети IPv4, выделение подсетей является чрезвычайно важным, поскольку это то, что делает возможным для нас иметь более чем один набор IP адресов в рамках одной и той же сетевой среды. В большинстве основных форм планирования сетей в которых вы назначаете некоторые IP адреса и выполняете маску подсети в виде 255.255.255.0, что достаточно распространено, причём эта подсеть ограничена всего лишь 254 уникальными адресами IP. Ох! Некоторые компании имеют тысячи различных серверов, помимо всех своих компьютеров клиентов и устройств, которые также необходимо подключать к общей сетевой среде. К счастью мы можем строить множество различных подсетей внутри отдельной сетевой среды IPv4 чтобы увеличивать нашу используемую сферу адресов IP, однако это требует тщательного планирования и вычисления этих подсетей и адресных пространств, и это причина, по которой мы полагаемся на опытных сетевых администраторов для управления этой частью сетевой среды для нас. Одна неверная настройка в таблице маршрутизации может переполнить поток сетевого обмена. Администрирование подсетей в сетевой среде IPv4 не для слабонервных.

Когда мы говорим об адресации IPv6, почти всегда ограничением является небо. Если бы вы попытались вычислить общее число уникальных адресов доступное в этом 128- битном пространстве, которое продемонстрировали ранее, вы можете обнаружить в нём более 340 ундециллиона доступных для создания адресов. Другими словами, это 340 триллионов триллионов триллионов адресов. Это значение навязывает нам то как много доступных адресов существует во всём Интернете, однако что это означает для наших внутренних сетей?

Чтобы обсудить общее число адресов которое мы имели бы внутри обычной внутренней сети, работающей с IPv6, давайте сделаем шаг назад и взглянем на адрес сам по себе. Адрес, который я показал ранее, это просто что- то созданное мной, однако мы разобьём его здесь на части.

1111:AABB:CCDD:AB00:0123:4567:8901:ABCD
 	   

В сопоставлении с 192.168.1.5 это выглядит чудовищно. Это потому, что нам обычно не приходится иметь дел с шестнадцатеричными значениями. Но всё что у нас здесь есть, это просто иной способ представления данных. Как мы уже упомянули, это 128- битный адрес. Так как он разбивается на восемь различных секций, каждая из отделяемая двоеточием состоит из 16 бит. Это обычная практика, когда компании выделяют секцию своего адреса как префикс организации, нечто что будет одним и тем же во всех их сетевых средах и устройствах. Давайте предположим, что это самые первые 48- бит, или первые три секции шестнадцатеричных значений. Затем, четвёртый набор информации, следующие 16 бит, могут быть идентификатором подсети. При применении множества значений здесь в качестве идентификатора подсети это даёт нам гибкость наличия множества различных подсетей, которые мы пожелаем в будущем. После выделения первой половины всего адреса у нас теперь имеется оставшаяся для работы половина, 64 бита. Она может быть оставлена для идентификации устройства. Эта часть вашего адреса будет уникальной для каждого устройства в вашей сетевой среде, и будет определять индивидуальный статичный IPv6 адрес, который будет применяться для взаимодействия. Давайте выложим всё это здесь. Мы возьмём пример адреса с предыдущей страницы и поделим его на следующие части:

Сколько устройств мы можем иметь в нашей сетевой среде в некоторой схеме IP, подобной нашей? Хорошо, даже в нашем примере где мы выделили только 16- битную секцию для адресации подсетей и 64 бита для реальных адресов IP, это может предоставить нам возможность иметь более 65 000 подсетей и квинтиллионы уникальных идентификаторов устройств в нашем диапазоне IP. Впечатляюще!

Если мы будем следовать вышесказанному и применять просто отдельные подсети для содержания всех наших машин, тогда первая половина нашего адреса всегда будет оставаться одной и той же, делая этот адрес намного более простым для запоминания и работы с ним. Это окажется сюрпризом, насколько быстро вы привыкнете видеть эти большие шестнадцатеричные номера в своей среде, однако даже хотя вы и начнёте распознавать их, вы скорее всего не соберётесь больше быстро переходить на серверы и компьютеры в вашей сетевой среде со статическими IP адресами. Я уверен, что многие из вас всё ещё имеют привычку говорить "Если мне нужно быстро перепрыгнуть на мой веб- сервер, я просто выполняю RDP на 192.168.1.5". Просто для набора такого IPv6 адреса, даже если вы его запомнили, требуется определённое время, которое не стоит того. IPv6 принесёт с собой ещё большую зависимость от DHCP и DNS, чтобы сделать его более удобным для применения.

Теперь, когда мы понимаем какие секции вашего адреса предназначены для применения в каких целях, как мы собираемся назначать индивидуальные номера идентификации устройств для всех своих компьютеров, серверов и прочих устройств в нашей сети? Вы можете начать со значения 1 и идти от него дальше. Другая идея, которую я недавно подглядел где- то в применении, состоит в вычислении старого адреса IPv4 в шестандцатеричном представлении и использовать его в качестве последних 32 бит своего адреса. Если вы откроете на своём компьютере Windows Calculator, раскройте его меню и установите его в режим Programmer. Это быстрый и простой инструмент для преобразования десятичных значений в шестнадцатеричные и наоборот. Давайте воспользуемся примером моего веб- сервера, который работает по адресу 192.168.1.5. Я хочу реализовать IPv6 в своей сети и я хочу чтобы мои адреса IPv6 отражали первоначальные адреса IPv4 идентификаторах моих устройств своего нового адреса. В своём калькуляторе я ввожу 192 и нажимаю на HEX, что показывает мне соответствующее шестнадцатеричное представление десятичного 192. Если я проделаю это с каждым октетом в своём IPv4 адресе, я увижу следующее:

192 = C0
168 = A8
1 = 01
5 = 05
 	   

 

Рисунок 1

Таким образом, мой сомножитель 192.168.1.5 превращается в C0A8:0105. Теперь я могу применять его в комбинации со своими префиксом организации и идентификатором подсети для создания статического адреса IPv6 своего веб- сервера.

1111:AABB:CCDD:0001:0000:0000:C0A8:0105
 	   

В предыдущем IPv6 адресе вы отметили, что я ввёл шестнадцатеричное значение для своего идентификатора устройства в самом конце, но я также внёс пару других изменений. Так как мы оставляем самые последние 64 бита доступными для идентификатора своего устройства, в то время как мой старый IP адрес потреблял 32 бита, я остаюсь с 32 битами в середине. Было бы странным иметь здесь некоторые данные, которые бы имели для меня некоторое значение, поэтому я просто заполню их нулями для упрощения своей схемы адресации. В дополнение к этому изменению, я также выровняю свой идентификатор подсети, чтобы он имел значение 1, так как это первая подсеть в моей сетевой среде.

Наша новая адресация становится выглядеть слегка понятнее и нести больше смысловой нагрузки. Теперь, когда мы видим этот новый адрес для своего веб- сервера выставленным, Я могу увидеть, что существуют некоторые дополнительные задачи очистки, которые мы можем выполнить на своём адресе чтобы заставить его выглядеть ещё лучше. Прямо сейчас приведённый выше адрес является 100% точным. Я могу подключить этот IP адрес в свойства NIС своего веб- сервера и это будет работать. Однако, присутствует множество нулей в моём адресе и нет необходимости чтобы я сохранял их все. Всякий раз, когда у вас имеются ненужные нули в пределах 16- битного сегмента, которому предшествует реальное число, они могут быть просто удалены. Например, наш идентификатор подсети и первые 32 бита нашего идентификатора устройства имеют множество ненужных нулей, поэтому я могу объединить адрес до следующего:

1111:AABB:CCDD:1:0:0:C0A8:0105
 	   

Затем, сделаем ещё шаг вперёд, всякий раз, когда у вас имеется полная секция из 16 бит, которая целиком заполнена нулями, она может быть полностью объединена в двойное двоеточие. Поэтому первые 32 бита идентификатора моего устройства которые целиком состоят из нулей, я могу заместить ::. Ниже приводятся полностью расписанный адрес и адрес в консолидированном виде. Эти числа выглядят совершенно различными. Мой консолидированный адрес намного проще на глаз, однако с точки зрения технологии они представляют в точности одно и то же число:

1111:AABB:CCDD:0001:0000:0000:C0A8:0105
1111:AABB:CCDD:1::C0A8:0105
 	   

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

1111:0000:0000:0000:0000:0000:0000:0001
1111::1
 	   

	Совет
	Важно отметить, что вы можете применять двойное двоеточие один раз внутри некоего адреса IP. Если у вас имеется два места, где вы можете его поместить, вы можете реализовать это только в одном из этих мест, а второе вам придётся заполнить нулями.

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

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

Даже самые новые ИТ профи обычно знакомы с ней. Ping является командой, которая используется из командной строки или PowerShell, и просто применяется для запроса IP адреса на предмет того отвечает он или нет. Ping является и всегда был инструментом который "следует применять" для тестирования связности между двумя устройствами в сетевой среде. Из клиента Win10 в вашей локальной сети я могу открыть приглашение командной строки и ping <IP_ADDRESS>. В качестве альтернативы я применяю DNS в своей среде, который будет разрешать имена в IP адреса, поэтому я могу также ping <SERVERNAME>, как это показано в примере ниже.

Вы можете видеть, что мой сервер откликается на мой ping, давая мне понять что сервер работает и отвечает:

 

Рисунок 2

Технически обмен с ping называется ICMP. Это важно, так как ICMP по умолчанию блокируется всё чаще и чаще в наши дни при помощи существующих межсетевых экранов, включённых по умолчанию в большинстве наших систем и устройств. Исторически ping всегда был инструментом, на который мы могли бы рассчитывать что он нам наверняка сообщит есть или нет связь между двумя устройствами, однако это больше не всегда так. Если вы построите новую коробку Windows и подключите её в свою сеть, этот компьютер может взаимодействовать с Интернетом и всеми вашими серверами в вашей сетевой среде, однако если вы попытаетесь пингануть этот новый компьютер с другой машины из своей сети, этот ping может оказаться неудачным. Почему это происходит? Потому что Windows имеет встроенные в него по умолчанию некоторые меры по безопасности, включая блокировку обмена ICMP в межсетевом экране (Firewall) Windows. Поэтому в данном случае вам необходимо либо отключить такой межсетевой экран, либо снабдить его правилом доступа, допускающим обмен ICMP. Когда такое правило включено, ping начнёт откликаться с нового компьютера. Держите в уме, что всякий раз, когда вы строите новые системы или сервера в своей сетевой среде, ping не всегда наиболее достоверный инструмент, на который можно полагаться в сегодняшнем сетевом мире.

Tracert, произносимое как Trace Route (трассировка маршрута), является инструментов, который применяется для отслеживания того, как сетевые пакеты путешествуют по вашей сетевой среде. В действительности, то что она выполняет, так это просмотр всех мест, на которые данный пакет натыкается прежде чем достигнет назначения. Такой путь столкновений, который необходимо преодолеть пакету называется hops (скачками, интервалами связи). Трассировщик маршрута показывает вам все интервалы (hops), которые имеет вам обмен для достижения необходимого сервера или в случае, когда он пытается осуществить это соединение. Моя тестовая лаборатория очень проста и заточена, поэтому выполнение tracert не покажет нам много чего. Однако, если я открою приглашение PowerShell в машине подключённой к Интернету и выполню tracert к веб службе наподобии Bing, мы получим некоторые интересные результаты:

 

Рисунок 3

	Совет
	Если вы используете tracert, но при этом не интересуетесь информацией DNS, порождаемой в выводе, воспользуйтесь tracert -d, чтобы сосредоточиться только на адресах IP.

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

Я отключил свой маршрутизатор Bynthytn и выполнил тот же самый tracert www.bing.com вновь, и теперь мы можем видеть, что всё ещё взаимодействую со своим локальным маршрутизатором, но не далее него:

 

Рисунок 4

Трассировщик маршрута полезен и кажется фактическим стандартом для отслеживания прохождения пакетов в вашей сети, однако с моей точки зрения следующая команда обладает ещё большей мощностью. Pathping по существу то же самое, что и tracert, за исключением того, что он предоставляет дополнительный объём критически важной информации. В большей части случаев применения этих команд вы интересуетесь только тем, где в цепочке ваших хопов что- то обрывается, однако часто, когда я настраиваю серверы для сетевых целей, я работаю с серверами и оборудованием, которое имеет множество различных сетевых плат. Когда мы имеем в системе дело со множеством NIC, локальная таблица маршрутизации также очень важна, как и внешние маршрутизаторы и коммутаторы, и я часто обычно хочу проверить весь путь некоторого сетевого пакета с тем, чтобы увидеть через какие локальные NIC он проходит. Это именно тот случай, в котором pathping становится более полезным, чем tracert. Первая часть информации, которую tracert показывает вам это его первый хоп по выходу из своего локального сервера, с которого вы перемещаетесь. Однако, в случае pathping, он всегда показывает вам через какой локальный сетевой интерфейс ваши пакеты следуют. Позвольте мне продемонстрировать это на примере. Я часто настраиваю серверы удалённого доступа со множеством NIC, и в течении этого процесса мы создаём множество маршрутов в нашем локальном сервере с тем, чтобы он знал какой обмен должен отсылаться в каком направлении, например, какой обмен должен идти к Внутренней NIC, а какой обмен должен идти к Внешнему NIC. После завершения всех наших установок маршрутизации для нашего Внутреннего NIC, мы проверим его на пинг сервера внутри нашей сетевой среды. Этот пинг проваливается, и мы не понимаем почему. Я пытаюсь применить команду tracert, однако она не способна предоставить мне ничего полезного, так я просто не могу увидеть первый прыжок, она просто завершается по тайм- ауту. Однако, если я вместо этого попробую pathping, первый хоп всё ещё завершится тайм- аутом, однако я теперь могу увидеть, что мой обмен пытается исполняться через мой Внешний NIC - упс - мы, должно быть, что- то установили неверно со статическим маршрутом в этом сервере. Поэтому теперь я знаю, что я должен удалить этот маршрут и повторно создать его чтобы заставить такой поток обмена проходить вместо этого через Внутренний NIC. Вот то же самое приглашение PowerShell с того же самого компьютера, который я применял в своём снимке экрана для tracert. Вы можете увидеть, что pathping показывает мне локальный IP адрес моего ноутбука, с которого обмен пытается покинуть систему, в котором tracert не показывал данную информацию:

 

Рисунок 5

Команды, которые мы обсуждали до сих пор, могли исполняться либо из командной строки, либо из PowerShell, однако теперь настало время погрузиться в более новые средства, которые могут работать только из приглашения PowerShell. Это cmdlet, называемый Test-Connection, и это вид, подобный ping на стероидах. Если мы откроем приглашение PowerShell в своей лаборатории и выполним Test-Connection WEB1, мы получаем очень похожие результаты на те, которые мы получали обычным ping, однако выводимая информация мне кажется более простой для восприятия. Присутствует также неожиданная колонка данных, называемая здесь Source:

 

Рисунок 6

Это интересно. Я зарегистрировался на своём сервере DC1 когда я выполнил данную команду и поэтому да, конечно моим источником для этой команды был DC1. Однако означает ли это что у меня есть возможность управлять этим компьютером источника для cmdlet Test-Connection? Да, это означает именно это. Как и всё в управлении Windows Server 2016, необходимость быть зарегистрированным на локальном сервере теперь отсоединена. Это специфично именно для cmdlet Test-Connection и означает, что у вас есть возможность открывать приглашение PowerShell где угодно в вашей сетевой среде и проверять соединение между двумя различными конечными точками, даже если вы не зарегистрированы ни на одной из них. Давайте проверим это. Я всё ещё зарегистрирован на своём сервере DC1, однако я собираюсь воспользоваться cmdlet Test-Connection чтобы проверить соединение между рядом своих серверов в данной сетевой среде. Как вы увидите, вы можете не только определять различные компьютеры источника вместо того, на котором вы зарегистрированы в настоящий момент, но вы также можете продвинуться ещё на шаг вперёд и определить множество источников и получателей при помощи данного мощного cmdlet -а. Поэтому, если я пожелаю проверить соединение с пары различных машин источников на пару различных получателей, это проще сделать командой навроде следующей:

Test-Connection –Source DC1, DC2 –ComputerName WEB1, BACK1
 	   

 

Рисунок 7

Как вы можете увидеть, у меня имеется статистика с обоих DC1 и DC2, причём до каждого из серверов WEB1 и BACK1 в моей сетевой среде. Test-Connection имеет потенциал быть очень мощным инструментом мониторинга!

Ещё одной мощной функцией, которую стоит указать здесь, является то, что вы можете также можете очистить вывод своей команды достаточно просто, воспользовавшись переключателем –Quiet Добавление –Quiet в команду Test-Connection очищает вывод и отображает вам простые True или False в случае если соединение было успешным, вместо отображения всех ваших индивидуальных отосланных пакетов ICMP. К сожалению, оказывается что вы не можете сочетать оба переключателя, –Source и –Quiet, однако если вы применяете Test-Connection с первоначального компьютера источника, на которм вы зарегистрировались, как это делает большинство из нас повсеместно, тогда –Quiet работает великолепно. Обычно нам действительно нужно знать Да или Нет о том, работают ли соединения и нет необходимости заботиться обо всех четырёх попытках. Применяя –Quiet мы получаем именно это. Если я где- то применил бы Test-Connection стандартным образом, чтобы попытаться установить контакты всех серверов в своеё сети, то я получил бы достаточно объёмный вывод. Однако воспользовавшись переключателем –Quiet, я получаю назад простые True и False, в зависимости от того можно или нет соединиться с каждым конкретным сервером.

Test-Connection -Quiet –ComputerName WEB1, BACK1, DC2, CA1
 	   

 

Рисунок 8

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

Когда мы обсуждали ранее ping, мы говорили об обратной стороне ICMP, состоящей в том, что он обычно блокируется, и что это становится всё более стандартным в наши сегодняшних сетевых средах, что они не дают успешного ping. Это очень жаль, так как ping всегда был одним из самых распространённых видов тестирования сетевых соединений, однако это реальность сегодняшнего дня. Если мы не можем полагаться на ping, в том, что он нам несомненно сообщит, можем ли связаться с удалённой системой, что нам делать вместо этого? Другой вариант, который я часто наблюдаю состоит в том, что некий сервер сам по себе может отвечать правильно, однако определённая работающая на этом сервере служба имеет проблемы и не отвечает. Простой ping показывает, что ваш сервер в рабочем состоянии, однако ничего не может сообщить нам об определённой его службе. Применяя команду клиента Telnet мы легко можем запрашивать сервер удалённо. Что ещё более важно, мы можем определить запрос индивидуальной службы на этом сервере, чтобы убедиться, что он прослушивает то, для чего он предназначен. Позвольте мне привести пример, который использую каждый раз. Я очень часто настраиваю новый веб- сервер, который развёрнут в Интернет. После установки нового веб- сервера, очень существенно, что я хотел бы проверить доступ к нему из Интернета, чтобы убедиться, что он отвечает, правильно? Однако, возможно у меня пока нет включённого и работающего вебсайта, поэтому я не могу просматривать его при помощи Internet Explorer. Достаточно вероятно, что у нас запрещён ping на данном сервере или на уровне межсетевого экрана, так как блокировка ICMP в Интернете достаточно распространена для уменьшения уязвимости безопасности опечатка в нашем Web. Поэтому мой новый сервер работает, и мы полагаем, что имеем наведённый порядок в своей сетевой среде, однако я не могу проверить пингованием свой новый сервер, так как согласно архитектуре он отказывает в откликах. Что я могу применить для тестирования? Telnet. Выполнив простую команду telnet, я могу попросить свой компьютер запросить определённый порт в своём новом веб- сервере и определить могу я соединиться с этим портом или нет. Выполнение сокетного установления соединения к данному порту на этом сервере во многом более похоже на действительный обмен пользователя чем то, что делал бы ping. Если команда telnet соединится успешно, вы знаете, что ваш выполненный таким образом обмен со своим сервером и что служба сервера, работающая с данным портом, который мы запросили, кажется отвечающей надлежащим образом.

Возможность Telnet не устанавливается по умолчанию в Windows Server 2016, или всех других операционных системах Windows, поэтому первое что нам необходимо сделать, это проследовать в менеджер сервера (Server Manager) Add Roles and Features чтобы установить своё свойство, называемое Telnet Client:

 

Рисунок 9

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

Теперь, когда свойство клиента Telnet установлено, мы можем применять его из командной строки или из PowerShell чтобы выполнять для нас работу, пытаясь устанавливать сокетные соединения с нашего компьютера к нашей удалённой службе. Всё что нам необходимо сделать, это сообщить ему какие сервер и порт опрашивать. Затем telnet будет просто соединяться или выходить по тайм- ауту и на основании этого результата мы сможем определять отвечает или нет определённая служба на этом сервере. Давайте попытаемся с нашим собственным веб- сервером. Для нашего примера я выключил свой вебсайт внутри IIS, поэтому мы теперь в положении, когда сервер сам по себе включён, однако вебсайт мёртв. Если делаю ping WEB1, я всё ещё вижу успешные отклики. Вы сможете увидеть, там где полагающиеся на ICMP инструменты мониторинга сервера могли бы здесь показывать здесь ошибочный результат, указывающий на то что сервер был включён и работал, даже хотя наш вебсайт был недоступен.

Даже несмотря на успешный отображённый ниже успешный ping, вы можете видеть, что я также попытался запросить порт 80 на своём сервере WEB1. Команда, которую я применил для этого: telnet web1 80. Она завершилась по тайм- ауту. Это указывает что наш вебсайт, который работает по порту 80, не отвечает:

 

Рисунок 10

Если я вернусь обратно и включу вебсайт назад, тогда мы можем попробовать telnet web1 80 вновь в этом случае я не увижу сообщения о таймауте. В этот раз моё приглашение PowerShell оставляет себя чистым и находится в ожидающем состоянии с мигающим курсором в верхней части. Хотя это и не говорит мне нечего навроде "Эй! я соединился" - такой мерцающий курсор показывает что было выполнено успешное сокетное соединение с портом 80 на моём веб- сервер, демонстрирующее, что данный веб- сервер включён и отвечает. {Прим. пер.: Если вам знаком язык запросов HTTP, вы даже можете сделать его в данной строке и получить ответ. Например:

GET /index.htm HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
 	   

С течением времени у вас может возникнуть потребность более глубоко погрузится в свои сетевые пакеты. Теперь мы входим на территорию, на которой могут быть задействованы и сетевые команды, однако, если вы знакомы с этими инструментами, вы будете в состоянии решить возникшие проблемы прежде чем вам понадобится сделать телефонный вызов консультанта. Применение инструментов командной строки для проверки состояния серверов или служб очень полезно, однако может оказаться недостаточным. Например, у вас имеется клиентское приложение, которое не может соединиться со своим сервером приложений, однако вы не понимаете почему. Вещи подобные ping и даже telnet могут успешно проверить соединение, что укажет на то, что маршрутизация установлена как следует, в то время как приложение отказывается соединяться при своём открытии. Если журнал событий владельца приложения не помогает в проведённом поиске неисправностей, вы можете пожелать заглянуть глубже вовнутрь своих сетевых пакетов, которые ваше приложение пытается пропихнуть в свой сервер. Это именно тот случай где на помощь приходят Wireshark и Netmon. Оба являются свободно распространяемыми, и оба выполняют в основном одни и те же функции. Они разработаны для перехвата сетевого обмена на его выходе или входе в систему, а также они перехватывают всю информацию, которая содержится внутри самих этих пакетов, поэтому вы можете заглянуть глубже в то что происходит. В нашем примере приложения, которое не может осуществить соединение, вы можете выполнить один из этих инструментов как на на клиентском компьютере для просмотра исходящего обмена, так и на сервере приложения для просмотра входящего обмена со стороны его клиента.

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

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

TCPView является инструментом, который изначально был создан SysInternals, вы должны были слышать что- то об их инструментах, таких как ProcMon и FileMon. Выполнение TCPView на машине отображает все активные соединения TCP и UDP происходящие на данном компьютере в реальном времени. Также важен тот факт, что у вас нет необходимости устанавливать что бы то ни было, для работы TCPView; он исполняется сам по себе, делая чрезвычайно простым применение и очищение машины после завершения работы с ним.

Вы можете загрузить его по адресу https://technet.microsoft.com/en-us/sysinternals/tcpview.aspx

Просто скопируйте этот файл на компьютер или сервер, который вы желаете подвергнуть мониторингу и дважды щёлкните по нему. Вот снимок экрана интерфейса TCPView, работающего на моём локальном компьютере, отображающим все соединения, которые выполняют в настоящий момент Windows и мои приложения. Вы можете остановить этот вывод чтобы вглядеться внимательнее, а также вы можете установить фильтры для подрезки части данных и поиска того, что вам действительно требуется. Фильтры позволяют освобождаться от "шума", так сказать, и позволить вам более пристально рассмотреть определённых получателей или особый идентификатор процесса:

 

Рисунок 11

Когда вы слышите термин "таблица маршрутизации", легко представить что это нечто, с чем должны иметь дело сетевые парни, что- то настраиваемое внутри сетевых маршрутизаторов и межсетевых экранов. Это не применяется сетевыми администраторами, верно? Сетевые серверы сообща были сделаны для нас достаточно простыми всего лишь требуя некоего IP адреса, маски подсети и шлюза по умолчанию, после чего мы моментально можем взаимодействовать со всем внутри остальной части нашей сетевой среды. Хотя в действительности и существует достаточно много сетевой магии, происходящей под капотом этого обмена, который предоставляется нам сетевым оборудованием и сетевыми администраторами, важно иметь представление о том, как работает маршрутизация внутри Windows, так как существуют некоторые примеры, когда вам необходимо изменять или выстраивать таблицу маршрутизации прямо в самом Windows Server. {Прим. пер., из личных воспоминаний: пожалуй, именно отсутствие внятных руководств по организации маршрутизации в Windows Server явилось тем, что подкосило Windows Compute Cluster Server на корню. Вечная память Кириллу Фаенову, тем не менее!}

Работа групповых (multihomed, многосетевых) серверов является тем случаем, когда вам несомненно следует понимать локальную таблицу маршрутизации Windows и работать с ней, поэтому давайте начнём здесь. Если вы полагаете, что это не относится к вам, так как вы никогда ранее не слышали о групповых серверах, подумайте об этом. Групповой это просто смешно звучащее слово, означающее, что у вашего сервера более одного NIC. Это несомненно может быть вашим случаем, даже если у вас всего лишь небольшой магазин и нет большого числа серверов. Во многих случаях малый бизнес или самые необходимые сервера имеют несколько сетевых интерфейсов, отделяющих внутренний обмен от обмена через Интернет. Другим экземпляром группового сервера может быть сервер удалённого доступа, который предоставляет DirectAccess, VPN или возможности прокси на одном конце вашей сетевой среды. Ещё одна причина, по которой следует заинтересоваться и изучить группирование это сервера Hyper-V. Для серверов Hyper-V очень распространено иметь множество NIC, так как все ВМ, которые работают на таком сервере могут нуждаться в подключению к различным физическим сетевым средам внутри вашей организации.

Теперь, когда мы установили что такое групповой сервер, просто сервер, который может иметь более одной сетевой карты, вы всё ещё можете удивляться зачем мы это обсуждаем. Если я имею более чем один NIC, не должен ли я просто настроить каждый NIC отдельно внутри Windows, предоставив каждому IP адрес, в точности так, как я это делаю для любого NIC во всех серверах? Да и нет. Да, вы должны настроить IP адрес для каждого NIC, так как он необходим для идентификации и транспорта пакетов в вашей сетевой среде. Нет, вы не настраиваете все имеющиеся NIC на своём сервере одновременно. Существует один критический элемент, который вы должны иметь в виду и придерживаться его чтобы заставить поток обмена работать надлежащим образом в своих групповом сервере.

Это ваш золотой билет. Когда ваш групповой сервер имеющий множество NIC, вы можете иметь только один шлюз по умолчанию. Один для всего сервера. Это означает, что у вас будет только один NIC с шлюзом по умолчанию, а также один или более NIC, которые НЕ имеют шлюз по умолчанию внутри своих настроек TCP/IP. Это чрезвычайно важно. Цель шлюза по умолчанию состоит в том, что он является путём последнего средства. Когда Windows хочет отослать пакет получателю, он просматривает локальную таблицу маршрутизации - да у вас существует таблица маршрутизации, даже если вы не настроили её или даже не видели её - и проверяет существует или нет определённый, статический маршрут для подсети назначения куда данный пакет должен поступить. Если маршрут существует, он выстреливает пакет в этот путь и сетевой интерфейс в его назначение. Если не существует статического маршрута в данной таблице маршрутизации, тогда он откатывает назад на применение шлюза по умолчанию и отправляет данный обмен на адрес этого шлюза по умолчанию. Во всех серверах с одним NIC шлюзом по умолчанию является маршрутизатор, который спроектирован со всей необходимой для вашей сетевой среды информацией о маршрутах и, таким образом, ваш сервер просто передаёт его в такой маршрутизатор и этот маршрутизатор выполняет всю оставшуюся работу.

Когда у нас имеется несколько NIC в Windows Server, мы не можем предоставить каждому из них шлюз по умолчанию, поскольку это сильно запутает поток обмена с вашего сервера. Это будет бесполезной стрельбой - на какой из шлюзов по умолчанию отправляется обмен потока при каждой сетевой передаче. Я помогал множеству людей разрешать проблему серверов на их площадке в точности с этой проблемой. Им необходимо было использовать свой сервер в качестве моста между двумя сетевыми средами или иметь сервер подключаемый ко множеству различных сетей по какой- либо имеющейся причине, а теперь они находятся в бедственном состоянии так как иногда обен кажется работающим, а иногда нет. Мы начинаем смотреть в свойствах NIC и обнаруживаем, что каждый NIC имеет свой собственный адрес шлюза по умолчанию в своих свойствах TCP/IP. Оп-ля-ля, вот наша проблема. Система полностью запутывается когда пытается отправлять обмен, так как она не знает какой шлюз ей применять в каком случае.

Если вы всё- таки пытаетесь добавить шлюзы по умолчанию к более чем одному NIC в одном и том же сервере, вы скорее всего знакомы с предупредительным сообщением, которое высвечивается когда вы это делаете. Давайте попробуем сделать это. Я добавил другой NIC в свои сервера и имею настройки IP только на одном NIC. Теперь я добавлю новый IP адрес, маску подсети и шлюз по умолчанию на свой второй NIC. Когда я кликаю кнопку OK, для сохранения этих изменений, мне предоставляется следующее сообщение:

 

Рисунок 12

Это одно из тех сообщений, которое запросто истолковать неправильно из- за его слегка шифрованной природы, однако вы осознали его сущность. Действуйте на свой риск! А потом, что большинство администраторов делают в подобном случае? Просто кликают через это и в любом случае сохраняют эти изменения. Затем начинаются проблемы маршрутизации. Может быть не сегодня, однако возможно при вашей следующей перезагрузке данного сервера, или, может быть, через три недели путешествия, однако в некоторый момент ваш сервер начнёт отсылать пакеты по неверному назначению и создаст у вас проблемы.

Итак, какой ответ на всё это? Постройте статическую таблицу маршрутизации. Когда у вас имеется множество NIC в некотором сервере с тем, чтобы сделать его групповым, вы должны сообщить Windows внутри таблицы маршрутизации какой NIC для какого обмена применять. Таким образом, когда сетевой обмен должен покидать ваш сервер в сторону определённого получателя, ваша таблица маршрутизации осведомлена о различных направлениях и путях, которые понадобится применить этому обмену чтобы попасть туда отправит его надлежащим образом. Вы всё ещё будете полагаться на маршрутизаторы, чтобы ваш обмен преодолел оставшийся путь, однако получение ваших пакетов на правильном маршрутизаторе путём отправки его на соответствующий физический NIC является ключом к тому, чтобы обмен протекал быстро и надлежащим образом из вашего группового сервера.

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

Добавление маршрута в командной строке

Прежде чем мы можем планировать свой новый маршрут, нам необходимо получить расклад текущих сетевых настроек данного сервера. Он имеет два NIC, причём один подключён в мою внутреннюю сетевую среду, а второй подключён к моей DMX, которая развёрнута лицом в сторону Интернета. Так как я могу иметь только один адрес шлюза по умолчанию, он идёт в сторону NIC DMZ, так как не существует способа, которым я мог бы добавлять маршруты для каждой подсети, которая должна соединяться через Интернет. Размещение своего шлюза по умолчанию в моём NIC DMZ означает, что внутренний NIC не имеет никакого шлюза по умолчанию и очень ограничен в том, с кем он может осуществлять контакт в данный момент. Моя внутренняя подсеть, к которой я физически подключён, это 10.0.0.0/24, поэтому я могу в настоящий момент с кем угодно в этой маленькой сетевой среде в диапазоне от 10.0.0.1 до 10.0.0.254. Однако я не могу контактировать с кем- либо ещё на данный момент через свой внутренний NIC, так как моя таблица маршрутизации ничего не знает о прочих подсетях, которые у меня есть внутри моей внутренней сетевой среды. У меня имеется дополнительная подсеть, а именно 192.168.16.0/24, и присутствует несколько серверов, работающих внутри этой подсети, с которыми мне нужна возможность осуществлять взаимодействие с моего этого нового настраиваемого сервера. Вот общий синтаксис выражения для маршрута, которому мы должны следовать, чтобы заставить этому обмену протекать с нашего сервера в его новую подсеть:

Route add –p <SUBNET_ID> mask <SUBNET_MASK><GATEWAY> IF <INTERFACE_ID>
 	   

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

В первых строках route print вы увидите перечисленными все свои NIC в системе. В нашем случае, внутренний NIC является самым первым в этом перечне, и вы можете увидеть, что он имеет идентификатор интерфейса с номером 4. Поэтому в моём выражении route add я собираюсь применить IF 4 в конце своего выражения чтобы гарантировать, что мой новый маршрут свяжет себя с этим физическим NIC.

Вот наше окончательное выражение route add:

Route add –p 192.168.16.0 mask 255.255.255.0 10.0.0.1 if 4
 	   

 

Рисунок 14

Всё ещё находясь в командной строке, если вы теперь выполните route print, вы сможете увидеть, что наш новый маршрут 192.168.16.0 перечислен в разделе Persistent Routes нашей таблицы маршрутизации, и мы можем отсылать пакеты в эту подсеть со своего нового сервера:

 

Рисунок 15

Удаление маршрута

Может случиться так, что вы ввели ключ в выражении маршрута неверно. Наилучший способ обработать это состоит в простом удалении этого плохого маршрута с последующим повторным выполнением вашего выражения route add с правильным синтаксисом. Могут существовать и другие причины почему нам нужно удалять маршруты всякий раз и поэтому вы захотите быть знакомым с данной командой. Удаление маршрута намного проще чем его добавление. Всё что вам нужно знать, это идентификатор вашей подсети для маршрута, который вы хотите удалить, и это всё. Затем просто route delete <SUBNET_ID>. Например, чтобы избавиться от нашего маршрута 192.168.16.0, который мы только что создали ранее пока мы работали внутри командной строки, я бы просто выполнил такую команду:

Route delete 192.168.16.0
 	   

Добавление маршрута при помощи PowerShell

Так как PowerShell является королём, когда дело доходит до наиболее ориентированных на командную строку задач внутри Windows Server, нам необходимо также выполнить ту же миссию из этого интерфейса. Вы можете применить ту же самую команду route add изнутри приглашения PowerShell и это будет работать просто превосходно, однако существует также специализированный cmdlet, которым мы можем воспользоваться вместо этого. Давайте применим New-NetRoute для добавления ещё другой подсети в свою таблицу маршрутизации, в этот раз мы собираемся добавить 192.168.17.0. Вот команда, которой мы можем воспользоваться:

New-NetRoute –DestinationPrefix "192.168.17.0/24" –InterfaceIndex 4 –NextHop 10.0.0.1
 	   

 

Рисунок 16

Вы можете заметить, что данная структура аналогична, однако слегка более дружественна. Вместо необходимости ввода слова mask и определения полного численного значения маски подсети, вы можете применить метод slash для идентификации своей подсети и маску внутри того же самого идентификатора. Кроме того, там где ранее мы определяли gateway, который всегда слегка вводил в заблуждение, при помощи cmdlet New-NetRoute мы вместо этого определяем то, что называется NextHop. Это слегка более понятно для меня.

А там, где мы ранее применяли route print чтобы просмотреть всю нашу таблицу маршрутизации, наш PowerShell cmdlet для отображения этой таблицы нам это просто Get-NetRoute:

 

Рисунок 17

Гибкость и эластичность облачных вычислений нельзя отвергать и большинство руководителей технологиями в настоящее время изучают свои возможности для применения облачных технологий. Одним из самых больших камней преткновения для внедрения является доверие. Облачные службы обеспечивают огромную вычислительную мощность доступную всю немедленно по нажатию кнопки, однако чтобы компании хранили свои данные в этих системах, должен быть очень высоким уровень доверия такой вашей организации имеющийся для подобного облачного поставщика решения. В конце концов, вы не являетесь владельцем оборудования и сетевой инфраструктуры, в которых располагаются ваши данные когда они находятся в таком облаке, и следовательно ваше управление этими ресурсами до некоторой степени ограничено. Видя подобный барьер, Microsoft предпринял множество усилий в последних обновлениях, чтобы привнести облачно- подобные технологии в локальный центр обработки данных. Введение эластичности сервера в наши центры обработки данных означает виртуализацию. Мы осуществляли виртуализацию самих серверов на протяжении многих лет до сих пор, хотя её возможности всё ещё улучшаются. Теперь, когда у нас имеется возможность раскручивать новые сервера так легко посредством технологий виртуализации, становится ясно, что следующим барьером будет наша способность легко перемещать эти виртуальные сервера повсеместно, где они нам только могут потребоваться.

Должен ли некий сервер, который вам нужен, переместиться в центр обработки данных через всю страну? Миграция всего центра обработки данных в новое место сосредоточения в городе? Возможно вы только что приобрели новую компанию и нуждаетесь в том, чтобы перенести её инфраструктуру в свою сетевую среду, однако должны перекрыть сетевые конфигурации. Приобрели ли вы ранее некоторое пространство у поставщика облачных услуг, а теперь пытаетесь продраться через беспорядок планирования миграции всех ваших серверов в конкретное облако? Все эти вопросы требуют ответа, и ответ этот состоит в Программно определяемых сетевых средах (SDN, Software-Defined Networking).

SDN обширен, это общий термин, покрывающий многие совместно работающие технологии, которые делают возможной данную идею. Его цель состоит в расширении границ вашей сетевой среды всякий раз и везде где это вам может понадобиться. Давайте взглянем на некоторые части и и фрагменты доступные в Windows Server 2016, которые работают в тандеме для создания виртуальной сетевой среды, причём начнём с освоения нашей идеологии Программно управляемых сетевых сред.

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

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

Частные облака

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

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

Чтобы предоставить частное облако внутри вашей инфраструктуры, в особенности когда вы хотите предоставить доступ множеству арендаторов, становятся очевидными преимущества сетевой виртуализации, более того, она обязательна. Скажем, вы предоставляете ресурсы двум подразделениям какой- либо компании, и каждое из них имеет собственные потребности для размещения неких веб- серверов. Не самое важное дело, однако оба этих подразделения имеют команды администраторов, которые желают применять схемы внутри 10.0.0.0. Им обеим необходима доступность одних и тех же IP адресов, причём в одном и том же ядре предоставляемой вами сетевой среды, а вам при этом ещё и требуется сохранить весь их обмен полностью выделенным и раздельным. Это было ночным кошмаром при наличии только физической сетевой среды, однако при применении мощности сетевой виртуализации вы легко можете обеспечить подсети и схемы адресации IP любого выбранного таким подразделением размера. Они могут запускать сервера в любых угодных им подсетях и с любыми нужными им IP адресами, причём при этом весь обмен уникально инкапсулируется с тем, чтобы оставаться отдельным, полностью не ведающем о прочем обмене, происходящем в том же самом физическом ядре сетевой среды, работающем ниже вашего уровня виртуализации. Такой сценарий также играет очень хорошую роль при приобретениях корпораций. Две объединяющие на уровне ИТ усилия компании обычно вступают в конфликт в отношении настроек доменов и подсетей. При использовании сетевой вируализации вы можете позволить существующей инфраструктуре и серверам продолжать работу с их текущей настройкой сетевой среды, однако вводить их вовнутрь одной и той же физической сетевой среды употребляя сетевую виртуализацию Hyper-V.

Другой более простой пример состоит в том, что вы просто желаете переместить сервер внутри сети корпорации. Возможно у вас имеется унаследованный по линии бизнеса сервер, который всё ещё нужен для доступа множеству сотрудников, так как их ежедневная рабочая нагрузка включает постоянно работающее приложение Больших объектов. Проблема с перемещением такого сервера состоит в том, что ваше приложение Больших объектов в компьютерах ваших клиентов имеет статический IPv4 адрес, настроенный на взаимодействие с данным сервером. Когда пользователь открывает своё приложение, он выполняет нечто вроде "обращения к серверу по адресу 10.10.10.10". Традиционно это может приводить к связанному с этим отключением такого сервера, так как перемещение этого сервера из его текущего центра обработки данных в новое местоположение означало бы изменение IP адреса такого сервера, а это было бы отключением у всех возможности связываться с ним. При использовании виртуальных сетевых сред это вовсе не является проблемой. При наличии возможности прогонять сетевой обмен и подсети IP на своём виртуальном уровне, подобный сервер может быть перемещён из Нью Йорка в Сан Диего и сохранить все свои настройки адресов IP, так как работающая в его основании физическая среда совсем не играет никакой роли. Весь этот обмен инкапсулируется перед своей отправкой в вашу физическую сетевую среду, поэтому ваш IP адрес наследуемого сервера может продолжать оставаться 10.10.10.10, причём он может быть закреплён и перемещён куда угодно в вашей среде без прерывания.

Гибридные облака

Хотя предоставление гибкости вашим корпоративным сетевым средам уже гигантское преимущество, возможность предоставления виртуализации ваших сетевых сред расширяются экспоненциально когда вы действительно окончательно решите начать углубляться в действительные облачные ресурсы. Когда и где вам придётся принять решение переместить некоторые ресурсы для размещения к поставщику общедоступных облачных услуг, скорее всего вы будете работать в гибридной среде. Это означает, что будете строить те же самые службы в своём облаке, однако при этом вы также оставите некоторые серверы и службы на площадке. По крайней мере на какое- то время, хотя я и предвижу, что большая часть компаний останется в сценарии гибридного облака всю оставшуюся вечность, так как 100% перемещение в облако просто невозможно по причинам, которыми многие компании ведут дела. Поэтому теперь, когда вы хотите настроить гибридное облако, мы вновь наблюдаем все виды приключений на одно место, связанные с перемещением ресурсов между нашими физическими и облачными сетевыми средами. Когда я хочу переместить сервер со своей площадки в своё облако, я должен настроить всё таким образом, чтобы сетевые конфигурации были бы совместимы с облачной инфраструктурой, верно? Какой бы ни была выделенная мне подсеть IP? Это не так - если у вас имеется поднятая и работающая инфраструктура виртуальной сетевой среды. Опять- таки, поскольку весь ваш обмен инкапсулируется перед отправкой, предоставляемая в вашем облаке физическая сетевая среда не должна быть совместимой или отличаться от нашей виртуальной сетевой среды, и это предоставляет нам возможность бесшовного перемещения сервера туда и обратно в пределах вашего облака без необходимости выполнения специальных приспособлений для сетевой среды.

Как это работает?

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

Менеджер виртуальных машин системного центра

Системный центр (System Center) Microsoft является ключевым местом всего пазла для создания вашей модели Программно- управляемой сетевой среды, в особенности такой компонент Системного центра, как Менеджер виртуальных машин (VMM, Virtual Machine Manager). Возможность прихватывания IP адреса и перемещения его в другие местоположения по всему миру требует некоторой координации ваших сетевых устройств и здесь приходит на помощь VMM. Это компонент, который является вашим интерфейсом с вашим центральным пунктом управления для определения и настройки ваших виртуальных сетевых сред. Системный центр является гигантским предметом со множеством параметров и опорными координатами, которые не поместятся в этой книге, которую вы сейчас читаете, поэтому я оставлю вам ссылку в качестве отправной точки для изучения VMM: https://technet.microsoft.com/en-us/library/gg610610.aspx {Прим. пер.: более корректно https://technet.microsoft.com/system-center-docs/vmm/vmm.}

Сетевой контроллер

Сетевой контроллер (Network Controller) Microsoft является новой ролью в Windows Server 2016 и, как на то указывает его название, применяется для управления сетевыми ресурсами внутри вашей организации. В большинстве случаев он будет работать параллельно с VMM чтобы выполнить по мере возможностей централизацию и бесшовность сетевых настроек. Сетевой контроллер имеет обособленную роль и может устанавливаться на Server 2016 и затем предоставлять доступ напрямую, без посредничества VMM, однако я не предвижу большого числа применений оставляющих дело таким образом. Взаимодействие с Сетевым контроллером напрямую возможно при подключении к его API с помощью PowerShell, однако это сделать гораздо лучше путём добавления графического интерфейса из которого вы настраиваете новую модель сетевой среды. Таким графическим интерфейсом, который можно применять, является VMM Системного центра.

Сетевой контроллер может применяться для настройки множества различных сторон ваших виртуальных и физических сетевых сред. Вы можете настраивать подсети IP и адреса, конфигурации и VLAN в коммутаторах Hyper-V, а также вы даже можете создавать и управлять типом правил ACL (Access Control List, Списком управления доступа) внутри коммутатора Hyper-V, так что на этом уровне вы можете строить ваши собственные решения межсетевого экранирования, без какой- бы то ни было необходимости настройки локальных межсетевых экранов в самой конкретной ВМ или наличия выделенного оборудования межсетевого экрана. Сетевой контроллер может даже применяться для настройки балансировки нагрузки и предоставления VPN доступа через серверы RRAS.

GRE

GRE (Generic Routing Encapsulation, Инкапсуляция общей маршрутизации) просто является протоколом туннелирования, однако крайне важным для того чтобы сетевая виртуализация проходила успешно. Ранее, когда мы обсуждали повсеместное перемещение подсетей IP и то, как вы можете размещать виртуальные сети поверх физических сетевых сред без беспокойства о том, чтобы их IP настройки были совместимы, вся эта функциональность предоставлялась в основном через GRE.

Когда ваша физическая сетевая среда работает с 192.168.0.x, однако вы желаете размещать некоторые ВМ в подсети этого центра обработки данных, вы можете создать виртуальную сетевую среду 10.10.10.x без каких- либо проблем, однако этот обмен должен быть осуществляться через вашу физическую сеть 192.168 чтобы всё работало. Это то место, в котором в игру вступает инкапсуляция маршрутизации. Все пакеты из сетевой среды 10.10.10.x инкапсулируются перед передачей по вашей физической сетевой среде 192.168.0.x.

Существует два различных определённых протокола инкапсуляции маршрутизации, которые поддерживаются в нашей среде сетевой виртуализации Microsoft Hyper-V. В предыдущих версиях операционной системы Windows Server мы могли сосредоточиться только на NVGRE (Network Virtualization Generic Routing Encapsulation, Инкапсуляции общей маршрутизации виртуальной сети), так как это был единственный протокол, поддерживавшийся предпочтением сетевой виртуализации Windows. Однако существует другой протокол, называемый VXLAN (Virtual Extensible Local Area Network, Виртуально расширяемые локальные сети), который существовал определённое время и многие из сетевых коммутаторов - в особенности Cisco - которые имеются в вашей среде скорее всего поддерживают VXLAN нежели NVGRE. Поэтому для новых платформ сетевой виртуализации предоставляемых в рамках Windows Server 2016 мы теперь в состоянии поддерживать либо NVGRE, либо VXLAN, то что лучше соответствует потребностям вашей компании.

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

Виртуальная сеть Microsoft Azure

Раз у вас имеется сетевая виртуализация Hyper-V, работающая внутри вашей корпоративной сетевой среды и предоставляющая вам удобство в представлении отдельно ваших физических и виртуальных сетевых сред, вы скорее всего пожелаете изучить возможности связанные с взаимодействием с сетевыми средами предоставляющими облачные службы. Когда вы применяете Microsoft Azure в качестве поставщика облачных служб, у вас имеется возможность строить гибридные облачные среды которые наводят мосты между вашими внутренними физическими сетями и удалёнными виртуальными сетевыми средами, хранящимися в Azure. Сетевая среда Azure является компонентом внутри Azure, который делает возможным для вас привносить ваши собственные IP адреса и подсети в ваше облако. Вы можете получить некоторую дополнительную информацию и даже подписаться на бесплатную пробную виртуальную сетевую среду Azure здесь: https://azure.microsoft.com/en-us/services/virtual-network/.

Шлюз Windows Server

Когда вы работаете с физическими сетевыми средами, виртуальными сетями, а теперь ещё и виртуальными сетевыми средами которые хранятся в облачных окружениях, вам необходим компонент для наведения мостов над этими промежутками, чтобы сделать возможным взаимодействовать и обмениваться информацией этим сетевым средам дуг с другом. Это то поле, на котором вступает в игру Шлюз (Gateway) Widows Server.

Шлюз Windows Server является новым термином для этого фрагмента, который ранее, а иногда и теперь, всё ещё называется Шлюзом сетевой виртуализации (Network Virtualization Gateway) Hyper-V, поэтому вы также можете обращаться и к такой документации. Цель Шлюза Widows Server достаточно проста, быть соединением между виртуальными и физическими сетевыми средами. Эти виртуальные сетевые среды могут размещаться в вашей локальной среде, или располагаться в вашем облаке. В любом случае, когда вы хотите соединить сетевые среды вместе, вам необходимо задействовать Шлюз Windows Server. Когда вы создаёте мост между внутренней сетью и облаком, ваш поставщик облачной службы будет использовать некий шлюз на своей стороне, к которому вы должны подключиться из своей физической сетевой среды через тунель VPN.

Шлюз Windows Server обычно является виртуальной машиной и интегрирован с Сетевой виртуализацией Hyper-V. Отдельный Шлюз может применяться для маршрутизации обмена для многих различных пользователей, арендаторов или подразделений. Даже если эти различные пользователи имеют раздельные сетевые среды которые должны продолжать оставаться отдельными от обмена прочих пользователей, поставщиков облачных услуг, общедоступных или частных, всё ещё можете продолжать применять единый Шлюз для управления этим обменом, так как шлюзы остаются полностью изолированными между этими потоками обмена.

Администрирование серверов и сетевое администрирование довольно чётко используются как разделённые в большинстве организаций, однако со временем эта линия разграничения размывается. Существует множество сетевых конфигураций и задач, которые теперь необходимо выполнять администраторам Windows Server, без какой бы то ни было необходимости привлекать сетевые команды, поэтому важно чтобы у вас было хорошее понимание как ваша инфраструктура соединяется воедино. Знакомство с инструментами, приведёнными в данной главе предоставит вам способность настраивать, мониторить и осуществлять поиск основных неисправностей сетевых сред вокруг Microsoft.

Наше введение в Программно определяемые сетевые среды может быть слегка сбивающим с толку разделом, если вы никогда ранее не встречались с этой идеей, однако будем надеяться что она укажет вашей любознательности углубиться слегка больше и подготовить себя для работы с этим в будущем. Облако уже здесь, хотите вы того или нет, а иногда исполнительские решения впихивают их в наши среды быстрее чем мы хотели бы чтобы это произошло с точки зрения безопасности ИТ. В последующие годы идея SDN будет продолжать расти в популярности, она является одним из тех моментов, который может казаться неизвестным и обескураживающим, однако через пять лет мы все сможем оглянуться назад и удивиться как мы могли выполнять свою работу без виртуальных сетевых сред. Существует гораздо больше информации в TechNet и в опубликованных книгах про виртуальные сетевые среды Hyper-V и VMM Системного центра. Я рекомендую погрузиться глубже в эти материалы если интересуетесь этим и пытаетесь это применять для себя.