По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой серии статей мы рассмотрим поиск и устранение неисправностей NAT (трансляции сетевых адресов) / PAT (трансляции адресов портов), DHCP и FHRP (протоколы избыточности при первом переходе).
NAT/PAT может быть проблемным, и не потому, что настройка несколько сложна (хотя и в этом тоже могут быть проблемы). Но в основном потому, что мы можем столкнуться с проблемами маршрутизации, так как мы периодически меняем IP-адреса. Во второй части этой серии мы рассмотрим наиболее распространенные проблемы DHCP и, наконец, закончим серию статей некоторыми проблемами FHRP.
Урок 1
В этом сценарии у нас есть 3 устройства. Маршрутизатор с левой стороны называется "Хост", и он представляет компьютер из нашей локальной сети. Предполагается, что устройство с правой стороны - это какой-то веб-сервер - это то, что мы пытаемся найти в Интернете. В середине мы видим наш маршрутизатор, который настроен для NAT и/или PAT.
Пользователи из нашей локальной сети жалуются на то, что они ничего не могут найти в Интернете. Они подтвердили, что их IP-адрес и шлюз по умолчанию в порядке. Давайте изучим маршрутизатор NAT:
Хорошая идея, чтобы проверить, может ли маршрутизатор NAT достичь веб-сервера, попробовав простой пинг. Если это не работает, вы, по крайней мере, знаете, что у вас есть проблемы с маршрутизацией или, что веб-сервер не работает (или, возможно, просто блокирует ICMP-трафик).
Поскольку это веб-сервер, лучше попробовать подключиться к TCP-порту 80. Вы видите, что это работает, так что маршрутизация между маршрутизатором NAT и веб-сервером + подключение к TCP-порту не является проблемой.
Мы можем использовать команду show ip nat translations, чтобы увидеть, происходит ли что-нибудь. Мы видим, что NAT-маршрутизатор что-то транслирует, но если вы посмотрите внимательно, то увидите, что это выглядит не совсем правильно. Внешние локальные и глобальные IP-адреса ссылаются ко внутреннему IP-адресу. Давайте посмотрим на конфигурацию ...
show ip nat statistics - хорошая команда для проверки вашей конфигурации. Вы можете видеть, что внутренние и внешние интерфейсы поменялись местами. FastEthernet 0/0 должен быть inside, а FastEthernet 1/0 должен быть outside.
NAT(config)#interface fastEthernet 0/0
NAT(config-if)#ip nat inside
NAT(config)#interface fastEthernet 1/0
NAT(config-if)#ip nat outside
Введем команды, которые позволяют исправить настройки, чтобы у нас были правильные внутренние и внешние интерфейсы.
Трафик с хоста на веб-сервер теперь работает!
Вот как должна выглядеть таблица трансляции NAT. Внутренний локальный IP-адрес - наш внутренний хост. Внутренний глобальный IP-адрес - это то, что мы настроили на внешней стороне нашего маршрутизатора NAT (FastEthernet 1/0). Внешний локальный и глобальный IP-адрес - наш веб-сервер ... проблема решена!
Итог урока: убедитесь, что у вас имеются правильные внутренние и внешние интерфейсы.
Урок 2
Та же топология, другая проблема! Опять пользователи нашей локальной сети жалуются, что они не могут связаться с веб-сервером. Давайте проверим наш маршрутизатор NAT:
NAT#show ip nat translations
Сначала мы проверим, транслирует ли маршрутизатор что-либо. Как видите, тихо ничего не происходит!
Мы убедились, что внутренний и внешний интерфейсы были настроены правильно. Однако никаких трансляций не происходит. Внутренний источник был определен с помощью списка доступа 1. Давайте поближе рассмотрим этот ACL:
Ааа, смотрите ... кажется, кто-то испортил ACL! Устраним эту неполадку:
NAT(config)#no access-list 1
NAT(config)#access-list 1 permit 192.168.12.0 0.0.0.255
Мы создадим ACL так, чтобы он соответствовал 192.168.12.0/24.
Теперь мы можем связаться с веб-сервером с нашего хоста.
Мы видим Hits, если просмотреть NAT statistics.
И я вижу трансляцию ... проблема решена!
Итог урока: убедитесь, что вы используете правильный список доступа, соответствующий вашим внутренним хостам.
Теперь почитатей продожение статьи про устранение неисправностей с DHCP.
По умолчанию, в Windows Server 2019 брандмауэр настроен на блокировку входящего трафика ICMP. Сюда входят эхо-запросы, которые используются командой ping, и это может затруднить устранение неполадок в сети. Некоторые системы мониторинга используют команду ping для отслеживания доступности серверов.
В этом руководстве рассмотрим, как включить правило, чтобы сервер стал отвечать на ping используя графический интерфейс Windows Server 2019, а также включим разрешающее правило через PowerShell и netsh.
Обычно просто отключают Windows Firewall полностью, однако это не рекомендуется делать в производственной среде, так как брандмауэр Windows хорошо справляется с обеспечением базового уровня защиты системы. Разрешим только конкретное правило, необходимое для успешного выполнения команды ping.
Разрешить проверку связи через брандмауэр Windows
Сначала нам нужно открыть брандмауэр Windows, это можно сделать несколькими способами. Один из методов - просто нажать клавишу Windows, чтобы открыть меню "Start", а затем начать вводить слово Firewall. Как показано ниже, брандмауэр Windows с расширенной безопасностью должен отображаться, выберите этот пункт.
Еще один быстрый способ: в PowerShell можно просто ввести "firewall" и нажать Enter. Откроется базовый интерфейс брандмауэра, а затем нажать кнопку "Advanced settings" в левой части. Откроется тот же интерфейс, что и через меню "Start".
Следующий способ открыть Firewall - ввести в CMD такой текст: "firewall.cpl"
В Брандмауэре в расширенном режиме перейдите в Inboud Rules (Правила для входящих подключений).
В перечне правил в Inboud Rules, найдите "File and Printer Sharing (Echo Request - ICMPv4-In)" и активируйте его.
Еще один вариант. Активируем разрешающее правило командлетом Powershell
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True
Полную справку со всеми параметрами можно получить, набрав команду в PowerShell
help New-NetFirewallRule
Вариант создания правила через netsh
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
Примечание: Включение правила позволит получать ответы только на IPv4 запросы, если нужно получать ответы по IPv6, нужно разблокировать правило такое же правило, только с Echo Request - ICMPv6-In, перечисленное ниже. К тому же имеется несколько профилей: доменный, публичный, частный. Ненужные профили можно отключить в правиле, во вкладке Advanced.
После разблокировки правила сервер должен начать отвечать на запросы ping. С хоста виртуализации или другого пк в локальной сети протестируем ping'ом Windows Server 2019 по адресу 192.168.1.11 перед включением правила, а затем снова после его включения. Ниже видно, что время ожидания первых запросов истекло, так как входящие запросы ICMP были отключены по умолчанию в Windows Server 2019. После включения правила ICMP запросы ping успешно выполняются, что подтверждает ожидаемую работу.
Пример проверки связи:
Скачать видео.
Резюме
Стандартное правило брандмауэра - блокировать ICMP запросы, в итоге сервер не отвечает на ping. Включив это правило брандмауэра, мы включили команду ping в Windows Server 2019, которая поможет нам устранить неполадки в сети.
Почитайте предыдущую статью про безопасность передачи данных.
Некоторые из самых ранних криптографических систем включали обертывание бумагой цилиндра определенного размера. Цилиндр должен был каким-то образом переноситься между двумя участниками зашифрованной связи, чтобы противник не захватил его. В более поздние годы блоки ключей физически переносились между двумя конечными точками зашифрованной системы. Некоторые из них были организованы таким образом, чтобы определенная страница использовалась в течение определенного периода времени, а затем вырывалась и уничтожалась, заменена новой страницей на следующий день. Другие были разработаны таким образом, чтобы каждая страница в блокноте использовалась для шифрования одного сообщения, после чего страница вырывалась и заменялась одноразовым блокнотом.
Концепция одноразового блокнота была перенесена в современный мир с системами аутентификации, которые позволяют пользователю создавать код, который используется один раз, а затем отбрасывается, чтобы быть замененным новым кодом в следующий раз, когда пользователь попытается аутентифицироваться. Любая система, использующая код, который используется один раз, по-прежнему называется одноразовым блокнотом (one-time pad).
В современном мире есть другие способы обмена криптографическим материалом, будь то использование общего секретного ключа или получение закрытого ключа.
Во многих случаях в криптографии легче объяснить, как что-то работает, на тривиальных примерах. В следующих пояснениях Фаина и Дима будут двумя пользователями, которые пытаются обмениваться защищенной информацией, причем Фаина является инициатором и отправителем, а Дима - получателем.
Обмен публичными ключами
Фаина хотела бы отправить сообщение Диме таким образом, чтобы его мог прочитать только Дима. Для этого ей нужен открытый ключ Димы (помните, что у нее не должно быть доступа к закрытому ключу Димы). Где она может получить эту информацию? Она могла:
Спросить об этом у Димы напрямую. Это может показаться простым, но в реальной жизни это может быть очень сложно. Как, например, она может быть уверена, что действительно общается с Димой?
Найти открытый ключ Димы в открытой базе данных ключей (на сервере ключей). Опять же, это кажется простым, но как она узнает, что нашла нужный ключ или кто-то не разместил ложный ключ для Димы на этом конкретном сервере?
Эти две проблемы можно решить с помощью какой-то системы репутации. Например, в случае открытого ключа Дима может попросить нескольких своих друзей, которые хорошо его знают, подписать его открытый ключ, используя свои закрытые ключи. Их подпись на его открытом ключе, по сути, гласит: "Я знаю Дмитрия, и я знаю, что это его открытый ключ". Фаина может изучить этот список друзей, чтобы определить, кому из них она может доверять. Основываясь на этом исследовании, Фаина может определить, что она либо верит, что этот конкретный ключ является ключом Димы, либо нет.
В этой ситуации Фаина сама решает, сколько и какого рода доказательств она примет. Должна ли она, например, признать, что ключ, который у нее есть, на самом деле принадлежит Диме, потому что:
Она напрямую знает одного из друзей Димы и верит, что этот третий человек скажет ей правду.
Она знает кого-то, кто знает одного из друзей Димы, и доверяет своему другу, чтобы он рассказал ей правду о друге Димы, и, следовательно, доверяет другу Димы рассказать правду о Диме и его ключе.
Она знает нескольких человек, которые знают нескольких друзей Димы, и принимает решение доверять этому ключу Димы, основываясь на свидетельствах нескольких человек.
Такая система называется паутиной доверия. Общая идея заключается в том, что доверие имеет разные уровни транзитивности. Концепция транзитивного доверия несколько противоречива, но идея, лежащая в основе сети доверия, заключается в том, что, если вы получаете достаточно доказательств, вы можете создать доверие в паре человек/ключ. Примером такого рода паутины доверия является система Pretty Good Privacy, где люди встречаются на конференциях, чтобы перекрестно подписывать ключи друг друга, создавая паутину транзитивных доверительных отношений, на которые можно положиться, когда их общение переходит в сферу только электронных.
Другой вариант - владелец сервера ключей может каким-то образом провести расследование в отношении Дмитрия и определить, действительно ли он тот, кем он себя выдает, и действительно ли это его ключ. Самый яркий пример такого решения в "реальном мире" - это нотариус. Если вы подписываете документ перед нотариусом, он проверяет наличие какой-либо формы удостоверения личности (подтверждающей, кто вы), а затем наблюдает, как вы физически подписываете документ (проверяя ваш ключ).
Этот вид проверки называется центральным источником доверия (или аналогичным - хотя в нем почти всегда есть слово "централизованный") или инфраструктурой открытого ключа (Public Key Infrastructure -PKI). Решение зависит от доверия Фаины процессу и честности централизованного хранилища ключей.
Обмен закрытыми ключами
Учитывая, что криптография с симметричным ключом обрабатывается намного быстрее, чем криптография с открытым ключом, в идеале вы хотели бы зашифровать любые давно существующие или большие потоки с использованием симметричного общего секретного ключа. Но, если не считать физического обмена ключами, как можно обмениваться одним закрытым ключом между двумя устройствами, подключенными по сети? Рисунок 1 демонстрирует это.
На рисунке выше:
Предположим, А начинает процесс. A зашифрует одноразовый номер, случайное число, которое используется один раз в процессе, а затем выбрасывается (по сути, одноразовый номер представляет собой форму одноразового блокнота), используя открытый ключ B. Поскольку одноразовый номер был зашифрован с помощью открытого ключа B, теоретически только B может расшифровать одноразовый номер, поскольку только B должен знать закрытый ключ B.
B, после расшифровки одноразового номера, теперь отправит новый одноразовый номер в A. Он может включать исходный одноразовый номер A или исходный одноразовый номер A плюс некоторая другая информация. Дело в том, что A должен точно знать, что исходное сообщение, включая одноразовый номер A, было получено B, а не какой-либо другой системой, действующей как B. Это обеспечивается B, включая некоторую часть информации, которая была зашифрована с использованием его открытого ключа, поскольку B - единственная система, которая могла его расшифровать.
A и B, используя одноразовые номера и другую информацию, обмениваемую до этого момента, вычисляют закрытый ключ, который затем используется для шифрования / расшифровки информации, передаваемой между двумя системами.
Описанные здесь шаги несколько наивны. Есть лучшие и более безопасные системы, такие как протокол Internet Key Exchange (IKE).