Сокет интернет-домена Linux, сокет и порт транспортных протоколов (TCP / UDP)
23/11/12 12:50, Gene Czarcinski написал:
Libvirt находится в процессе перехода от использования bind-interface к использованию bind-dynamic для устранения проблемы, связанной с безопасностью, когда dnsmasq отвечал на запросы порта 53, которые не происходили на адресе в виртуальном сетевом интерфейсе , который поддерживал экземпляр dnsmasq.
Судя по ps -ax | grep dnsmasq , он использует файл конфигурации /var/lib/libvirt/dnsmasq/default.conf .
## dnsmasq conf file created by libvirt
strict-order
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
#...
Таким образом, они действительно перешли на динамическое связывание из интерфейсов связывания . См. Также src / network.c в dnsmasq:
В --bind-interfaces единственным контролем доступа являются адреса, которые мы слушаем. Нет ничего, чтобы избежать запроса адреса внутреннего интерфейса, поступающего через внешний интерфейс, где мы не хотим принимать запросы, за исключением того, что в обычном случае адреса внутренних интерфейсов - RFC1918 ...
Исправление: использовать --bind-dynamic, который также проверяет интерфейс прибытия. Трудно, если ваша платформа не поддерживает это.
Обратите внимание, что проверка интерфейса прибытия поддерживается в стандартном API IPv6 и всегда выполняется.
Сокет DHCP (порт 67) привязан к определенному интерфейсу. Таким образом, нам не нужно беспокоиться о DHCP, только о DNS (порт 53).
(dnsmasq всегда использует только один сокет DHCP. Он прослушивает все адреса, но когда есть ровно один интерфейс, он может привязаться к нему с помощью SO_BINDTODEVICE . Не просите меня объяснять, почему он использует только один сокет DHCP; выполнение DHCP обычно странное и низкоуровневое).
Тестирование dnsmasq со второй машины:
$ ip route add 192.168.124.1 via $FEDORA_IP
$ sudo nmap -A -F 192.168.124.1
Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-18 16:11 GMT
Nmap scan report for 192.168.124.1
Host is up (0.0023s latency).
Not shown: 98 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.1 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
53/tcp open tcpwrapped
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.11 - 3.14
Network Distance: 1 hop
TRACEROUTE (using port 8888/tcp)
HOP RTT ADDRESS
1 0.80 ms 192.168.124.1
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.42 seconds
Итак, я вижу открытый TCP-порт. Однако он отвечает, как будто это "tcpwrapped". Это означает, что если вы подключаетесь через другой интерфейс из virbr0 , dnsmasq закрывает соединение без чтения каких-либо данных. Таким образом, данные, которые вы отправляете, не имеют значения; это не может, например использовать классическое переполнение буфера.
- Сокеты — это API операционной системы. Этот API позволяет приложениям в одной или разных системах обмениваться данными по протоколам TCP и UDP (и другим протоколам ). Сокеты домена UNIX (, а не интернет-сокеты , как вы пишете ), обеспечивают аналогичную функциональность для связи с приложениями только в той же системе. Концепции для обоих схожи :API предоставляет способы создания сокета, привязки, прослушивания + принятия и подключения сокета, чтения и записи в нем и его закрытия. Что касается чтения и записи, они соответствуют другим файловым дескрипторам, которые относятся к обычным файлам, именованным каналам, анонимным каналам и т. д., но создание файлового дескриптора отличается, и есть еще несколько операций с файловым дескриптором по сравнению, например, с обычными файлами.
- Номер порта в TCP и UDP — это целое число от 1 до 65535. Слово «порт» используется как сокращение от «номера порта». Кортеж из IP-адреса, номера порта и протокола описывает адрес конечной точки. Если вместо этого называть его портом, это вызовет путаницу при чтении другой литературы.
- Неподключенный (, но уже связанный )сокет представляет только одну конечную точку (ip,port,protocol ). Подключенный сокет представляет собой локальную конечную точку и другую (локальную или удаленную )конечную точку, то есть соединение. Нельзя иметь несколько сокетов ядра -для одного и того же соединения, но можно иметь несколько файловых дескрипторов для одного и того же сокета ядра -. Одна и та же конечная точка может быть в нескольких подключенных сокетах, но не для одного и того же соединения, т. е. другая конечная точка соединения должна быть другой. На самом деле может быть несколько несвязанных сокетов, представляющих одну и ту же конечную точку, но это очень необычно.
- Процессы могут совместно использовать сокеты, поскольку сокеты являются файловыми дескрипторами, а файловые дескрипторы могут использоваться совместно. Совместное использование обычно осуществляется путем разветвления, т. Е. Родитель открывает какой-то файл или сокет, а потомок наследует его.Но есть также способы отправить файловый дескриптор/сокет от одного процесса к другому. Совместное использование означает, что оба могут записывать и читать, но никакие данные не будут дублироваться, т.е. если родитель читает какие-то данные, эти данные берутся из сокета и не могут быть прочитаны потомком. Но невозможно, чтобы один процесс создал новый сокет (вместо совместного использования существующего ), который представляет точно такое же соединение, как и существующий сокет в той же системе.
- Два сокета/соединения могут совместно использовать один и тот же порт на одной конечной точке, но они не могут совместно использовать обе конечные точки, т. е. по крайней мере один из исходного IP-адреса, исходного порта, целевого IP-адреса, целевого порта или протокола должен отличаться.
"port" is like a house, identified by city, street name and house number, and "port number" is like the house number of a house. I hope this will help you understand what I mean in my post.
Понятно. Я согласен, это полезная концепция для размышления.
Когда нам нужно поговорить о какой-то точной технической детали в существующих системах, проще определить понятие «номер порта». Мы можем обратиться к значению поля порта в TCP-пакете или к полю sin_portв struct sockaddr_in, используемому с API сокетов UNIX. В таком обсуждении мы можем позволить читателю просмотреть полную историю использования TCP-пакетов (, возможно, в оригинальном RFC :-). Или как API-функции сокетов используются в программе, например, просмотрев страницы man.
Естественно, что это понятие стало сокращаться. Естественно, мы можем сказать «порт 80» вместо «номер порта 80».
Оригинальный стандарт TCP, RFC 793 , говорит о понятиях "порт" и "номер порта" как о разных вещах. (Во введении также используется «идентификатор порта» для обозначения того же, что и «номер порта» ).
Страницы manв текущей версии Linux, например, не настолько тщательно проводят это различие.man 7 ipчасто использует «порт» как сокращение от «номера порта».
Страницы Linux man— очень важный документ, на который ссылаются программисты, поэтому термин «порт» становится двусмысленным. Если вы беспокоитесь о том, что -может быть неверно истолковано, разговор о «номере порта» + IP-адресе — отличная идея.
5. I heard that two connections can't share the same socket (assuming Linux's internet domain socket and transport protocols (TCP/UDP)'s socket can be used interchangeably). Can two connections share the same tuple (IP address, transport protocol, port number)?
Один прослушивающий порт может принимать соединения от нескольких разных исходных портов.
При программировании TCP для Linux прослушиватель получает один сокет для каждого такого соединения (и прослушивает сокет, который не подключен ).
API сокетов не дает возможности сделать обратное, т. е. установить несколько исходящих соединений, используя один и тот же исходный порт. Стандарт транспортного протокола может технически это разрешить; Я не уверена.
Заметьте, что если бы вы могли сделать это,вы не сможете установить несколько подключений к одному и тому же целевому порту. Целевая система не сможет различить эти два соединения. Я предполагаю, что они чувствовали, что это конкретное ограничение было слишком странным, чтобы иметь с ним дело. Затем более широкое ограничение закрепляется в исходных API, включая сокеты UNIX. А позже, если кто-то попытается это сделать, он рискует обнаружить где-нибудь краеугольные случаи, которые на самом деле никогда не проверялись :-).
В транспортном протоколе UDP нет концепции соединений, поэтому вопрос к нему не относится. Вы можете вызвать connect()в сокете UDP, если хотите, но это только для удобства.
Если вы напишете «сокет» в современном документе, люди будут интерпретировать его как отсылку к концепции сокета в API сокетов UNIX. Определение «сокета» в RFC 793 отличается. Это определение, приведенное ниже, больше не используется.
To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections.