Как я могу получить имя интерфейса / индекс, связанный с сокетом TCP?
Лучше использовать библиотеку requests, если вы используете Python 3.x. Вот как вы можете получить ответ JSON.
import requests
snav_timetable_url = "https://booking.snav.it/api/v1/rates/1040/2019-02-25/1042/2019-02-25?lang=1"
fh = requests.get(snav_timetable_url)
json_data = fh.json()
Таким образом, у вас не будет никаких ошибок и вы сможете продолжить анализ.
for departure in json_data ['data']['ratesOutward']:
snav_timetable_data_cleaned.append({
'COMPANY': 'Snav',
'CODICE CORSA': departure['coditinera'],
'DEPARTURE DATE TIME': departure['strDatapart'],
'ARRIVAL DATE TIME': departure['strDataarri']
})
7 ответов
В общем, вам не нужно знать, на каком интерфейсе будут отправляться / приниматься пакеты; это работа таблицы маршрутизации ядра. Трудно узнать интерфейс сокета, потому что прямой связи действительно нет. Маршрутизация пакетов может изменяться в течение срока службы сокета в зависимости от информации о маршрутизации.
Для сокетов дейтаграмм (UDP) вы можете использовать getsockopt (s, IPPROTO_IP, IP_PKTINFO, ...) ; см. getsockopt (2) и ip (7) .
Для потоковых (TCP) сокетов одним вариантом может быть открытие нескольких прослушивающих сокетов, по одному для каждого интерфейса в системе и используйте setsockopt (s, SOL_SOCKET, SO_BINDTODEVICE, ...) для привязки каждого к одному интерфейсу;
Таблица маршрутизации ядра решает, на каком интерфейсе отправлять пакет, следовательно, можно связывать устройства. Беглый взгляд на "Программирование сокетов Linux, Уоррен В. Гей" показывает, что указывать интерфейс плохо и что из-за динамики ядра (брандмауэр, пересылка) он более сложный.
Я бы предложил изменить ваш IP-адрес. Схема такова, что информация IP сообщает вам ваш интерфейс (ы), просматривая его так же, как ifconfig, иначе вы стреляете в себя в дизайне ног.
1) Получить информацию об IP из TCP-сеанса. 2) Найдите, какой интерфейс (ы) это может быть действительным для
Я продолжу искать в API ядра. Вам не обязательно это знать, абстракция существует по множеству веских причин.
Extra Thought Размышляя над этим, кажется, что если оба интерфейса используют один и тот же IP-адрес, тогда должна быть разница в маршрутизации диапазона адресов клиентов (в противном случае будут использоваться оба интерфейса). Ваш сервер может проверить таблицу маршрутизации на основе IP-адреса клиента
I think using getsockname() after accept()ing the incoming connection might be what you're after. The two functions getsockname() and getpeername() get the local and remote addresses respectively that a socket is bound to. Both should be valid for a fully connected TCP socket.
Edit: Whilst this seems to be true for OpenBSD according to the man page, the Linux man page differs considerably and so getsockname() after accept() on Linux is almost certainly unuseful. Teaches me for using my memory instead of checking everything. sigh
Посмотрите на адрес назначения.
Каждый интерфейс обычно привязан к уникальному адресу. Если несколько интерфейсов связаны вместе, вероятно, не имеет значения, какой из них используется.
Единственным исключением является использование ipv6 anycast, но даже в этом случае у вас обычно не будет нескольких интерфейсов на одном хосте с тот же ip.
Очевидно, не то, что я изучал очень глубоко, не говоря уже о том, чтобы пытаться, это может быть одна из корзины "настолько безумно, что просто может сработать" ...
Если это действительно будет только для Linux, вы можете написать собственный модуль netfilter , который отслеживает входящие соединения и отмечает, через какой интерфейс они поступают, и записывает эту информацию куда-нибудь для ваше серверное приложение для чтения.
I am adding another answer and a potential solution after looking through the source of Wireshark and iftop which seem to have indirectly similar functionality.
Looks to me that you can use libpcap to sniff on interfaces. Presuming you can identify some unique part of the TCP/IP session then you can track it down to an interface fairly simply using filters and session tracking.
No kernel modules (and it plays nice with threads)
http://www.ex-parrot.com/pdw/iftop/ Some simple source to have a peek at www.tcpdump.org/ for libpcap
I think you will be able to match VLANs using it too.
Also wireshark might be useful for debugging. Hope this helps! It's been on my brain since.
Предложение Кирона написать модуль netfilter, вероятно, является одним из способов попробовать, но я бы хотел воздержаться от написания моего самого первого модуля ядра для этого решения.
Я придумал. другой вариант использования NAT источника и преобразования порта источника соединения для корреляции с источником соединения. Я могу назначить диапазоны портов для каждой сети и проверить их на сервере. Единственная проблема заключается в том, что NAT источника в iptables выполняется в цепочке POSTROUTING, и я не уверен, что он используется для соединений, которые принимаются этим хостом, поэтому мне может потребоваться другой сервер.
Здесь нет простых решений, жаль, я не могу получить имя / индекс интерфейса из сокета ...