Het gebruik van IPv6 in Advanced Direct Connect

Het is interessant om de ontwikkeling van het file-sharing netwerk te volgen, maar nog interessanter is het om eraan deel te nemen.

Tegenwoordig, door een moderne NMDC hub in te stellen en in gebruik te nemen, krijgt de nieuwe administrator toegang tot bijna alle ontwikkelingen en de ervaring die zijn voorgangers op dit gebied hebben opgebouwd. Hij heeft een systeem dat klaar is voor uitbreiding en maatwerk, onder andere met behulp van talloze scripts.

met ADC de hubs anders. De structuur van dit protocol maakt uitbreidbaarheid mogelijk. Wil je een nieuwe functie? Nou, stel voor, promoot, implementeer, pas toe, gebruik.

Vertaal naar het Engels

Als gevolg hiervan kan men "uit de doos" natuurlijk een kant-en-klare hub krijgen, maar het is niet goed om het gewoon te starten en er vervolgens niet meer naar om te kijken. Uitbreidbaarheid in historische context houdt ook in dat er verschillende functies zijn voor client- en serversoftware, afhankelijk van de versie. En wat zonder problemen werkt bij de ene gebruiker, kan incompatibel zijn met de client van een ander, en dat moet in aanmerking worden genomen.

Dat is precies wat er gebeurde met IPv6. De oude NMDC ondersteunt het in feite niet, terwijl ADC er wel voor klaar is. Echter, het is niet zo eenvoudig.

Een beetje theorie

Een "actieve" gebruiker kan inkomende verbindingen accepteren. Eigenlijk is een uitgaande verbindingsverzoek van hem in feite een uitnodiging..

Een "passieve" gebruiker kan in het algemeen alleen uitgaande verzoeken gebruiken. Via de hub kan hij 16 BYN (~475 RUB) voor een subnet /64. een uitnodiging van een actieve gebruiker versturen – en de verbinding wordt tot stand gebracht.

En ja, dit mechanisme is niet afhankelijk van de versie van het gebruikte IP-protocol.

De Zwaan, de Krab en de Snoek

Laten we het over de clientsoftware hebben.

Ondersteuning voor IPv6 in DC++ heeft een experimenteel karakter. Er zijn geen specifieke instellingen voor, en het verbaasde me des te meer verschillende werkmodi te zien voor verschillende versies van IP, waarbij passief juist voor de zesde is, maar dat is niet precies.

Het verkrijgen van de actieve modus bij handmatige configuratie lukte zelfs niet toen ik expliciet een domein met een AAAA-record als WAN IP gebruikte, maar in de automatische modus met UPnP werkte alles zoals het hoorde.

AirDC++ heeft ook ondersteuning voor IPv6-verbindingen, en deze is volledig apart van IPv4 geïmplementeerd. Bovendien modificeert deze client tags voor gebruikers zodat zowel de werkmodi voor beide IP-protocollen tegelijkertijd worden weergegeven. De hubs kunnen dit (tot nu toe) niet, wat jammer is.

Ik moet meteen stellen: AirDC++ doet dit voor zichzelf. Voor het gemak zal ik in de toekomst combinaties gebruiken zoals AP of AA als een aanwijzing voor de actieve of passieve werkmodi voor respectievelijk IPv4 en IPv6, en niet hun weergave in de tag van de echte client op een echte hub. Dit is belangrijk.

In ons experiment zullen we gebruik maken van FlylinkDC++ als client, die helemaal niet bekend is met IPv6. Bovendien moet worden opgemerkt dat de ondersteuning voor NATT op het moment van schrijven in dit artikel nergens was geïmplementeerd.

Inleiding

Allereerst zullen we de opzettelijk onmogelijke verbindingen tussen gebruikers van verschillende versies van het IP-protocol bekijken. Voor de test zal worden gebruikt een IPv6 ready hub met resource A- en AAAA-records voor de domeinnaam, die als zijn adres fungeert.

Let op, hier geeft een (feitelijke) poging om verbinding te maken met een gebruiker met een IP-adres van de zesde versie een foutmelding.

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

In mensentaal klinkt dit als

P4: – Mag ik aan je vastklampen?
A6: – Klamp je maar vast!
P4: – Het leven is pijn 0_0

Een kort woordenboekje, voor het geval dat, hier.

En als omgekeerd, en de verbinding initieert A4, dan verschijnt er geen fout en 'hangt' de verbinding gewoon.

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

Wees, en niet lijk.

Wat belangrijk is, is de weergegeven verbindingmodus op de hub.

Klanten zonder ondersteuning voor IPv6 moeten de verbonden gebruikers via hem zien als duidelijk passief, simpelweg omdat de hub voor hen niet invult I4 of I6 het veld dienovereenkomstig.

FlylinkDC++ vs. IPv6

In werkelijkheid is de situatie eenvoudiger en ingewikkelder tegelijk.

AirDC++ vs. IPv6

Eenvoudiger, omdat IPv6 prioriteit heeft boven IPv4, en dat is duidelijk. Via deze verbinding (hoewel met de bijbehorende optie beschikbaar is om te overschrijven) wordt de verbinding met de hub gelegd, en zijn actieve client zal een verbinding met de passieve bieden.

Ingewikkelder, omdat als er op de hub gebruikers zijn met ondersteuning voor IPv6, maar zij strikt zijn verbonden via een IPv4-adres, dan...

… kun je verbinden (blindelings) zonder überhaupt IPv4 te hebben.

Let op, de externe client heeft zich als actief aangeduid, maar wordt als passief behandeld. Waarom?

Oeps, dat gaat de verkeerde kant op

Laten we nu proberen om clients met verschillende, maar overlappende IPv4-ondersteuningssets met elkaar te verbinden.

Ja, het is jammer dat passieve gebruikers aan de zijlijn moeten staan. Maar dat kan niet worden geholpen, omdat hun zichtbare IP-adres niet veel betekent - dat is nou eenmaal hoe passieven werken.

Hé! De actieve client stuurt een passieve opdracht?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.

Waarom is dat zo? We vragen de ontwikkelaar en krijgen als antwoord:

CTM is niet goed als de andere gebruiker IPv6 niet ondersteunt

En daar valt niet over te twisten! Maar dat vereist al interne logica, onafhankelijk van de hub (zie code hier en hier). Passieven kunnen nog steeds niet geholpen worden, omdat

Actieve modus = TCPx + IPx

De pogingen om clients met overlappende IPv6-ondersteuningssets met elkaar te verbinden zien er als volgt uit. Ik herinner je eraan dat we moeten proberen PA voor DC++ niet is gelukt.

En weer een verrassing. Het lijkt erop dat de passieve modus voor IPv6, zoals gedemonstreerd door DC++, ofwel een opzettelijke nep is, of een bug.

Wat nu?

Op dit moment zijn er precies twee manieren om alle mogelijke verbindingsproblemen voor gebruikers in verschillende modi en met verschillende IP-ondersteuningssets op te lossen.

De eerste is om IPv6 helemaal te dempen of, omgekeerd, een hub te creëren die alleen via IPv6 werkt.

De tweede is dit uitbreiding, dat net in de testfase komt.

En terwijl je lui de actieve modus instelt voor DC, houd in gedachten:

Wie heeft, hem zal gegeven worden; maar wie niet heeft, van hem zal ook datgene worden afgenomen waarvan hij denkt dat hij het heeft. Lk. 8:18

Bron: habr.com