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.