Jak mogę uzyskać nazwę interfejsu/indeks skojarzony z gniazdem TCP?

Question

Piszę serwer TCP, który musi wiedzieć, z którego interfejsu pochodzi każde połączenie. Nie mogę użyć adresu/podsieci do określenia, który interfejs był używany, ponieważ mogą istnieć interfejsy o tych samych wartościach adres/podsieć. Jest oparty na systemie Linux i nie ma potrzeby, aby kod był przenośny.

Wszystko, co mogłem znaleźć, to funkcje umożliwiające uzyskanie wszystkich interfejsów lub pojedynczy interfejs według indeksu. Nie mogłem znaleźć sposobu na połączenie interfejsu z akceptowanym gniazdem TCP.

Wszelkie pomysły? Coś, co przeoczyłem?

EDYCJA: Aby powtórzyć, adresy IP nie są unikalne w moim przypadku. Ani adresy docelowe (sam serwer), ani adresy źródłowe (klienci). Tak, jest to bardzo ekstremalny schemat IP.

Answer 1

Sprawdź adres docelowy.

Każdy interfejs jest zwykle związany z unikalnym adresem. Jeśli wiele interfejsów jest połączonych ze sobą, prawdopodobnie nie ma znaczenia, którego użył.

Jedynym wyjątkiem od tej reguły jest użycie aniwastu ipv6, ale nawet wtedy normalnie nie ma wielu interfejsów na tym samym hoście z tym samym adresem IP.

Answer 2

Myślę, że używając getsockname() po zaakceptowaniu() połączenie przychodzące może być tym, na co masz ochotę. Dwie funkcje getsockname() i getpeername() pobierają odpowiednio adres lokalny i zdalny, do którego przyłączone jest gniazdo. Oba powinny być ważne dla w pełni połączonego gniazda TCP.

Edycja: Choć wydaje się, że jest to prawdą dla OpenBSD, zgodnie ze stroną man, strona podręcznika linuksowego różni się znacznie i dlatego getsockname() po accept() w systemie Linux prawie na pewno nie jest użyteczne. Uczy mnie używać mojej pamięci zamiast sprawdzać wszystko. westchnienie

Answer 3

Tabela routingu jądra decyduje, który interfejs wysłać pakiet, stąd możliwość wiązania urządzeń. Rzut oka na "Linux Socket Programming, Warren W. Gay" sugeruje, że określenie interfejsu jest złe, a ze względu na dynamikę jądra (firewall, forwarding) jest bardziej skomplikowane.

Sugerowałbym zmianę twojego schematu IP tak, aby informacje IP wskazywały twój interfejs (y) poprzez wyszukiwanie w ten sam sposób, co ifconfig, w przeciwnym razie strzelasz sobie w mądry projekt stopy.

1) Uzyskać informacje IP z sesji TCP 2) Lookup który interfejs (y) może to być ważne dla

będę patrząc w API jądra choć. Nie powinieneś tego wiedzieć, abstrakcja istnieje z wielu dobrych powodów.

Extra Myśl Zastanawiając się nad tym, wydaje się, że jeśli oba interfejsy korzystać z tego samego adresu IP to musi istnieć różnica zakres routingu adres klienta (w przeciwnym razie byłyby stosowane zarówno interfejsy). Twój serwer może sprawdzić tabelę routingu na podstawie klienta IP

Answer 4

Ogólnie, nie powinieneś wiedzieć, w jakim interfejsie będą wysyłane/odbierane pakiety; to jest zadanie tabeli routingu jądra. Trudno jest znaleźć interfejs dla gniazda, ponieważ tak naprawdę nie ma bezpośredniego powiązania. Routing pakietów może się zmienić w czasie życia gniazda na podstawie informacji o routingu.

Dla gniazd datagramowych (UDP) możesz używać getsockopt(s, IPPROTO_IP, IP_PKTINFO, ...); patrz getsockopt(2) i ip(7).

Dla gniazd strumieniowych (TCP) jedną opcją może być otwieranie wielu gniazd nasłuchujących, po jednym dla każdego interfejsu w systemie i używanie setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ...) do wiązania każdego z jednym interfejsem; patrz setsockopt(2) i socket(7).

Answer 5

Oczywiście nie coś co wyglądało na bardzo głęboko, nie mówiąc już próbował, to może być jeden na „tak szalony, że może działać tylko” kosz ...

Jeśli to będzie tylko dla naprawdę nigdy Linux, możesz napisać niestandardowy moduł netfilter, który śledzi przychodzące połączenia i notatki, do których interfejsu wchodzą, i zapisuje te informacje gdzieś, aby aplikacja serwera mogła je odczytać.

Answer 6

Propozycja Kierona na napisanie modułu netfiltra jest prawdopodobnie jednym ze sposobów wypróbowania, ale chciałbym powstrzymać się od napisania mojego pierwszego modułu jądra dla tego rozwiązania.

Wymyśliłem inną opcję użycia źródłowego NAT i tłumaczenia portu źródłowego połączenia w celu skorelowania ze źródłem połączenia. Mogę przypisać zakresy portów dla każdej sieci i sprawdzić to na serwerze. Jedyny problem polega na tym, że źródłowy NAT w iptables jest wykonywany w łańcuchu POSTROUTING i nie jestem pewien, czy jest używany dla połączeń akceptowanych przez ten host, więc może potrzebuję użyć innego serwera.

ma łatwych rozwiązań tutaj, szkoda, że ​​nie można uzyskać nazwę/indeks interfejsu z gniazdka ...

Answer 7

dodaję kolejną odpowiedź i potencjalne rozwiązanie po przeglądając źródła Wireshark i iftop który wydają się mieć pośrednio podobną funkcjonalność.

Wygląda na to, że możesz użyć libpcap do sniffowania interfejsów. Zakładając, że możesz zidentyfikować unikalną część sesji TCP/IP, możesz śledzić ją do interfejsu, po prostu używając filtrów i śledzenia sesji.

Brak modułów jądra (i odgrywa ładne z wątków)

http://www.ex-parrot.com/pdw/iftop/ kilka prostych źródło mieć okiem na www.tcpdump.org/ dla libpcap

myślę, że będzie w stanie dopasować VLAN używając go również.

Również wireshark może być przydatny do debugowania. Mam nadzieję że to pomoże! Od tego czasu jest w moim mózgu.

Answer 8

Użyj adresu getsockname(), aby uzyskać adres IP lokalnego końca połączenia TCP. Następnie użyj getifaddrs() aby znaleźć odpowiedni interfejs:

struct sockaddr_in addr; 
struct ifaddrs* ifaddr; 
struct ifaddrs* ifa; 
socklen_t addr_len; 

addr_len = sizeof (addr); 
getsockname(sock_fd, (struct sockaddr*)&addr, &addr_len); 
getifaddrs(&ifaddr); 

// look which interface contains the wanted IP. 
// When found, ifa->ifa_name contains the name of the interface (eth0, eth1, ppp0...) 
for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) 
{ 
    if (ifa->ifa_addr) 
    { 
     if (AF_INET == ifa->ifa_addr->sa_family) 
     { 
      struct sockaddr_in* inaddr = (struct sockaddr_in*)ifa->ifa_addr; 

      if (inaddr->sin_addr.s_addr == addr.sin_addr.s_addr) 
      { 
       if (ifa->ifa_name) 
       { 
        // Found it 
       } 
      } 
     } 
    } 
} 
freeifaddrs(ifaddr); 

powyżej jest po prostu brudny przykład, potrzebne są pewne modyfikacje:

1. Dodaj brakuje weryfikacje Błąd wsparcia
2. IPv6