Tworzenie (generowanie) pakietu IP

Problemy dotyczące programowania.

Moderatorzy: Moderatorzy, Administratorzy

thopass
Użytkownik
Posty: 173
Rejestracja: 2005-01-08, 13:48
Lokalizacja: Warszawa

Tworzenie (generowanie) pakietu IP

Post autor: thopass »

Witam wszystkich w ten ciepły wieczór.
Potrzebuję pomocy (choćby w postaci linka/nazwy biblioteki) przy tworzeniu pakietu IP.
Problem wygląda następująco:

Mamy następujacą strukturę:

Kod: Zaznacz cały

LAN_A --- ROUTER_A ===== ROUTER_B --- LAN_B
Patrząc od strony A:
Komputer z sieci lokalnej wysyła pakiet pod adres z puli sieci B.
Na routerze A działa aplikacja, która za pomocą biblioteki libpcap przechwytuje wszystkie pakiety. Ci, którzy używali libpcap wiedzą, że po przechwyceniu pakietu otrzymujemy:
nagłówek ETHERNET (adresy MAC i typ protokołu wyższej warstwy), nagłówek IP + dane.
Zadanie polega na pobraniu pakietu IP (czyli wszystkiego od bajtu 15), przesłaniu go przez "tunel" i tam ponownym wpuszczeniu w sieć.

O ile przechwycenie pakietu, wydzielenie z niego danych dotyczących IP i przesłanie ich za pomocą socket'a nie sprawia większego problemu o tyle nie mogę znaleźć sposobu na ponowne wpuszczenie ciągu bajtów (czyli mojego nagłówka IP z danymi) w sieć.
Może mnie ktoś nakierować na jakąś stronę/bibliotekę/howto?
Z góry dziękuję.
Slackware Current + kernel 2.6.32.6 + KDE 3.5.10
registered linux user #412954

[url=http://userbars.org][img]http://img162.imageshack.us/img162/9958/linux1hf8.jpg[/img][/url]
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

nie ty pierwszy wpadles na ten pomysl ;) istnieje wiele rozbudowanych narzedzi do tego
http://en.wikipedia.org/wiki/Tuntap
thopass
Użytkownik
Posty: 173
Rejestracja: 2005-01-08, 13:48
Lokalizacja: Warszawa

Re: Tworzenie (generowanie) pakietu IP

Post autor: thopass »

Wiem, że nie ja pierwszy i to mnie cieszy - zawsze jest szansa na uzyskanie jakiejś pomocy.
Piszesz, że istnieje do tego wiele narzędzi ale ja to muszę w swój program wbudować :/ (piszę w C++). Dlatego biblioteka dająca możliwość odwrotną do libpcap (czyli wypuszczanie pakietów zamiast ich wyłapywania) bardziej by mi pomogła.
Z tego co zrozumiałem TUN/TAP wymaga utworzenia dodatkowych wirtualnych urządzeń - nie da się zrobić tego inaczej?
Slackware Current + kernel 2.6.32.6 + KDE 3.5.10
registered linux user #412954

[url=http://userbars.org][img]http://img162.imageshack.us/img162/9958/linux1hf8.jpg[/img][/url]
Awatar użytkownika
dozzie
Użytkownik
Posty: 855
Rejestracja: 2004-06-01, 13:15
Lokalizacja: Wrocław
Kontakt:

Re: Tworzenie (generowanie) pakietu IP

Post autor: dozzie »

Oczywiście że się da. Wystarczy poszukać w sieci trochę głębiej niż po nagłówkach w Google.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

pytanie tylko po co? po to zostal zaimplementowany w kernelu taki a nie inny sposob, zeby robic to porzadnie a nie prowizorycznie.
zamiast ladowac te pakiety "na chama" w jakis interface to puszczasz je przez tun/tap i kernel je otrzymuje tak jakby przyszly z karty sieciowej , co za tym idzie trafiaja one normalnie do firewalla , i lataja po sieci zgodnie z tabela routingu i jest porzadek.

sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,

jezeli bedziesz chcial zarzadzac tym ruchem to co, bedziesz implementowal w swoim programie filtrowanie jak iptables?, mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac prgram itd, kto nad tym zapanuje?
Z tego co zrozumiałem TUN/TAP wymaga utworzenia dodatkowych wirtualnych urządzeń - nie da się zrobić tego inaczej?
kiedys ktos inteligentny zauwazyl ze urzadzenia zasadniczo ulatwiaja zycie, pewnie dlatego sie ich nadal uzywa ;)
latwiej otworzyc plik urzadzenia i do niego pisac, niz przkopywac tone dokumentacji , implementowac jakies struktury ,ladowac biblioteki itd tracac czas na samo dostanie sie do czegos co ma byc tylko narzedziem z ktorego chcesz skorzystac.
poswiec swoj czas na rozwoj twojego prgramu a nie na zglebianie czyjegos ;)

no i libpcap itd to dodatkowe zaleznosci dla twojego programu a tun/tap siedzi w kernelu.
Awatar użytkownika
dozzie
Użytkownik
Posty: 855
Rejestracja: 2004-06-01, 13:15
Lokalizacja: Wrocław
Kontakt:

Re: Tworzenie (generowanie) pakietu IP

Post autor: dozzie »

kazalot pisze:pytanie tylko po co? po to zostal zaimplementowany w kernelu taki a nie inny sposob, zeby robic to porzadnie a nie prowizorycznie.
Po co? Żeby nie robić ze swojej maszyny routera, ot po co.
kazalot pisze:sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,
Ę? Że jak proszę?
kazalot pisze:mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac prgram itd, kto nad tym zapanuje?
Konfiguracja, to chyba oczywiste? Nie wiem ile masz programów na koncie, ale adresów IP nigdy nie wkompilowuje się na sztywno, chyba że jako defaulty.
kazalot pisze:
Z tego co zrozumiałem TUN/TAP wymaga utworzenia dodatkowych wirtualnych urządzeń - nie da się zrobić tego inaczej?
kiedys ktos inteligentny zauwazyl ze urzadzenia zasadniczo ulatwiaja zycie, pewnie dlatego sie ich nadal uzywa ;)
latwiej otworzyc plik urzadzenia i do niego pisac, niz przkopywac tone dokumentacji , implementowac jakies struktury ,ladowac biblioteki itd tracac czas na samo dostanie sie do czegos co ma byc tylko narzedziem z ktorego chcesz skorzystac.
Nadal nie wiem ile masz programów na koncie, ale jeśli uważasz, że TUN/TAP znacząco skraca ilość kodu potrzebną do wypuszczenia dowolnie skonstruowanego pakietu w sieć w porównaniu z czymkolwiek, od libnet po surowe gniazda, to nie masz pojęcia o czym mówisz.
kazalot pisze:no i libpcap itd to dodatkowe zaleznosci dla twojego programu a tun/tap siedzi w kernelu.
Nie w każdym. Nie zawsze jest jak przebudować kernel. Nie zawsze potrzebne jest wypuszczenie pakietu zgodnie z tablicą routingu. Nie zawsze program jest docelowym (jedynym) odbiorcą pakietu. Nie zawsze wystarczy dowolny pakiet IP, czasem potrzebna jest ramka ethernetowa.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

dozzie pisze: Po co? Żeby nie robić ze swojej maszyny routera, ot po co.
rownie dobrze mogles napisac , "dlatego ze to semantyczne naduzycie" mniejwiecej takie znaczenie ma twoja wypowiedz, nic z niej nie wynika.
dozzie pisze: kazalot napisał/a:
sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,

Ę? Że jak proszę?
Ą , Że tak
chetnie z toba podyskutuje , tylko zacznij przedstawiac argumenty a nie wydawac z siebie onomatopeje ;)
dozzie pisze: kazalot napisał/a:
mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac prgram itd, kto nad tym zapanuje?

Konfiguracja, to chyba oczywiste? Nie wiem ile masz programów na koncie, ale adresów IP nigdy nie wkompilowuje się na sztywno, chyba że jako defaulty.
no pierwsza wypowiedz w ktorej mozna doszukac sie jakiegos argumentu. szkoda tylko ze urwales moja wypowiedz, calosc brzmi
kazalot pisze: jezeli bedziesz chcial zarzadzac tym ruchem to co, bedziesz implementowal w swoim programie filtrowanie jak iptables?, mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac program itd, kto nad tym zapanuje?
jasne mozna zrobic konfiguracje , podawac indywidualene adresy jakie maja byc przesylane,adres oraz maske podsieci i na jej podstawie zaimplementowac w programie sprawdzanie czy pakiet nalezy przeslac czy nie itd...

nigdzie nie powiedzialem ze nie mozna, mozna tylko po co? jezeli zostalo to juz zaimplementowane, jest wiele wygodnych narzedzi (ifconfig, route itd), i raczej nie zrobisz tego optymalniej a napewno stracisz na to czas ktory moglbys poswiecic na swoj program.

jezeli bedzie trzeba, sprawdzic jaki ruch jest generowany na tym tunelu to przeciez mozesz zrobic zliczanie pakietow, jakos ladnie sobie to wyswietlac itp. ale latwiej i szybciej jest skorzystac z tego co zostalo juz zrobione, przez lata dopracowane i poprostu obejrzec statystyke interfejsu.

napisz sobie i caly system operacyjny jezeli cie to kreci , ale jezeli twoim celem jest wyslanie tylko jakiegos pakietu a nie napisanie systemu to naprawde szybciej bedzie skorzystac z istniejacego juz systemu.
dozzie pisze: Nadal nie wiem ile masz programów na koncie,

"ile masz programów na koncie" - to takie dziecinne, niczym mlody kierowca swiezo po zdanym egzaminie, z duma chwalacy sie ze z jego skrzetnie prowadzonych obliczen wynika ze "zrobil juz 10tys km", i zaczepnie pyta kogos kto 15lat ma prawo jazdy "a ile ty zrobiles?" :)
dozzie pisze: ale jeśli uważasz, że TUN/TAP znacząco skraca ilość kodu potrzebną do wypuszczenia dowolnie skonstruowanego pakietu w sieć w porównaniu z czymkolwiek, od libnet po surowe gniazda, to nie masz pojęcia o czym mówisz.
moze faktycznie nie wiem,a moze poprostu kiedys dokladniej niz ty przeczytalem w ksiazce do nauki programowania rozdzial na temat obslugi plikow, i nie sa one dlamnie tajemnica.

wpuszczenie pakietu przez tun/tap wyglada mniejwiecej tak

Kod: Zaznacz cały

char packet[] = {0x45,0x00,0x00,0x3c,...};   //pakiet ktory chcemy wyslac
fd = open("/dev/net/tun", O_RDWR)             //otworzenie pliku
    ifr.ifr_flags = IFF_TUN;                   //wybranie czy chcemy 
ioctl(fd, TUNSETIFF, (void *) &ifr)      //uzywac  tun czy tap
write (fd, packet, (sizeof(packet)/sizeof(char)) );                       //wpisanie pakietu do pliku 
close(fd)                                                    //zamkniecie pliku
i nawet nie chodzi o to ze nie trzeba zadnych bibliotek linkowac itd, tego kodu bedzie mniej dlatego ze nie musimy w programie filtrowac pakietow, zadnego adresu konfigurowac ani zadnych innych ustawien sieciowych, zostaje stworzony interfejs ktory konfigurujemy narzedziami systemowymi.
dozzie pisze: kazalot napisał/a:
no i libpcap itd to dodatkowe zaleznosci dla twojego programu a tun/tap siedzi w kernelu.

Nie w każdym. Nie zawsze jest jak przebudować kernel. Nie zawsze potrzebne jest wypuszczenie pakietu zgodnie z tablicą routingu. Nie zawsze program jest docelowym (jedynym) odbiorcą pakietu. Nie zawsze wystarczy dowolny pakiet IP, czasem potrzebna jest ramka ethernetowa.
prawda, czasami trzeba wstrzyknac gdzies jakis pakiet o zadanych parametrach , pomijajac tablice routingu itd,
tak samo jak czasami trzeba wczytac np bezposrednio dane z klawiatury i zaimplementowac do tego sterowanie, ale jezeli ktos chce tylko wczytac "zuzia" z klawiatury to naprawde lepszym rozwiazaniem jest uzycie scanf.
Awatar użytkownika
dozzie
Użytkownik
Posty: 855
Rejestracja: 2004-06-01, 13:15
Lokalizacja: Wrocław
Kontakt:

Re: Tworzenie (generowanie) pakietu IP

Post autor: dozzie »

kazalot pisze:
dozzie pisze: Po co? Żeby nie robić ze swojej maszyny routera, ot po co.
rownie dobrze mogles napisac , "dlatego ze to semantyczne naduzycie" mniejwiecej takie znaczenie ma twoja wypowiedz, nic z niej nie wynika.
Nie każda maszyna powinna robić za router. Jakikolwiek router.
kazalot pisze:
dozzie pisze: kazalot napisał/a:
sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,

Ę? Że jak proszę?
Ą , Że tak
chetnie z toba podyskutuje , tylko zacznij przedstawiac argumenty a nie wydawac z siebie onomatopeje ;)
Podsumujmy to zdanie. Wynika z niego, że ręczne utworzenie pakietu i wpuszczenie go w sieć takiego, jakim został stworzony pozbawia twórcę pakietu kontroli nad tym pakietem.
To jest jawna bzdura.
kazalot pisze:
dozzie pisze: kazalot napisał/a:
mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac prgram itd, kto nad tym zapanuje?

Konfiguracja, to chyba oczywiste? Nie wiem ile masz programów na koncie, ale adresów IP nigdy nie wkompilowuje się na sztywno, chyba że jako defaulty.
no pierwsza wypowiedz w ktorej mozna doszukac sie jakiegos argumentu. szkoda tylko ze urwales moja wypowiedz, calosc brzmi
Ale co dalsza część niby wnosi do tematu konieczności rekompilacji programu dla zmiany adresu? Bo ja tam nic nie widzę.
kazalot pisze:
kazalot pisze: jezeli bedziesz chcial zarzadzac tym ruchem to co, bedziesz implementowal w swoim programie filtrowanie jak iptables?, mala zmiana adresow w sieci i musisz poprawiac zrodla,rekompilowac program itd, kto nad tym zapanuje?
jasne mozna zrobic konfiguracje , podawac indywidualene adresy jakie maja byc przesylane,adres oraz maske podsieci i na jej podstawie zaimplementowac w programie sprawdzanie czy pakiet nalezy przeslac czy nie itd...

nigdzie nie powiedzialem ze nie mozna, mozna tylko po co?
Bo czasem to jest potrzebne. Ot, po co. Często nakład administracyjny potrzebny do użycia interfejsów TUN/TAP jest dużo większy niż użycie surowych gniazd. Ty po prostu próbujesz przykładać do siebie dwie różne rzeczy służące do różnych celów.
kazalot pisze:jezeli zostalo to juz zaimplementowane, jest wiele wygodnych narzedzi (ifconfig, route itd), i raczej nie zrobisz tego optymalniej a napewno stracisz na to czas ktory moglbys poswiecic na swoj program.
Użycie surowych gniazd, twoim zdaniem, jest bardzo trudne? Kosztowniejsze niż utworzenie interfejsu, nadanie mu adresu, ustawienie trasy i forwardowania i dopiero wpuszczenie pakietu?
kazalot pisze:jezeli bedzie trzeba, sprawdzic jaki ruch jest generowany na tym tunelu to przeciez mozesz zrobic zliczanie pakietow, jakos ladnie sobie to wyswietlac itp. ale latwiej i szybciej jest skorzystac z tego co zostalo juz zrobione, przez lata dopracowane i poprostu obejrzec statystyke interfejsu.
Ale na razie nie wiemy, co OP chce zrobić. Jakoś nie wspominał ani słowem o zliczaniu traffiku. Zresztą nie widzę najmniejszego powodu, dla którego jakieś zliczanie traffiku lub traffic shaping miałby nie działać na surowych gniazdach.
kazalot pisze:napisz sobie i caly system operacyjny jezeli cie to kreci , ale jezeli twoim celem jest wyslanie tylko jakiegos pakietu a nie napisanie systemu to naprawde szybciej bedzie skorzystac z istniejacego juz systemu.
Zgadza się. Z surowych gniazd na przykład. Albo z libnet. Tylko dlaczego upierasz się przy jednym z kosztowniejszych administracyjnie rozwiązań?
kazalot pisze:
dozzie pisze: Nadal nie wiem ile masz programów na koncie,

"ile masz programów na koncie" - to takie dziecinne, niczym mlody kierowca swiezo po zdanym egzaminie, z duma chwalacy sie ze z jego skrzetnie prowadzonych obliczen wynika ze "zrobil juz 10tys km", i zaczepnie pyta kogos kto 15lat ma prawo jazdy "a ile ty zrobiles?" :)
Rozumiem w takim razie, że programistą nie jesteś.
kazalot pisze:
dozzie pisze: ale jeśli uważasz, że TUN/TAP znacząco skraca ilość kodu potrzebną do wypuszczenia dowolnie skonstruowanego pakietu w sieć w porównaniu z czymkolwiek, od libnet po surowe gniazda, to nie masz pojęcia o czym mówisz.
moze faktycznie nie wiem,a moze poprostu kiedys dokladniej niz ty przeczytalem w ksiazce do nauki programowania rozdzial na temat obslugi plikow, i nie sa one dlamnie tajemnica.
O, to jeszcze pliki tu jakieś się pojawiają? Druga Platyna, co to uważa, że interfejs eth0 jest plikiem?
kazalot pisze:wpuszczenie pakietu przez tun/tap wyglada mniejwiecej tak

Kod: Zaznacz cały

char packet[] = {0x45,0x00,0x00,0x3c,...};   //pakiet ktory chcemy wyslac
fd = open("/dev/net/tun", O_RDWR)             //otworzenie pliku
    ifr.ifr_flags = IFF_TUN;                   //wybranie czy chcemy 
ioctl(fd, TUNSETIFF, (void *) &ifr)      //uzywac  tun czy tap
write (fd, packet, (sizeof(packet)/sizeof(char)) );                       //wpisanie pakietu do pliku 
close(fd)                                                    //zamkniecie pliku
i nawet nie chodzi o to ze nie trzeba zadnych bibliotek linkowac itd, tego kodu bedzie mniej dlatego ze nie musimy w programie filtrowac pakietow, zadnego adresu konfigurowac ani zadnych innych ustawien sieciowych, zostaje stworzony interfejs ktory konfigurujemy narzedziami systemowymi.
I ten program będzie działać, tak? Nawet jeśli dopiszę brakujące include'y i deklaracje? Trochę nie bałdzo. Ot, interfejs nie zostanie podniesiony, nie zostanie mu nadany adres IP, trzeba będzie jeszcze włączyć forwardowanie pakietów dla tego interfejsu i dla interfejsów na świat... Samo się nie zrobi. Zrzucisz to wszystko na użytkownika? Twoje "mniej więcej" wymaga jeszcze masy roboty.

Teraz pora na moje "mnóstwo niepotrzebna koda nienadająca się do opiekowanie".

Kod: Zaznacz cały

#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <netinet/if_ether.h>
#include <netinet/in.h>

#define MAKE_IP(a, b, c, d) ((a << 24) | (b << 16) | (c << 8) | d)

int main(void)
{
  // ping wp.pl
  char packet[] = {
    0x45, 0x00, 0x00, 0x54, 0x00, 0x00, 0x40, 0x00, 0x40, 0x01, 0xf7, 0xea,
    0x0a, 0x02, 0x00, 0x0a, // moj adres, 10.2.0.10
    0xd4, 0x4d, 0x64, 0x65, // wp.pl, 212.77.100.101
    0x08, 0x00, 0x15, 0x3c,
    0x0b, 0x65, 0x00, 0x01, 0xfb, 0xda, 0x56, 0x46, 0x95, 0x39, 0x05, 0x00,
    0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13,
    0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
    0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
    0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37
  };

  struct sockaddr_in dest = {
    AF_INET, 0, { MAKE_IP(212, 77, 100, 101) }
  };

  int fd = socket(PF_INET, SOCK_RAW, IPPROTO_RAW);

  if (fd < 0) {
    perror("socket()");
    return 1;
  }

  int q = sendto(fd, packet, sizeof(packet), 0,
                 (struct sockaddr *)&dest, sizeof(struct sockaddr_in));
  if (q < 0)
    perror("sendto()");

  close(fd);

  return 0;
}
Po pierwsze, mój kod jest krótszy od twojego (pomijając pełną definicję pakietu IP włącznie z adresami i obsługę błędów). Po drugie, działa bezpośrednio po skompilowaniu (a kompiluje się bez warningów na -Wall -std=c99). Po trzecie, nie wymaga żadnych dodatkowych bibliotek. Po czwarte, nie wymaga żadnego dodatkowego nakładu pracy na konfigurację dodatkowych interfejsów.

Co powiesz na to, mój ty mały geniuszku?
Ostatnio zmieniony 2007-05-25, 14:55 przez dozzie, łącznie zmieniany 1 raz.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
thopass
Użytkownik
Posty: 173
Rejestracja: 2005-01-08, 13:48
Lokalizacja: Warszawa

Re: Tworzenie (generowanie) pakietu IP

Post autor: thopass »

Dziękuję Wam obu za odzew, instrukcje i dobre rady.
Ostatecznie zdecydowałem się na RAW sockety (mój kod może jest mniej elegancki niż dozzie'go ale już działa i wystarczy go uporządkować) i chyba przy tym rozwiązaniu zostanę.
Rozwiązanie z TUN/TAP w moim przypadku nie jest najlepsze ponieważ komp, na którym ma to zadziałać, nie jest mój i nie mogę sie tam bawić kernelem.
Podsumowując: piszę dalej i mam nadzieję, że przez moje pytanie nie rozpęta się wojna na linii dozzie==kazalot.

Pozdrawiam
Ostatnio zmieniony 2007-05-25, 15:47 przez thopass, łącznie zmieniany 1 raz.
Slackware Current + kernel 2.6.32.6 + KDE 3.5.10
registered linux user #412954

[url=http://userbars.org][img]http://img162.imageshack.us/img162/9958/linux1hf8.jpg[/img][/url]
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

dozzie pisze: Nie każda maszyna powinna robić za router. Jakikolwiek router.
co rozumiesz przez router? prawie kazdy komputer jaki dziala w sieci ma table routingu i kieruje jakos pakiety a wiec jest i routerem.
poza tym myslisz ze jak nie uzyjesz systemowej tabeli routingu tylko na podstawie swojego widzimisie bedziesz kierowal pakiety to to nie jest routing?to niby co to jest?
byc moze poprostu nie do konca rozumiesz znaczenie slowa routing.

poza tym thopass podal ze program ma dzialac na routerze.
dozzie pisze: Podsumujmy to zdanie. Wynika z niego, że ręczne utworzenie pakietu i wpuszczenie go w sieć takiego, jakim został stworzony pozbawia twórcę pakietu kontroli nad tym pakietem.
To jest jawna bzdura.
ja naprawde rozwinalem i uzasadnilem moj punkt widzenia , postaraj sie skupic i przeczytac ze zrozumieniem co napisalem.
sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,
jezeli bedziesz chcial zarzadzac tym ruchem to co, bedziesz implementowal w swoim programie filtrowanie jak iptables?
chyba jasno wynika z mojej wypowiedzi ze chodzi o kontrole na poziomie narzedzi systemowych takich jak iptables.
i nie chodzi o samo wysylanie, bo program ktory pisze thopass nie jest programem ktorego celem jest wysylanie pakietu, tylko zestawienie polaczenia miedzy 2 sieciami.

problem kontroli pojawia sie juz na wstepie (o czym pisalem) przy odczytywaniu pakietow, sposob ktory przyjeliscie zmusza was do implementacji filtrowania pakietow, a ja uwazam ze lepiej skorzystac z gotowych rozwiazan.

dozzie pisze: Bo czasem to jest potrzebne. Ot, po co.
no genialna odpowiedz brawo

przeciez napisalem
prawda, czasami trzeba wstrzyknac gdzies jakis pakiet o zadanych parametrach , pomijajac tablice routingu itd,
tak samo jak czasami trzeba wczytac np bezposrednio dane z klawiatury i zaimplementowac do tego sterowanie, ale jezeli ktos chce tylko wczytac "zuzia" z klawiatury to naprawde lepszym rozwiazaniem jest uzycie scanf.
tak czasami trzeba , autor napisal co chce osiagnac i w tym przypadku uwazam ze jest to nie potrzebne, a nawet z punktu widzenia administratora nie wskazane.
tunel to zagadnienie laczenia segmentow sieci , tak jak mosty czy switche i na tych samych zasadach powinno sie tym administrowac , majac do dyspozycji porzadne narzedzia.
Ty po prostu próbujesz przykładać do siebie dwie różne rzeczy służące do różnych celów.
no swietnie caly czas probuje wam to przekazac , ze to "dwie różne rzeczy służące do różnych celów" i uwazam ze do realizacji celu o ktorym mowi thopass czyli polaczeniu 2 sieci lepiej nadaje sie tun/tap


dozzie pisze: kazalot napisał/a:
jezeli zostalo to juz zaimplementowane, jest wiele wygodnych narzedzi (ifconfig, route itd), i raczej nie zrobisz tego optymalniej a napewno stracisz na to czas ktory moglbys poswiecic na swoj program.

Użycie surowych gniazd, twoim zdaniem, jest bardzo trudne? Kosztowniejsze niż utworzenie interfejsu, nadanie mu adresu, ustawienie trasy i forwardowania i dopiero wpuszczenie pakietu?
a czy ja napisalem w ktoryms momencie ze jest trudne? jest proste i dobrze zorganizowane.
dlaczego ty to rozpatrujesz jakby dla ciebie problemem bylo samo stworzenie takiego gniazda czy sama obsluga tun/tap, ja caly czas pisze o tym co bedziesz musial zaimplementowac sam w programie jezeli zrobisz to na gniazdach, a czego nie bedziesz jezeli zrobisz to na tun/tap.

dozzie pisze: Często nakład administracyjny potrzebny do użycia interfejsów TUN/TAP jest dużo większy niż użycie surowych gniazd.
naklad administracyjny potrzebny do uzycia interfejsow tun/tap jest taki sam jak do uzycia interfejsow eth, jest to w zasadzie to samo i nadal nie rozumiem dlaczego chcesz polaczenie 2 sieci rozpatrywac jako jakis twor z kosmosu.

dozzie pisze: Zgadza się. Z surowych gniazd na przykład. Albo z libnet. Tylko dlaczego upierasz się przy jednym z kosztowniejszych administracyjnie rozwiązań?
bo robilem to tak i tak , i uwazam ze tun/tap jest nieporownywalnie lepsze, szybsze i latwiejsze w administrowaniu.
dozzie pisze: Rozumiem w takim razie, że programistą nie jesteś.
oczywiscie , jestem hodowca drobiu to chyba logiczne :)
dozzie pisze: O, to jeszcze pliki tu jakieś się pojawiają? Druga Platyna, co to uważa, że interfejs eth0 jest plikiem?
nie wiem co oznacza tytul drugiej platyny , ale sadzac z kontekstu twojej wypowiedzi chciales mnie obrazic, no nie udalo ci sie bo przyzwyczajony jestem ze jak komus sie koncza argumenty to siega po wyzwiska.

nigdzie nie pisalem o eth0 , caly czas pisze o tun/tap. ta technologia polega na tym ze jezeli program otworzy plik tun , to zostanie stworzony interfejs ktory bedzie istnial dopuki plik nie zostanie zamkniety.
interfejs dziala na tej samej zasadzie co eth0 z ta roznica ze caly ruch jaki jest na interfejsie mozna czytac z pliku tun, a zeby cos wyslac wystarczy to do pliku napisac.
lopatologicznie mowiac sa 2 mozliwosci wyslania czegos do komputera przez dany interfejs tun, albo wysylajac to na sam interfejs tak jak na eth0 (np ping -I tun0) lub przez wpisanie pakietu do pliku /dev/net/tun.

czyli najprostsze rozwiazanie problemu o ktorym pisal thopass czytanie z pliku /dev/net/tun, zakodowanie czy co tam autor sobie chce z tym zrobic i wysylanie gniazdem (tak do tego zastosowania, gniazdo jest bardzo dobre) jego zawartosci do 2 routera, gdzie to co przyjdzie z gniazda jest rozkodowywane i wpisywane do pliku /dev/net/tun i to samo w drugim kierunku - caly program.

w obydwu systemach pojawi sie interfejs o nazwie np tun0 ktory bedzie sie zachowywal jak eth0, a dla systemu komunikacja wygladac bedzie jak gdyby routery byly polaczone bezposrednio skretka.
I ten program będzie działać, tak? Nawet jeśli dopiszę brakujące include'y i deklaracje? Trochę nie bałdzo. Ot, interfejs nie zostanie podniesiony, nie zostanie mu nadany adres IP, trzeba będzie jeszcze włączyć forwardowanie pakietów dla tego interfejsu i dla interfejsów na świat... Samo się nie zrobi. Zrzucisz to wszystko na użytkownika? Twoje "mniej więcej" wymaga jeszcze masy roboty.
jakiego uzytkownika? mowimy o polaczeniu sieci , tym zajmuje sie administrator, chyba kazdy administrator wolalby administrowac polaczeniem ktore jest widoczne jak zwykle ethernetowe.
szczerze mowiac nie sadze zebys znalazl administratora ktory chcialby administrowac segmentem sieci dla ktorego zrobiles swoja wlasna "konfiguracje" do filtrowania i zarzadzania,
no chyba ze to jakis "administrator domeny windows" czym kolwiek by to nie bylo , oni lubia takie rzeczy , im cos bardziej udziwnione, tajemnicze, stworzone metodami chalupniczymi i wbrew przyjetym konwencjom tym bardziej "trendy" ;)
Po pierwsze, mój kod jest krótszy od twojego (pomijając pełną definicję pakietu IP włącznie z adresami i obsługę błędów). Po drugie, działa bezpośrednio po skompilowaniu (a kompiluje się bez warningów na -Wall -std=c99). Po trzecie, nie wymaga żadnych dodatkowych bibliotek. Po czwarte, nie wymaga żadnego dodatkowego nakładu pracy na konfigurację dodatkowych interfejsów.
tak jedyna roznica to to ze musisz zaimplementowac sam filtrowanie i zarzadzanie tym ruchem(zwane przez ciebie konfiguracja) a przy tun/tap korzystasz z dostepnych dla eth0 narzedzi i o tym uproszczeniu caly czas mowie.
robilem to kiedys na gniazdach i kiedy zrobilem to na tun/tap to stwierdzilem ze zmarnowalem czas z socetami.
thopass pisze: Rozwiązanie z TUN/TAP w moim przypadku nie jest najlepsze ponieważ komp, na którym ma to zadziałać, nie jest mój i nie mogę sie tam bawić kernelem.
rozumiem, jezeli nie mozesz go uzyc to trudno "jak sie nie ma co sie lubi to sie lubi co sie ma".
jezeli to serwer na ktorym ludzie pracuja to pewnie tun/tap tam masz, bo opiera sie na tym openvpn i chyba wiekszosc rozwiazan tunelowych.

reasumujac , wszystko da sie zrobic , tylko jak zrobisz to na gniazdach to nie zdziw sie ze przekierowanie portu z zewnetrznego adresu sieci A na wewnetrzny adres sieci B z prostej regulki urasta do problemu programistycznego, a pewnie odkryjesz to jak bedziesz przekierowanie potrzebowal na wczoraj.
thopass pisze: mam nadzieję, że przez moje pytanie nie rozpęta się wojna
ja nie mam zamiaru z nikim walczyc, w imie czego? nigdzie nie twierdze ze ktos sie myli lub ze ja mam racje, dziele sie jedynie moimi doswiadczeniami z uzytkowania obydwu rozwiazan, a to czy ktos skorzysta z tego czy nie to jego sprawa.

cala dyskusja rozwinela sie dlatego ze dozzie zaczal probowac odpowiedziec na moje pytanie retoryczne "tylko po co?" ktore zawarlem w poscie skierowanym do ciebie.

w sumie nadal nie wiem jakie jest jego stanowisko w tej sprawie i nie poznalem zadnego argumentu z jego strony ktory bylby za lub przeciw danemu rozwiazaniu, oprocz tego ze mu sie cos kompiluje bez warningow.
Awatar użytkownika
dozzie
Użytkownik
Posty: 855
Rejestracja: 2004-06-01, 13:15
Lokalizacja: Wrocław
Kontakt:

Re: Tworzenie (generowanie) pakietu IP

Post autor: dozzie »

kazalot pisze:
dozzie pisze: Nie każda maszyna powinna robić za router. Jakikolwiek router.
co rozumiesz przez router?
Dokładnie to, co każdy znający się na sieciach choć trochę. Czyli węzeł, który przekazuje cudze pakiety nie zaadresowane do tego węzła.
kazalot pisze:prawie kazdy komputer jaki dziala w sieci ma table routingu i kieruje jakos pakiety a wiec jest i routerem.
Nieprawda.
kazalot pisze:poza tym myslisz ze jak nie uzyjesz systemowej tabeli routingu tylko na podstawie swojego widzimisie bedziesz kierowal pakiety to to nie jest routing?
Dlaczego "nie użyjesz systemowej tablicy routingu"?
kazalot pisze:
dozzie pisze: Podsumujmy to zdanie. Wynika z niego, że ręczne utworzenie pakietu i wpuszczenie go w sieć takiego, jakim został stworzony pozbawia twórcę pakietu kontroli nad tym pakietem.
To jest jawna bzdura.
ja naprawde rozwinalem i uzasadnilem moj punkt widzenia , postaraj sie skupic i przeczytac ze zrozumieniem co napisalem.
O nie, mój drogi. Teraz ty postaraj się zrozumieć, co napisałeś. Stwierdziłeś, że tworząc pakiet ręcznie traci się nad nim kontrolę (a raczej że nie ma się nad nim kontroli).
kazalot pisze:
sposob ktorym ty chcesz to zrobic jest nieporzadny, nie daje ci kontroli nad tymi pakietami,
jezeli bedziesz chcial zarzadzac tym ruchem to co, bedziesz implementowal w swoim programie filtrowanie jak iptables?
chyba jasno wynika z mojej wypowiedzi ze chodzi o kontrole na poziomie narzedzi systemowych takich jak iptables.
Owszem, nie wynika to z twojej wypowiedzi.
A nawet gdyby wynikało, to bredzisz. Nigdy nie widziałeś komunikatu błędu wysyłania pakietu ICMP echo request przy nadmiernie restrykcyjnym firewallu? Nie? To już nie mój problem. A spróbuj zgadnąć, czego używa /bin/ping do utworzenia i wysłania pakietu.
kazalot pisze:i nie chodzi o samo wysylanie, bo program ktory pisze thopass nie jest programem ktorego celem jest wysylanie pakietu, tylko zestawienie polaczenia miedzy 2 sieciami.
Racja. Twoje rozwiązanie, pchanie pakietów jeszcze dodatkowo po interfejsach TUN/TAP, to jawna kpina. Tak naprawdę powinno to zostać zrobione prostym routingiem.

kazalot pisze:
Ty po prostu próbujesz przykładać do siebie dwie różne rzeczy służące do różnych celów.
no swietnie caly czas probuje wam to przekazac , ze to "dwie różne rzeczy służące do różnych celów" i uwazam ze do realizacji celu o ktorym mowi thopass czyli polaczeniu 2 sieci lepiej nadaje sie tun/tap
Ale nie w sposób, w jaki ty go proponujesz używać. A już na pewno nie do wstrzykiwania dowolnych pakietów gdziekolwiek, co starałeś się nam tu wmówić.


kazalot pisze:a czy ja napisalem w ktoryms momencie ze jest trudne? jest proste i dobrze zorganizowane.
dlaczego ty to rozpatrujesz jakby dla ciebie problemem bylo samo stworzenie takiego gniazda czy sama obsluga tun/tap, ja caly czas pisze o tym co bedziesz musial zaimplementowac sam w programie jezeli zrobisz to na gniazdach, a czego nie bedziesz jezeli zrobisz to na tun/tap.
No to proszę, co takiego w moim programie do wysyłania ICMP echo request trzeba jeszcze zaimplementować, żeby wybierał trasę domyślną? Co najwyżej trzeba wyzerować w tworzonym pakiecie pole IP sender address, żeby system sam je wypełnił.
kazalot pisze:
dozzie pisze: Często nakład administracyjny potrzebny do użycia interfejsów TUN/TAP jest dużo większy niż użycie surowych gniazd.
naklad administracyjny potrzebny do uzycia interfejsow tun/tap jest taki sam jak do uzycia interfejsow eth, jest to w zasadzie to samo
Owszem, użycie jednego interfejsu TUN/TAP jest tak samo kosztowne jak użycie jednego interfejsu ethernetowego. Problem w tym, że do wysyłania pakietów tak czy siak potrzebujesz interfejsu ethernetowego, a przy użyciu TUN/TAP potrzebujesz dodatkowo interfejsu TUN/TAP. Czyli koszt administracyjny nagle wzrasta w porównaniu z raw socket.
kazalot pisze:
dozzie pisze: Zgadza się. Z surowych gniazd na przykład. Albo z libnet. Tylko dlaczego upierasz się przy jednym z kosztowniejszych administracyjnie rozwiązań?
bo robilem to tak i tak , i uwazam ze tun/tap jest nieporownywalnie lepsze, szybsze i latwiejsze w administrowaniu.
...niż surowe gniazda, których nie trzeba konfigurować, które poddają się procesowi routingu i filtrowania, które nie zajmują tak wielu zasobów systemu, którym nie trzeba nadawać kolejnych adresów IP (ja na swoim laptopie używam stale adresów z trzech różnych podsieci; gdybym miał jeszcze dodawać osiemnaście kolejnych przy każdym testowaniu sieci...)
kazalot pisze:
dozzie pisze: O, to jeszcze pliki tu jakieś się pojawiają? Druga Platyna, co to uważa, że interfejs eth0 jest plikiem?
nie wiem co oznacza tytul drugiej platyny , ale sadzac z kontekstu twojej wypowiedzi chciales mnie obrazic, no nie udalo ci sie bo przyzwyczajony jestem ze jak komus sie koncza argumenty to siega po wyzwiska.
A ja jestem przyzwyczajony do tego, że jak komuś się kończą argumenty, to zaczyna się wszędzie dopatrywać wycieczek osobistych.
kazalot pisze:ta technologia polega na tym ze jezeli program otworzy plik tun[...]

czyli najprostsze rozwiazanie problemu o ktorym pisal thopass czytanie z pliku /dev/net/tun, zakodowanie czy co tam autor sobie chce z tym zrobic[...]
Proszę się douczyć znaczeń słów "technologia", "kodowanie" i "szyfrowanie", jak również pisowni słowa "dopóki".

I twoje rozwiązanie polega na tym, żeby odebrać z interfejsu pakiet, puścić go do innego interfejsu i pozwolić mu zostać przeroutowanym do trzeciego interfejsu. Nie powiem, bardzo to przypomina klasyczny routing, o jaki autorowi chodziło. To już raw sockets jest lepsze.
kazalot pisze:
Po pierwsze, mój kod jest krótszy od twojego (pomijając pełną definicję pakietu IP włącznie z adresami i obsługę błędów). Po drugie, działa bezpośrednio po skompilowaniu (a kompiluje się bez warningów na -Wall -std=c99). Po trzecie, nie wymaga żadnych dodatkowych bibliotek. Po czwarte, nie wymaga żadnego dodatkowego nakładu pracy na konfigurację dodatkowych interfejsów.
tak jedyna roznica to to ze musisz zaimplementowac sam filtrowanie i zarzadzanie tym ruchem
ROTFL. Doczytać o surowych gniazdach i poeksperymentować na nich przed dalszą dyskusją.
kazalot pisze:w sumie nadal nie wiem jakie jest jego stanowisko w tej sprawie i nie poznalem zadnego argumentu z jego strony ktory bylby za lub przeciw danemu rozwiazaniu, oprocz tego ze mu sie cos kompiluje bez warningow.
Zapytajmy osoby postronnej, co uważa o twoim pomyśle routowania pakietu przez trzy interfejsy podczas gdy potrzebne jest proste dodanie trasy. I co uważa o twoim pomyśle, że łatwiej konstruować i wypuszczać w sieć dowolne pakiety przez TUN/TAP niż surowe gniazda.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

przekonales mnie
masz racje, tun/tap i openvpn sa do kitu,robia tylko balagan w interfejsach,
do virtual private network duzo lepsze jest sniffowanie przez libpcap i surowe gniazda :ok:
od dzis zaczne nawracac wszystkich znajomych ktorzy nieswiadomie traca czas uzywajac bezsensownego tun/tap i openvpn do tego :)
Awatar użytkownika
dozzie
Użytkownik
Posty: 855
Rejestracja: 2004-06-01, 13:15
Lokalizacja: Wrocław
Kontakt:

Re: Tworzenie (generowanie) pakietu IP

Post autor: dozzie »

kazalot pisze:przekonales mnie
masz racje, tun/tap i openvpn sa do kitu,robia tylko balagan w interfejsach,
do virtual private network duzo lepsze jest sniffowanie przez libpcap i surowe gniazda :ok:
Teraz bredzisz. Nic takiego nie powiedziałem ani nie zasugerowałem. Zresztą męczy mnie dyskusja z osobą, której wydaje się że udaje kogoś o pewnej wiedzy.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
Awatar użytkownika
kazalot
Użytkownik
Posty: 1259
Rejestracja: 2006-04-05, 10:48

Re: Tworzenie (generowanie) pakietu IP

Post autor: kazalot »

dozzie pisze: A nawet gdyby wynikało, to bredzisz...Teraz bredzisz.
za naduzywanie slowa "bredzisz" na forum przysluguja punkciki, jezeli nie potrafisz kulturalnie prowadzic dyskusji to zapisz sie na wieczorne spotkania pod smietnikiem i tam rozwijaj swoj wyrafinowany jezyk , a nie na forum.

moja opinia jest jasna, uwazam ze do realizacji wirtualnej sieci prywatnej thopass powinien wykorzystac interfejs tun/tap.
taka jest moja opinia i mam do niej pelne prawo , jezeli sie ze mna nie zgadzasz (tez masz prawo do wlasnej opini) to to wyraz swoja opinie , ale na ten temat a nie opinie o mnie, o moich umiejetnosciach czy pogladach bo do tego nie masz prawa i za to tez naleza ci sie punkciki.
thopass
Użytkownik
Posty: 173
Rejestracja: 2005-01-08, 13:48
Lokalizacja: Warszawa

Re: Tworzenie (generowanie) pakietu IP

Post autor: thopass »

Szanowni koledzy.
Obaj przedstawiliście swoje punkty widzenia i swoje sposoby rozwiązania mojego problemu za co jestem Wam wdzięczny. Moje doświadczenie jest jednak zbyt małe, żeby oceniać, które z rozwiązań jest lepsze (zakładając, że rzeczywiście, któreś jest lepsze). Mogę tylko powiedzieć, że rozwiązanie z surowymi gniazdkami było łatwiejsze do zrozumienia i zaimplementowania przy moim poziomie zaawansowania.
Może jak się poduczę spróbuję z TUN/TAP'em i porównam z rozwiązaniem aktualnie użytym.

Natomiast teraz proponuję podać sobie ręce na zgodę i na zakończenie (jeśli można) proszę o jeszcze jedną wskazówkę:
nasłuchiwanie pcap'em na określonym interfejsie to nie problem jednak wysłanie surowym socketem (nie podłączonym do niczego, wysłanie przez sendto) nie pozwala mi wybrać gdzie pakiet ma być wysłany (wysyłam spreparowany nagłowek IP + dane) i wysyła nie w to łącze.
Nakierujecie mnie gdzie szukać rozwiązania? Czy muszę jednak bindować/connect'ować gniazdko?
Slackware Current + kernel 2.6.32.6 + KDE 3.5.10
registered linux user #412954

[url=http://userbars.org][img]http://img162.imageshack.us/img162/9958/linux1hf8.jpg[/img][/url]
ODPOWIEDZ