Limit czasu wykreślania UDP

Question

Potrzebuję zaimplementować protokół UDP. Komputer PC musi nasłuchiwać w dedykowanym porcie UDP dla przychodzących pakietów. Wysyła również pakiet (odpowiedzi). Aplikacja działa w systemie Windows XP, 7, 8, ....

Zapora systemu Windows blokuje przychodzące pakiety. Można tego uniknąć przez dziurkowanie UDP. Więc muszę wysłać coś, co nie powinno boleć. Ale chcę jak najmniej przeszkadzać.

• Jak określić limit czasu, dopóki zapora nie zamknie otworu?
• Czy mogę wykryć, że zapora zamknęła zaporę ogniową, aby móc ponownie wysłać pakiet do otwierania? Oczywiście nie otrzymam niczego, gdy zapora zostanie zamknięta, ale może to mieć inne przyczyny.

Answer 1

Aby odpowiedzieć na własne pytanie: nie ma sposobu, aby ustalić limit czasu. Musisz poeksperymentować, jakiego czasu zapora systemu Windows 7 używa dla połączeń UDP. Obecne doświadczenie pokazuje czterosekundowy limit czasu, ale może się różnić.

kilka ogólnych wskazówek, dziurkowanie:

1. nie przeszkadzać żadnego innego hosta w sieci. Wyślij pakiet z treścią, która nie boli.
2. Nie trzeba wysyłać do hosta, który ma być nadawcą odpowiedzi.
3. Nie trzeba wysyłać do portu UDP, który ma być nadawcą. Wyślij do dowolnego portu UDP. Jest port odrzutów (9), który powinien ignorować wszystko, co wysyłasz.
4. Upewnij się, że pakiet jest naprawdę wysłany. Jeśli spróbujesz wysłać do hosta, który nie był widziany w ostatnim czasie, stos IP użyje protokołu ARP, aby uzyskać adres MAC. Jeśli stos IP nie otrzymuje odpowiedzi ARP, nie może wysłać i pakiet IP i nie ma dziurkowania. Ten problem można ominąć, wysyłając na adres sieciowy.
5. Upewnij się, że wybiłeś dziurę w pożądanej sieci przy użyciu adresu rozgłoszeniowego odpowiednich adapterów.

Answer 2

Kilka porad, dziurkowanie:

1. Na większości zapór (zakładam Zaporę systemu Windows, jak również) dziurkowanie pozwala tylko na konkretne IP, aby połączyć. Dziurkowanie wyłudza zapory/NAT w myśleniu, że komunikujesz się z określonym adresem IP, dzięki czemu możliwe jest przesyłanie pakietów z tego adresu IP. Jeśli chcesz słuchać dowolnego adresu IP, nie możesz skorzystać z dziurkowania bez komputera pomostowego, który może koordynować połączenie.
2. Czas może różnić się między zaporami i/lub NAT. Nie tylko musisz się martwić o zaporę programową (taką jak Zapora systemu Windows), ale jeśli masz zaporę sprzętową i/lub urządzenie NAT, musisz się także martwić o ten czas. Hardcoding wartość nie będzie działać, chyba że masz bardzo specyficzną konfigurację sieci i oprogramowania. Wykrywanie, że zapora zamknęła dziurę, brzmi jak świetny pomysł, z tym że większość zapór/NAT nie ma sposobu, aby wykryć, że zamknęli otwór i o ile wiem, nie ma dla ciebie dobrego sposobu program do wykrywania.
3. Aby wykonać dziurkowanie, będziesz musiał wysłać pakiety, które nie mają żadnej funkcji. Zwykle są to pakiety NOP (No OPeration) lub KEEP_ALIVE, które nie mają celu, a jeśli program je otrzymuje, po prostu je odrzuca.

Moja sugestia to wdrożenie pakietu KEEP_ALIVE, który program klienta ignoruje, oraz aby serwer okresowo wysyłał pakiet KEEP_ALIVE do klienta, aby zachować zaporę ogniową. Zakłada to, że znasz adres IP klienta, abyś mógł przesłać mu pakiety KEEP_ALIVE. Jeśli nie znasz jeszcze adresu IP klienta, musisz albo skonfigurować publiczny komputer pomostowy, albo wyłączyć zapory ogniowe dla twojego serwera. Zapora systemu Windows ma interfejs COM API lub polecenia netsh, za pomocą których program może nasłuchiwać połączeń. W przypadku sprzętowych zapór ogniowych/NAT, możesz spróbować użyć UPNP. Jeśli to nie zadziała, najlepiej jest poprosić użytkownika o otwarcie określonego portu dla twojego programu.

Answer 3

Oto jak zmierzyć to, ze netcata:

Na moim hosta Unix (Mac OS X Darwin), bez zapory (lub na komputerze z systemem Windows, gdzie zapora systemu Windows umożliwia netcata "NC" wykonywalny nasłuchiwać na portach UDP), uruchomić serwer UDP ze zmiennym opóźnieniem dostarczonych przez klientów zdalnych:

WINHOST=10.116.140.69 
mkfifo f 
nc -u -p 2222 $WINHOST 6666 < f | \ 
(while read secs; do for sec in $secs; do echo sleep $sec 1>&2; sleep $sec; echo SLEPT $sec; echo SLEPT $sec 1>&2; done; done) > f 

na moim hosta systemu Windows (Windows 7 Professional SP1 64-bit), Windows Firewall z zainstalowanym cygwin dostarczyć skorupę i netcat, interaktywnie uruchamiam klienta UDP:

UNIXHOST=192.168.181.1 
nc -u -p 6666 $UNIXHOST 2222 

Nie musisz używać cygwin; Netcat powinien działać poprawnie, ale wiersze poleceń mogą się różnić.

Następnie do tego klienta wpisuję serię interwałów testowych, obserwuję, jak serwer śpi, a następnie reaguje, obserwuję, czy klient otrzymuje odpowiedź. Te pracował: 1, 2, 10, 60, 120, 180. Następnie ta powiodła się: 240 Postępować z binarnym wyszukiwania między 180 a 240.

Przykład 1: Na stronie klienta, typu I:

10 
60 
120 
180 
240 

i zauważ, że opóźnienie żądanie-odpowiedź do 180 prac, 240 nie.

Przykład 2: Po stronie klienta, wpisuję:

180 
181 
182 
182 

i zauważyć, że opóźnienie żądanie-odpowiedź w wysokości do 181 prac, 182 nie.

Przykład 3: Po stronie klienta, typu I (w tej samej linii)

180 180 180 181 181 181 182 182 182 183 183 183 

która generuje jedno żądanie UDP z klientem, a następnie serii reakcji oddziela się przez 180, 181, 182, lub 183 sekundowe interwały. Zaobserwowano, że czas reakcji na żądanie wynoszący do 181 zadziałał, a ponadto kontynuowano reakcje (bez nowych wniosków) w odstępach czasu aż do 181 sekund.

W związku z tym otwór w zaporze ma licznik czasu bezczynności, bez względu na to, czy brak aktywności jest opóźnieniem w początkowej odpowiedzi, czy w kolejnym dodatkowym ruchu.

Wyniki na wielu maszynach:

• W tym Windows 7 Professional SP1 64-bit pulpit, otwór odpowiedź UDP jest otwarty na 181 sekund. Możliwe, że mierzę także zaporę sieciową między dwoma systemami, ponieważ są one w oddzielnych sieciach - ale myślę, że są one routowane, a nie zaporą ogniową. W każdym razie otwór w zaporze systemu Windows trwa co najmniej 181 sekund w tym systemie.
• Kolejny Windows 7 Professional SP1 64-bitowy laptop, ten sam segment sieciowy (więc zdecydowanie nie ma interwencji firewall), otwór odpowiedzi UDP jest otwarty przez 64 sekundy.

Chciałbym zobaczyć podobne pomiary na innych komputerach z systemem Windows na różnych poziomach systemu operacyjnego i konfiguracji zapory.