Одинаковы ли IP-адреса с ведущими нулями и без них?

У меня есть система безопасности, и в настройках сети разрешен только трехзначный IP-адрес. Я не могу установить его 192.168.2.100, вместо этого я должен использовать 192.168.002.100.

Эти два IP-адреса разные? Нужно ли настраивать локальную сеть маршрутизатора, чтобы все 192.168.xxx.xxxработало правильно? Я не могу найти надежную информацию об этом.

Это зависит от инструмента.

Для большинства целей оба будут одинаковыми, но не всегда.

Например, если вы используете трехзначное число, начинающееся с нуля (или двузначное, начинающееся с нуля, спасибо @ Dietrich-Epp), тогда ping будет считать восьмеричные числа.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users>ping 011.012.013.014

Pinging 9.10.11.12 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 9.10.11.12:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Предполагая, что все программное обеспечение, которое вы используете, использует десятичную точку и подсеть правильно, да, они одинаковы.

Например, 192.168.0.1 - это только понятные десятичные дробные значения двоичного значения 11000000.10101000.00000000.00000001.

Вводите ли вы это как 192.168.0.1 или 192.168.000.001, они оба равны 11000000.10101000.00000000.00000001

Это зависит от инструментов или функций, которые любая конкретная программа использует для анализа указанного адреса. И Microsoft, и Linux, а также другие операционные системы используют POSIX- совместимую inet_addr()процедуру для анализа адресов.

Многие программы TCP / IP, такие как Ping и FTP, используют функцию сокетов inet_addr () для преобразования строк IP-адресов в 4-байтовые адреса. Эта функция принимает IP-адрес в стандартном десятичном, восьмеричном и шестнадцатеричном формате.
Microsoft KB115388 Ping и FTP разрешают IP-адрес с лидирующим нулем в виде восьмеричного

Функция inet_addr () преобразует адрес хоста Интернета cp из нотации цифр и точек IPv4 в двоичные данные в порядке сетевых байтов.

Во всех вышеперечисленных формах компоненты точечного адреса могут быть указаны в десятичном, восьмеричном (с лидирующим 0) или шестнадцатеричном с лидирующим 0X). Адреса в любой из этих форм в совокупности называются нотацией цифр и точек IPv4 . Форма, которая использует ровно четыре десятичных числа, называется точечно-десятичной нотацией IPv4 (или иногда: четырехточечной нотацией IPv4).
inet_addr (3): процедуры изменения адреса в Интернете - справочная страница Linux

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

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

Как указали Гонки Легкости на Орбите и другие,

INET(3)Страница человек описывает inet_addrи inet_atonстандартные функции , используемые для преобразования «IPv4 чисел и точек обозначения в виде двоичного кода». Это говорит

... компоненты точечного адреса могут быть указаны в десятичном, восьмеричном (с лидирующим 0) или шестнадцатеричном с лидирующим 0X).

Таким образом, технически НЕТ , IP-адрес с ведущими нулями (не всегда) не совпадает с адресом без начальных нулей. В вашем случае , однако, 192.168.2.100и 192.168.002.100являются идентичными, так как 002 == 2.

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

Некоторые реализации считают октеты с ведущими нулями десятичными, другие реализации считают их восьмеричными. Пока октет находится в диапазоне от 0 до 7, это не имеет значения. Так, например, 192.168.002.100будет интерпретироваться как 192.168.2.100в обеих реализациях.

Но если вы введете адрес, 192.168.010.100он может быть интерпретирован как один 192.168.10.100или в 192.168.8.100зависимости от реализации. Также не исключено, что реализации существуют, что рассматривает начальные нули как синтаксическую ошибку. Кроме того, существуют сценарии, в которых программное обеспечение может настаивать на том, что вы должны использовать каноническое представление по той или иной причине. По всем этим причинам я рекомендую избегать начальных нулей при записи IP-адреса.

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

Немного связаны есть реализации, которые позволяют вам иметь менее четырех компонентов в точечной нотации. Когда имеется менее четырех компонентов, последний компонент имеет более 8 бит, а более ранние компоненты имеют ровно 8 бит. Например 192.168.612, на самом деле будет правильным способом записи 192.168.2.100. Но повторное использование этой записи не рекомендуется.

Небольшой совет: в некоторых случаях важно использовать нулевые префиксы в IP-адресах. Примером является Apache .htaccess, запрещающий правила.

Если вы используете что-то вроде

deny from 11.22.33.22

Apache настолько глуп, что также блокирует доступ со следующих IP-адресов:

111.22.33.22

11.22.33.221

211.22.33.221

и вообще любой IP-адрес, который включает 11.22.33.22

Итак, просто чтобы быть уверенным, что вы не заблокируете IP-адреса, которые вы не хотели блокировать, вы должны использовать:

deny from 011.022.033.022

чтобы быть уверенным, что Apache заблокирует доступ только с IP-адреса 11.22.33.22.

будь осторожен с этим. он ДОЛЖЕН быть таким же , но это НЕ !
Я не мог найти объяснение этому, но я могу точно сказать, что в Windows и Linux IP-адреса с ведущими нулями и без них НЕ одинаковы! Может быть, это связано с преобразованием из других форматов, таких как шестнадцатеричный или двоичный формат.

Исходя из моего опыта работы с Windows и Linux, это не зависит от инструмента, но зависит от ОС, кажется, потому что я работаю в некоторых проблем с использованием ips, как 10.08.03.100:

• примечание: "10.08.0.1" и 10.09.0.1 не могут быть найдены
• примечание: "10.010.0.1" разрешено до 10.8.0.1

linux / debian7 / 8: те же результаты с инструментами "ping" и "snmpget"

user@test:~$ ping 10.7.0.1
PING 10.7.0.1 (10.7.0.1) 56(84) bytes of data.
^C
--- 10.7.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.07.0.1
PING 10.07.0.1 (10.7.0.1) 56(84) bytes of data.
^C
--- 10.07.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.8.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.08.0.1
**ping: unknown host 10.08.0.1**
user@test:~$ ping 10.9.0.1
PING 10.9.0.1 (10.9.0.1) 56(84) bytes of data.
^C
--- 10.9.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.09.0.1
ping: unknown host 10.09.0.1
user@test:~$ ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
^C
--- 10.10.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.010.0.1
PING 10.010.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.010.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms

Windows7 / 8/10: те же результаты с инструментами "ping" и "telnet"

(извините, у меня нет английских окон под рукой, ошибка говорит о том, что хост не найден)

C:\Users\user>ping 10.7.0.1

Ping wird ausgeführt für 10.7.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.07.0.1

Ping wird ausgeführt für 10.7.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.8.0.1

Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.08.0.1
Ping-Anforderung konnte Host "10.08.0.1" nicht finden. Überprüfen Sie den Namen,

C:\Users\user>ping 10.9.0.1

Ping wird ausgeführt für 10.9.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.09.0.1
Ping-Anforderung konnte Host "10.09.0.1" nicht finden. Überprüfen Sie den Namen,

C:\Users\user>ping 10.10.0.1

Ping wird ausgeführt für 10.10.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.010.0.1

Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
STRG-C
^C

Два IP-адреса разные.

Тем не мение:

• Люди обычно считают их одинаковыми.
• Некоторые программы считают их одинаковыми.
• Некоторые программы на некоторых платформах будут считать их разными.

Если это звучит запутанно, то это потому, что не существует стандарта, определяющего порядок написания IP-адресов, поэтому разные программисты в разные моменты истории и на разных платформах имели разные представления о том, что следует делать.

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

Я советую вам: не используйте начальные нули, если вы хотите использовать пунктирную десятичную запись. Некоторые программы считают, что этот флаг означает, что вы вводите восьмеричное число. Если вы хотите ввести десятичное число, вы не получите ожидаемых результатов.

Я задал похожий вопрос и получил несколько хороших ответов, так что, если вы хотите почитать RFC, там есть хорошая информация.

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

Изменить : Windows будет читать как восьмеричное, это работает только для Linux.

Ведущий ноль не имеет смысла. Октеты - это числа (базы-10) 0-255, а не строки.

Поскольку я не совсем уверен, что вы спрашиваете (или что вы знаете, какой вопрос задавать :)): при этом IP # должен быть в той же подсети, что и ваша сеть. Если вы выберете 11.12.13.14 в пределах маски подсети 192.168.0.0, это устройство не сможет общаться или использовать эту подсеть.