Можно ли использовать глобальные IP-адреса без Интернета?

Question 1

Это абсолютно возможно - в пространстве IPV4 нет ничего магического, и все работает одинаково. Головные боли приходят много лет спустя, когда эта сеть интегрируется в Интернет.

Answer

Это абсолютно возможно - в пространстве IPV4 нет ничего магического, и все работает одинаково. Головные боли приходят много лет спустя, когда эта сеть интегрируется в Интернет.

Question 2

Да, это возможно, но не рекомендуется.

Вместо этого вам следует использовать блоки, выделенные RFC1918, и небольшую сеть, насколько это возможно. Избегайте использования 10.0.0.0/8 для вашей домашней сети с несколькими устройствами.

Более подробная информация наhttps://www.rfc-editor.org/rfc/rfc1918и его заменаhttps://www.rfc-editor.org/rfc/rfc6761

Хорошим правилом является использование размера сети в 4 раза больше максимального количества устройств, которые вы можете запустить в этой сети, или /24 (254 хоста), в зависимости от того, что больше. /24 также упрощает подсети.

Поэтому используйте 10.вашномерулицы.вашгодрождения.0 или 192.168.вашроствсм.0 Будьте креативны!

Если вы планируете создать VPN-соединение типа «сеть-сеть», рассмотрите в качестве кандидата диапазон 172.16–31.0.0, поскольку он немного более запутан и поэтому используется реже.

Другая причина не использовать существующий публичный диапазон заключается в том, что кэширование DNS может испортить устройства, которые меняют сети. Ноутбуки, телефоны и планшеты IE могут кэшировать "dns.google.com" как 8.8.8.8 и продолжать использовать эту запись после подключения к вашей локальной сети. Или кто-то уходит домой, а ваше имя хоста "fileserver.local", разрешающееся в 8.8.8.8, может кэшироваться вплоть до TTL записи.

Пример глупого повторного использования IP-адресов. Во времена VMware Workstation я пытался использовать 127.99.99.0/24 в качестве IP-сети, поскольку он был более специфичным, чем 127.0.0.0/8, применяемый к интерфейсам обратной связи.

Это работало идеально для vmware и для linux VM. Но windows (xp?) сказал "Стоп, нет", как только вы указали 127 в качестве первого октета IP-адреса. Я никогда не пробовал выделять IP-адреса через DHCP в то время.

Вероятность непредвиденных последствий огромна.

И иногда, редко, классовая сеть портит вас. Я использовал сеть 192.168.0.0/16, и в ней много всего успешно сосуществовало: Windows 95, XP, NT4, Linux, Mac, принтеры и т. д.

Затем мы получили несколько точек доступа Linksys WRT54GL, и они не принимали сетевую маску больше /24 при использовании с 192.168. Это потому, что изначально 192.168.0.0 был определен как

256 смежных сетей класса C

Поэтому сеть должна была быть 256 хостов или меньше. Это появлялось только с некоторыми комплектами linksys, а флэш с OpenWRT с удовольствием использовал полную сеть /16.

Вывод из этого таков: /24 более чем достаточно для большинства пользователей. /8 или /16 слишком велики.

Answer

Да, это возможно, но не рекомендуется.

Вместо этого вам следует использовать блоки, выделенные RFC1918, и небольшую сеть, насколько это возможно. Избегайте использования 10.0.0.0/8 для вашей домашней сети с несколькими устройствами.

Более подробная информация наhttps://www.rfc-editor.org/rfc/rfc1918и его заменаhttps://www.rfc-editor.org/rfc/rfc6761

Хорошим правилом является использование размера сети в 4 раза больше максимального количества устройств, которые вы можете запустить в этой сети, или /24 (254 хоста), в зависимости от того, что больше. /24 также упрощает подсети.

Поэтому используйте 10.вашномерулицы.вашгодрождения.0 или 192.168.вашроствсм.0 Будьте креативны!

Если вы планируете создать VPN-соединение типа «сеть-сеть», рассмотрите в качестве кандидата диапазон 172.16–31.0.0, поскольку он немного более запутан и поэтому используется реже.

Другая причина не использовать существующий публичный диапазон заключается в том, что кэширование DNS может испортить устройства, которые меняют сети. Ноутбуки, телефоны и планшеты IE могут кэшировать "dns.google.com" как 8.8.8.8 и продолжать использовать эту запись после подключения к вашей локальной сети. Или кто-то уходит домой, а ваше имя хоста "fileserver.local", разрешающееся в 8.8.8.8, может кэшироваться вплоть до TTL записи.

Пример глупого повторного использования IP-адресов. Во времена VMware Workstation я пытался использовать 127.99.99.0/24 в качестве IP-сети, поскольку он был более специфичным, чем 127.0.0.0/8, применяемый к интерфейсам обратной связи.

Это работало идеально для vmware и для linux VM. Но windows (xp?) сказал "Стоп, нет", как только вы указали 127 в качестве первого октета IP-адреса. Я никогда не пробовал выделять IP-адреса через DHCP в то время.

Вероятность непредвиденных последствий огромна.

И иногда, редко, классовая сеть портит вас. Я использовал сеть 192.168.0.0/16, и в ней много всего успешно сосуществовало: Windows 95, XP, NT4, Linux, Mac, принтеры и т. д.

Затем мы получили несколько точек доступа Linksys WRT54GL, и они не принимали сетевую маску больше /24 при использовании с 192.168. Это потому, что изначально 192.168.0.0 был определен как

256 смежных сетей класса C

Поэтому сеть должна была быть 256 хостов или меньше. Это появлялось только с некоторыми комплектами linksys, а флэш с OpenWRT с удовольствием использовал полную сеть /16.

Вывод из этого таков: /24 более чем достаточно для большинства пользователей. /8 или /16 слишком велики.

Question 3

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

Допустим, вы управляете компьютером и можете задать его IP-адрес. И вот вы вводите IP-адрес 8.8.8.8. Вы можете это сделать? Да.

Теперь «маршрутизация» может быть проблемой (о чем я собираюсь рассказать в более поздней части этого ответа). Однако, могут быть способы обойти это. Итак, предположим, что удаленный конец связался с вашим сервером ICMP и выполнил «ping 8.8.8.8». Ответит ли ваш сервер ICMP (обычно встроенный в программные компоненты «стека TCP/IP»)? Да. Никаких проблем.

Допустим, вы запускаете сервер на этом компьютере, например DNS-сервер. Если бы на вашем компьютере был запущен DNS-сервер и он получил ответ, мог бы он ответить и все бы работало? Да. Никаких проблем.

Допустим, вы запускаете HTTP-сервер. Если другой компьютер открыл веб-браузер и в итоге связался с вашим компьютером с IP-адресом, то сможет ли ваш компьютер ответить и все ли заработает? Эм... ну... раньше ответ был "Да". Но теперь все стало немного сложнее из-за HPKP. Для получения более подробной информации см.Веб-страница Википедии о закреплении открытого ключа HTTP]. Так что это может не сработать так уж хорошо. Подводя итог: популярные веб-браузеры посчитали это стилем атаки и поставляли некоторые сведения о надлежащих сертификатах/соединениях HTTPS для некоторых из ведущих сайтов мира. Другой связанной техникой может быть «предварительная загрузка HSTS», которая связана с HSTS («HTTP Strict Transport Security»). Так что, когда люди устанавливают современные версии веб-браузеров, эти браузеры могут поставляться с некоторыми сведениями о некоторых веб-сайтах. Если ваш поддельный сайт «Google» не соответствует ожиданиям, браузер может вмешаться (и, предположительно, сообщить конечному пользователю о проблеме).

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

Почему я говорю, что вы не хотите этого делать?

Во-первых, есть лучшее решение. Пусть устройства полагаются на DHCP. Затем в вашей локальной сети установите DHCP-сервер, который указывает места для использования ваших локальных DNS-серверов, по разумному адресу (например, FEC0:0:0:ffff::/126 или IPv6-адрес, начинающийся с fd или, возможно, fec0:, или IPv4, использующий диапазоны адресов из IETF BCP 5 («RFC 1918»)). Если вы стандартизируете это для клиентских машин, то мобильные системы, скорее всего, будут работать удаленно и в вашей локальной сети, как и требуется.

Большая проблема с выполнением ожидаемых действий — это маршрутизация. Если вы настроили адрес 192.168.55.3/24, а другой компьютер с адресом 192.168.55.105/24 пытается связаться с вами, то компьютеры распознают /24 (он же маска подсети 255.255.255.0) и поймут, что все, что соответствует первым трем октетам (начинающимся с «192.168.55.»), находится в локальной сети, и попытаются установить прямую связь.

Если DNS-клиент находится по адресу 192.168.55.105/24 и пытается связаться с 8.8.8.8, то компьютер распознает, что 8.8.8.8 не соответствует первым трем октетам, и поэтому компьютер попытается отправить трафик на шлюзовое устройство, чаще всего «шлюз по умолчанию», который отправляет информацию в Интернет. (Это «шлюзовое» устройство должно находиться в локальной сети. Используя более технические термины, шлюз должен находиться в той же подсети.)

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

Вы можете заставить свои клиентские системы незаконно использовать диапазон 8.8.8.0/24. Тогда 8.8.8.8 покажется близким. Обратите внимание, что это нарушит допустимые коммуникации с 8.8.8.8, и вы не сможете одновременно использовать эту стратегию, чтобы ваши локальные компьютеры находились в том же близком диапазоне IP-адресов, что и другой адрес.
Вы можете заставить свою локальную систему использовать 192.168.55.105/0 вместо 192.168.55.105/24. Это означает, что вы используете маску подсети 0.0.0.0, так что теперь вы эффективно убедили свой компьютер, что 8.8.8.8 — это локальный адрес. Поэтому коммуникации не будут идти на ваш «шлюз по умолчанию», а вместо этого попытаются достичь 8.8.8.8 напрямую в вашей локальной сети. Если и клиент, и сервер делают это, то это, скорее всего, сработает.
- Однако, используя показанный здесь экстремальный пример, вы эффективно убедили свой компьютер, что все IP-адреса являются частью вашей локальной сети. Таким образом, этот незаконный метод теперь убедил затронутый компьютер, что весь Интернет должен рассматриваться так, как будто он находится в вашей локальной сети. Теперь вместо того, чтобы разорвать связь с законным сайтом Google по адресу 8.8.8.8, вы эффективно разорвали связь со всеми законными IP-адресами в Интернете. Ой. Плохо.
Вы можете настроить пользовательскую маршрутизацию на вашем устройстве «шлюза по умолчанию», чтобы информация, отправляемая на 8.8.8.8, перенаправлялась на нужный вам локальный IP-адрес, а не передавалась вашему интернет-провайдеру.

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

Как человек, который понимает маршрутизацию трафика, я бы предположил, что вам может понадобиться некоторая экспертиза, чтобы успешно разорвать законные соединения, которые вам нужны (к настоящему 8.8.8.8), не разрывая при этом законные соединения, которые вы не хотите разрывать. И если у вас есть такой опыт, чтобы это осуществить, то у вас, вероятно, также есть некоторая экспертиза, чтобы просто запустить DNS-сервер на установленном частном адресе. Так почему бы не сделать все стандартизированным способом, который с меньшей вероятностью вызовет странные редкие побочные эффекты, которые сложнее предвидеть и устранять?

В ответ на то, что вы спросили, и как вы это спросили, да, технически что-то подобное возможно. Но также имейте в виду, что если коммуникация не идет туда, куда должна идти, то это часто описывается как атака «Человек посередине» («MITM»). Подключения веб-браузера уже эволюционировали для поддержки HKPK, чтобы противостоять таким махинациям. Менее известный факт заключается в том, что DNS в значительной степени был заменен использованием EDNS (используя «механизмы расширения для DNS»), а более широко известный факт заключается в том, что существуют некоторые новые усовершенствования безопасности DNS, называемые DNSSec. Если вы не знали ни об одном из этого, то знайте, что нынешние разработчики популярного программного кода для Интернета, возможно, уже намного вас опередили, поэтому вам, возможно, стоит иметь это в виду, прежде чем пытаться включить «атаку MITM» в качестве критической части какого-то нового причудливого дизайна любой сети, которую вы контролируете.

Итак, подведем итог: главная причина, по которой, как я думаю, вам не стоит делать это для реальной сети (а не для тестовой лаборатории, где вы изучаете возможности), заключается в том, что для достижения полезных законных целей есть лучший способ. А именно, когда вы пытаетесь спроектировать, как будет вести себя ваша сеть, делайте все правильно. Скорее всего, вы испытаете меньше боли в целом.

Чтобы еще раз прояснить это на случай, если вы забыли, "правильный способ", о котором я говорю, заключается в том, чтобы просто использовать ваш локальный DNS-сервер на частном адресе, никого не обманывая, и поощрять компьютеры использовать локальный частный адрес или полагаться на DHCP, и заставить ваши локальные DHCP-серверы сообщать устройствам полагаться на ваш локальный DNS-сервер. Это более честный стиль дизайна, который не нарушает возможности связи с публичным сайтом и широко поддерживается, поэтому у тех, кто поддерживает стандарты Интернета, меньше шансов сделать что-то, что нарушит такой законный дизайн во многих локальных сетях, используемых по всему миру.

Answer

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

Допустим, вы управляете компьютером и можете задать его IP-адрес. И вот вы вводите IP-адрес 8.8.8.8. Вы можете это сделать? Да.

Теперь «маршрутизация» может быть проблемой (о чем я собираюсь рассказать в более поздней части этого ответа). Однако, могут быть способы обойти это. Итак, предположим, что удаленный конец связался с вашим сервером ICMP и выполнил «ping 8.8.8.8». Ответит ли ваш сервер ICMP (обычно встроенный в программные компоненты «стека TCP/IP»)? Да. Никаких проблем.

Допустим, вы запускаете сервер на этом компьютере, например DNS-сервер. Если бы на вашем компьютере был запущен DNS-сервер и он получил ответ, мог бы он ответить и все бы работало? Да. Никаких проблем.

Допустим, вы запускаете HTTP-сервер. Если другой компьютер открыл веб-браузер и в итоге связался с вашим компьютером с IP-адресом, то сможет ли ваш компьютер ответить и все ли заработает? Эм... ну... раньше ответ был "Да". Но теперь все стало немного сложнее из-за HPKP. Для получения более подробной информации см.Веб-страница Википедии о закреплении открытого ключа HTTP]. Так что это может не сработать так уж хорошо. Подводя итог: популярные веб-браузеры посчитали это стилем атаки и поставляли некоторые сведения о надлежащих сертификатах/соединениях HTTPS для некоторых из ведущих сайтов мира. Другой связанной техникой может быть «предварительная загрузка HSTS», которая связана с HSTS («HTTP Strict Transport Security»). Так что, когда люди устанавливают современные версии веб-браузеров, эти браузеры могут поставляться с некоторыми сведениями о некоторых веб-сайтах. Если ваш поддельный сайт «Google» не соответствует ожиданиям, браузер может вмешаться (и, предположительно, сообщить конечному пользователю о проблеме).

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

Почему я говорю, что вы не хотите этого делать?

Во-первых, есть лучшее решение. Пусть устройства полагаются на DHCP. Затем в вашей локальной сети установите DHCP-сервер, который указывает места для использования ваших локальных DNS-серверов, по разумному адресу (например, FEC0:0:0:ffff::/126 или IPv6-адрес, начинающийся с fd или, возможно, fec0:, или IPv4, использующий диапазоны адресов из IETF BCP 5 («RFC 1918»)). Если вы стандартизируете это для клиентских машин, то мобильные системы, скорее всего, будут работать удаленно и в вашей локальной сети, как и требуется.

Большая проблема с выполнением ожидаемых действий — это маршрутизация. Если вы настроили адрес 192.168.55.3/24, а другой компьютер с адресом 192.168.55.105/24 пытается связаться с вами, то компьютеры распознают /24 (он же маска подсети 255.255.255.0) и поймут, что все, что соответствует первым трем октетам (начинающимся с «192.168.55.»), находится в локальной сети, и попытаются установить прямую связь.

Если DNS-клиент находится по адресу 192.168.55.105/24 и пытается связаться с 8.8.8.8, то компьютер распознает, что 8.8.8.8 не соответствует первым трем октетам, и поэтому компьютер попытается отправить трафик на шлюзовое устройство, чаще всего «шлюз по умолчанию», который отправляет информацию в Интернет. (Это «шлюзовое» устройство должно находиться в локальной сети. Используя более технические термины, шлюз должен находиться в той же подсети.)

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

Вы можете заставить свои клиентские системы незаконно использовать диапазон 8.8.8.0/24. Тогда 8.8.8.8 покажется близким. Обратите внимание, что это нарушит допустимые коммуникации с 8.8.8.8, и вы не сможете одновременно использовать эту стратегию, чтобы ваши локальные компьютеры находились в том же близком диапазоне IP-адресов, что и другой адрес.
Вы можете заставить свою локальную систему использовать 192.168.55.105/0 вместо 192.168.55.105/24. Это означает, что вы используете маску подсети 0.0.0.0, так что теперь вы эффективно убедили свой компьютер, что 8.8.8.8 — это локальный адрес. Поэтому коммуникации не будут идти на ваш «шлюз по умолчанию», а вместо этого попытаются достичь 8.8.8.8 напрямую в вашей локальной сети. Если и клиент, и сервер делают это, то это, скорее всего, сработает.
- Однако, используя показанный здесь экстремальный пример, вы эффективно убедили свой компьютер, что все IP-адреса являются частью вашей локальной сети. Таким образом, этот незаконный метод теперь убедил затронутый компьютер, что весь Интернет должен рассматриваться так, как будто он находится в вашей локальной сети. Теперь вместо того, чтобы разорвать связь с законным сайтом Google по адресу 8.8.8.8, вы эффективно разорвали связь со всеми законными IP-адресами в Интернете. Ой. Плохо.
Вы можете настроить пользовательскую маршрутизацию на вашем устройстве «шлюза по умолчанию», чтобы информация, отправляемая на 8.8.8.8, перенаправлялась на нужный вам локальный IP-адрес, а не передавалась вашему интернет-провайдеру.

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

Как человек, который понимает маршрутизацию трафика, я бы предположил, что вам может понадобиться некоторая экспертиза, чтобы успешно разорвать законные соединения, которые вам нужны (к настоящему 8.8.8.8), не разрывая при этом законные соединения, которые вы не хотите разрывать. И если у вас есть такой опыт, чтобы это осуществить, то у вас, вероятно, также есть некоторая экспертиза, чтобы просто запустить DNS-сервер на установленном частном адресе. Так почему бы не сделать все стандартизированным способом, который с меньшей вероятностью вызовет странные редкие побочные эффекты, которые сложнее предвидеть и устранять?

В ответ на то, что вы спросили, и как вы это спросили, да, технически что-то подобное возможно. Но также имейте в виду, что если коммуникация не идет туда, куда должна идти, то это часто описывается как атака «Человек посередине» («MITM»). Подключения веб-браузера уже эволюционировали для поддержки HKPK, чтобы противостоять таким махинациям. Менее известный факт заключается в том, что DNS в значительной степени был заменен использованием EDNS (используя «механизмы расширения для DNS»), а более широко известный факт заключается в том, что существуют некоторые новые усовершенствования безопасности DNS, называемые DNSSec. Если вы не знали ни об одном из этого, то знайте, что нынешние разработчики популярного программного кода для Интернета, возможно, уже намного вас опередили, поэтому вам, возможно, стоит иметь это в виду, прежде чем пытаться включить «атаку MITM» в качестве критической части какого-то нового причудливого дизайна любой сети, которую вы контролируете.

Итак, подведем итог: главная причина, по которой, как я думаю, вам не стоит делать это для реальной сети (а не для тестовой лаборатории, где вы изучаете возможности), заключается в том, что для достижения полезных законных целей есть лучший способ. А именно, когда вы пытаетесь спроектировать, как будет вести себя ваша сеть, делайте все правильно. Скорее всего, вы испытаете меньше боли в целом.

Чтобы еще раз прояснить это на случай, если вы забыли, "правильный способ", о котором я говорю, заключается в том, чтобы просто использовать ваш локальный DNS-сервер на частном адресе, никого не обманывая, и поощрять компьютеры использовать локальный частный адрес или полагаться на DHCP, и заставить ваши локальные DHCP-серверы сообщать устройствам полагаться на ваш локальный DNS-сервер. Это более честный стиль дизайна, который не нарушает возможности связи с публичным сайтом и широко поддерживается, поэтому у тех, кто поддерживает стандарты Интернета, меньше шансов сделать что-то, что нарушит такой законный дизайн во многих локальных сетях, используемых по всему миру.

Question 4

Теоретически это должно быть нормально.

На практике:

Может нарушить предположения третьих лиц.
Вы можете использовать программное обеспечение/оборудование, которое предполагает соблюдение определенных общеизвестных соглашений об IP-адресах, что может привести к непреднамеренному поведению при нарушении этих предположений.
Может вызвать скрытые ошибки.
Некоторое глючное ПО в большинстве случаев работает нормально, но странные особенности могут вызывать их. Такие ошибки можно исправить, если их заметить, но если вы используете нестандартную конфигурацию, вероятность столкнуться с ошибками, с которыми никто раньше не сталкивался, может возрасти.
Может запутать других, работающих с вашей сетью.
Даже если вы спокойно помните, что это 8.8.8.8означает что-то еще в вашей внутренней сети, это может потенциально сбить с толку других. Коллеги, техническая поддержка, люди, читающие журнал, которым вы можете поделиться на форуме помощи и т. д., могут столкнуться с трудностями.
Могут возникнуть противоречия в кэшах.
Если какие-либо устройства в вашей сети ранее были подключены к глобальному Интернету, в их настройках, правилах брандмауэра и т. д. могут быть сохранены адреса IPv4, что может привести к нежелательным коллизиям при подключении к локальной сети.

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

Answer

Теоретически это должно быть нормально.

На практике:

Может нарушить предположения третьих лиц.
Вы можете использовать программное обеспечение/оборудование, которое предполагает соблюдение определенных общеизвестных соглашений об IP-адресах, что может привести к непреднамеренному поведению при нарушении этих предположений.
Может вызвать скрытые ошибки.
Некоторое глючное ПО в большинстве случаев работает нормально, но странные особенности могут вызывать их. Такие ошибки можно исправить, если их заметить, но если вы используете нестандартную конфигурацию, вероятность столкнуться с ошибками, с которыми никто раньше не сталкивался, может возрасти.
Может запутать других, работающих с вашей сетью.
Даже если вы спокойно помните, что это 8.8.8.8означает что-то еще в вашей внутренней сети, это может потенциально сбить с толку других. Коллеги, техническая поддержка, люди, читающие журнал, которым вы можете поделиться на форуме помощи и т. д., могут столкнуться с трудностями.
Могут возникнуть противоречия в кэшах.
Если какие-либо устройства в вашей сети ранее были подключены к глобальному Интернету, в их настройках, правилах брандмауэра и т. д. могут быть сохранены адреса IPv4, что может привести к нежелательным коллизиям при подключении к локальной сети.

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

Можно ли использовать глобальные IP-адреса без Интернета?

решение1

решение2

решение3

решение4

Связанный контент