Почему SSH показывает протокол как tcp6 * и * tcp в netstat?

$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN  

Почему существуют две записи порта 22 ( :::22и 0.0.0.0:22) и почему одна использует протокол как, tcpа другая какtcp6

Это на Ubuntu 12.04.4

По умолчанию sshdиспользуются ipv4 и ipv6. Вы можете настроить протокол, который использует sshd, с помощью AddressFamilyдирективы в/etc/ssh/sshd_config

Для ipv4 и ipv6 (по умолчанию)

AddressFamily any

Только для ipv4

AddressFamily inet

Только для ipv6

AddressFamily inet6

После внесения изменений sshd_configперезапустите, sshdчтобы изменения вступили в силу.

На самом деле, это немного интереснее

По сути, даже если вы полностью отключите IPv6, некоторые сокеты будут идентифицированы как «TCP6 / UDP6» из-за любопытных причин ядра.

Я заметил это после того, как запустил netstat на телефоне Android, который был подключен к сети 3G без подписи поддержки IPv6 (отключен в настройках APN и явно не поддерживается оператором)

После того, как я увидел, что TCP6-соединения WhatsApp как-то сохраняются, я начал исследовать и нашел эту ссылку: https://blog.codecentric.de/en/2014/04/note-netstat/

Можно связываться только по ::IPv4 и IPv6 и разговаривать по ним. Я удивился, почему некоторые приложения, в том числе openssh, не пользуются этим.

Этот раздел об IPv6 в руководстве разработчика FreeBSD содержит несколько интересных комментариев, которые могут быть актуальны:

Похоже, что RFC2553 слишком мало говорит о проблеме подстановочных знаков, особенно о проблеме пространства порта, режиме сбоя и взаимосвязи между подстановочными знаками AF_INET / INET6. Для этого RFC может быть несколько отдельных интерпретаций, которые соответствуют ему, но ведут себя по-разному. Таким образом, для реализации переносимого приложения вы не должны предполагать ничего о поведении в ядре. Использование getaddrinfo (3) - самый безопасный способ. Проблемы пространства номеров портов и подстановочных знаков подробно обсуждались в списке рассылки ipv6imp в середине марта 1999 года, и, похоже, что нет конкретного консенсуса (то есть вплоть до разработчиков). Вы можете проверить архивы списка рассылки.

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