Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

Ciekawie jest obserwować rozwój sieci wymiany plików, ale jeszcze ciekawiej jest w niej uczestniczyć.

Dziś montaż i uruchomienie nowoczesnego NMDC hub, nowo powołany administrator uzyskuje dostęp do niemal wszystkich osiągnięć i doświadczeń zgromadzonych w tym obszarze swoich poprzedników. Posiada system gotowy do rozbudowy i dostosowywania, w tym za pomocą licznych skryptów.

С ADC inaczej koncentratory. Projekt tego protokołu ma być rozszerzalny. Czy chcesz nową funkcję? Cóż, oferuj, promuj, wdrażaj, wdrażaj, korzystaj.

Przetłumacz na angielski

W rezultacie możesz oczywiście dostać gotowy hub od razu po wyjęciu z pudełka, ale samo uruchomienie go i zapomnienie o nim nie będzie dobre. Rozszerzalność w kontekście historycznym implikuje także obecność różnej liczby różnych funkcji oprogramowania klienckiego i serwerowego, w zależności od wersji. A to, co będzie działać bez problemów dla jednego użytkownika, może być niekompatybilne z klientem innego i należy to wziąć pod uwagę.

Stało się tak w przypadku protokołu IPv6. Stary NMDC w zasadzie nie wie jak to zrobić, ale sam ADC jest na to gotowy. Jednak nie wszystko jest takie proste.

Tylko trochę teorii

Użytkownik „aktywny” może akceptować połączenia przychodzące. W rzeczywistości żądanie połączenia pochodzące z niego jest w rzeczywistości zaproszenie.

Użytkownik „pasywny” może zazwyczaj korzystać tylko z żądań wychodzących. Przez piastę on pyta aktywny użytkownik wysyła zaproszenie - i połączenie zostaje nawiązane.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

I tak, mechanizm ten nie jest zależny od wersji użytego protokołu IP.

Łabędź, rak i szczupak

Porozmawiajmy o oprogramowaniu klienckim.

Obsługa protokołu IPv6 DC ++ ma charakter eksperymentalny. Nie ma dla niego osobnych ustawień, a tym bardziej zdziwiło mnie to, że dla różnych wersji IP widziałem różne tryby pracy, z pasywnym tylko dla szóstej, ale to nie jest dokładne.

Nie było możliwości uzyskania trybu aktywnego podczas konfiguracji ręcznej, nawet przy jawnym użyciu domeny IP z rekordem AAAA jako sieci WAN, ale w trybie automatycznym przy użyciu UPnP wszystko działało zgodnie z oczekiwaniami.

AirDC++ obsługuje również połączenia IPv6 i jest wdrażany całkowicie niezależnie od IPv4. Ponadto klient ten modyfikuje tagi użytkownika w taki sposób, aby wyświetlać tryby pracy dla obu protokołów IP jednocześnie. Same huby nie wiedzą (jeszcze), jak to zrobić, a szkoda.

Muszę natychmiast dokonać rezerwacji: AirDC++ robi to sam i dla siebie. W przyszłości dla wygody będę używał kombinacji takich jak AP lub AA jako wskazanie aktywnych lub pasywnych trybów działania odpowiednio dla IPv4 i IPv6, zamiast ich wyświetlania w rzeczywistym tagu klienta na prawdziwym koncentratorze. To jest ważne.

W naszym eksperymencie użyjemy FlylinkDC++ jako klient, który w ogóle nie zna protokołu IPv6. Należy również zauważyć, że wsparcie NATT dla niego w momencie pisania tego artykułu nie był nigdzie wdrażany.

początek

Przede wszystkim przyjrzymy się oczywiście niemożliwym połączeniom pomiędzy użytkownikami różnych wersji protokołu IP. Będzie używany do testu Koncentrator obsługujący protokół IPv6 z rekordami zasobów A i AAAA dla nazwy domeny działającymi jako jej adres.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

Pamiętaj, że przy (faktycznej) próbie skontaktowania się z użytkownikiem mającym adres IP w wersji XNUMX wyświetlany jest błąd.

Hub:	[Outgoing][IPv4:412]	 	DRCM AACX AACU ADCS/0.10 337151563
Hub:	[Incoming][IPv4:412]	 	DCTM AACU AACX ADCS/0.10 1988 337151563
Hub:	[Outgoing][IPv4:412]	 	DSTA AACX AACU 240 IPsunknown

W ludzkim tłumaczeniu brzmi to tak

P4: – Czy mogę się do Ciebie przylgnąć?
A6: – Trzymaj się!
P4: – Życie jest bólem 0_0

W razie potrzeby krótki słownik tutaj.

A jeśli jest odwrotnie i połączenie zostaje zainicjowane A4, wówczas nie wyświetla się żaden błąd i połączenie po prostu się zawiesza.

Hub:	[Outgoing][IPv4:412]	 	DCTM AACX AACU ADCS/0.10 1993 3871342713

Być, nie wydawać się być

Istotny jest tryb połączenia wyświetlany na hubie.

Klienci bez obsługi protokołu IPv6 będą musieli postrzegać podłączonych przez niego użytkowników jako wyraźnie pasywnych, po prostu dlatego, że koncentrator nie jest dla nich zapełniony I4 lub I6 odpowiednio pole.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim
FlylinkDC++ vs. IPv6

W rzeczywistości sytuacja jest prostsza i bardziej złożona jednocześnie.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim
AirDC++ vs. IPv6

Łatwiejsze, ponieważ IPv6 ma pierwszeństwo przed IPv4 i jest to zrozumiałe. To właśnie za jego pośrednictwem (choć istnieje możliwość nadpisania za pomocą odpowiedniej opcji) zostanie nawiązane połączenie z koncentratorem, a aktywny klient zaoferuje je klientowi pasywnemu w celu połączenia.

Jest to trudniejsze, bo jeśli na koncentratorze znajdują się użytkownicy obsługujący IPv6, ale połączeni są ściśle poprzez adres IPv4, to...

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

... wtedy możesz się z nimi połączyć (losowo) bez posiadania IPv4.

Należy pamiętać, że klient zdalny określił siebie jako składnik aktywów, ale jest traktowany jako zobowiązanie. Dlaczego?

Rzuć go w huśtawkę

Spróbujmy teraz połączyć klientów z różnymi, ale powszechnymi pod względem IPv4, zestawami obsługi protokołów IP.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

Tak, szkoda, że ​​pasywni użytkownicy muszą palić na uboczu. Ale nic na to nie poradzi, ponieważ ich widoczny adres IP nie jest szczególnie ważny - dlatego są zobowiązani.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

Ba! Aktywny klient wysyła polecenie pasywne?.. Logiczne byłoby oczekiwać „zablokowanego” połączenia, ale nie, okazuje się, że spełniają warunki A4.

Dlaczego? Kontaktujemy się z deweloperem i otrzymujemy odpowiedź:

CTM nie jest dobre, jeśli drugi użytkownik nie obsługuje protokołu IPv6

I nie możesz się kłócić! Wymaga to jednak wewnętrznej logiki, niezależnej od koncentratora (patrz code tutaj и tutaj). Nadal nie można pomóc pasywnym, ponieważ

Tryb aktywny = TCPx+IPx

Próby nawiązania połączenia pomiędzy klientami korzystającymi z typowych zestawów obsługi IPv6 IP wyglądają następująco. Przypomnę, osiągnij PA Nie udało mi się to z DC++.

Używanie protokołu IPv6 z zaawansowanym połączeniem bezpośrednim

I znowu niespodzianka. Okazuje się, że tryb pasywny dla IPv6, który demonstruje DC++, jest albo celową podróbką, albo błędem.

Co dalej?

Obecnie istnieją dokładnie dwa sposoby rozwiązania wszystkich możliwych problemów łączących użytkowników w różnych trybach i z różnymi zestawami obsługi protokołów IP.

Pierwszy polega na całkowitym wyciszeniu protokołu IPv6 lub odwrotnie, utworzeniu koncentratora, który będzie działał tylko przez niego.

Drugie jest to rozbudowa, który właśnie zbliża się do etapu testów.

Cóż, jeśli jesteś zbyt leniwy, aby skonfigurować tryb aktywny do pracy w DC, pamiętaj:

Kto ma, temu będzie dane, a kto nie ma, nawet to, co mu się wydaje, że ma, zostanie mu zabrane. OK. 8:18

Źródło: www.habr.com

Dodaj komentarz