Ще за дні, що стосуються лише IPv4, з'єднання LISTEN, яке відображається netstatяк прослуховування 0.0.0.0, відповість на з'єднання будь-якого інтерфейсу IPv4 в системі.
Як я розумію, нова ідіома IPv6 ::слухає всі доступні інтерфейси IPv6 та IPv4. Чи правильно це для всіх ОС (Unix, Windows, Mac)? Чи є ідіома слухати лише інтерфейси IPv6?
Відповіді:
На жаль, це відрізняється залежно від того, яку операційну систему ви використовуєте.
У Microsoft Windows прив'язування сокета ::прив'язується лише до портів IPv6. Таким чином , щоб прослуховувати всі адреси на IPv4 , так і IPv6, необхідно пов'язувати з 0.0.0.0, а також ::. Наступний витяг із вікна:
C:\>netstat -an | find "445"
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
Приклад, який я даю, - порт 445, який використовується для SMB-трафіку, коли NetBIOS не використовується. Як бачите, він є обов'язковим для обох 0.0.0.0і ::змушує працювати клієнтів IPv4 та IPv6 відповідно.
В Linux ::включено IPv4-сумісні адреси, як ви правильно здогадалися, тому прив'язування до 0.0.0.0них непотрібне. Я написав просту програму Python, яка прив'язується лише до AF_INET6сокета ::. Хоча я також не прив’язувався до AF_INETсокета (IPv4), він все ще приймає з'єднання від клієнтів IPv4. Якщо, скажімо, 10.1.1.3підключиться до нього, це відобразиться як з'єднання ::ffff:10.1.1.3.
За винятком того, що воно стає волохатим. Вищезазначене не стосується Linux, якщо /proc/sys/net/ipv6/bindv6onlyвстановлено значення 1, і в такому випадку поведінка точно така ж, як і Windows - обов'язкові для ::прослуховування лише для запитів IPv6. Якщо ви хочете також слухати IPv4-запити, вам потрібно буде створити AF_INETсокет і прослухати 0.0.0.0. На щастя, за замовчуванням bindv6onlyє 0, тому існує дуже невелика ймовірність, що вам коли-небудь доведеться зіткнутися з цим (за винятком випадків, коли ви використовуєте Debian, який фактично за замовчуванням bindv6only = 1).
Все це зручно знати, перевіряючи, чи є послуга з підтримкою IPv6 та чи підтримується вона також IPv4. Ось мій SSH-сервер:
$ netstat -64ln | grep 22
tcp6 0 0 :::22 :::* LISTEN
Як бачите, SSH слухає лише на ::порту 22. Однак, це не просто прослуховування клієнтів IPv6 - він чудово працює від клієнтів IPv4, через сумісність IPv4. Щоб довести це, якщо ви подивитесь на це:
$ cat /proc/sys/net/ipv6/bindv6only
0
bindv6onlyвимкнено (за замовчуванням). Якби це було встановлено 1, я би повинен був заохотити SSH слухати 0.0.0.0також (або замість цього).
Вибачте за відсутність інформації щодо речей Mac OS X. Я використовував його в минулому, але я віддаю перевагу естетиці GNOME, тому не використовував її дуже давно. Однак я б здогадався, що поведінка така ж, як у Linux.
Сподіваюсь, це допомагає.
Це неможливо, оскільки сегмент адресного простору IPv6 такий же, як і простір IPv4, тож навіть якщо ви могли якось відключити IPv4-сокети, ви все одно зможете відправити пакети IPv4 до IPv6-розетки. Ознайомтеся з розділом переходу IPv4 на сторінці Вікіпедії IPv4 .
Редагувати: Ах, трохи далі вона говорить:
Деякі поширені стеки IPv6 не підтримують функцію адресного відображення IPv4, або тому, що стеки IPv6 та IPv4 є окремими реалізаціями (Microsoft Windows до Vista / Longhorn: наприклад XP / 2003), або через проблеми безпеки (OpenBSD). У цих операційних системах необхідно відкрити окремий сокет для кожного IP-протоколу, який повинен підтримуватися. У деяких системах (наприклад, Linux, NetBSD, FreeBSD) ця функція управляється параметром сокета IPV6_V6ONLY, як зазначено в RFC 3493
Можливо, ви могли б зробити це за допомогою свого ідентифікатора мережі, AAAA: BBBB: CCCC: DDDD :: або будь-якого іншого для вас. Це гарантувало б, що тільки інтерфейси IPv6 підхоплять його. Я думаю. Я не майстер IPv6.