Ús d'IPv6 amb connexió directa avançada

És interessant veure el desenvolupament de la xarxa per compartir fitxers, però encara és més interessant participar-hi.

Avui, instal·lant i llançant un modern NMDC hub, el nou administrador té accés a gairebé tots els desenvolupaments i experiència acumulats en aquesta àrea dels seus predecessors. Té un sistema preparat per a l'expansió i la personalització, fins i tot amb l'ajuda de nombrosos scripts.

С ADC hubs en cas contrari. El disseny d'aquest protocol pretén ser extensible. Vols una funció nova? Bé, oferir-lo, promocionar-lo, implementar-lo, implementar-lo, utilitzar-lo.

Traduir a l'anglès

Com a resultat, podeu, per descomptat, treure un concentrador ja fet de la caixa, però simplement llançar-lo i oblidar-lo no serà bo. L'extensibilitat en un context històric també implica la presència d'un nombre diferent de funcions diferents del programari client i servidor, segons la versió. I el que funcionarà sense problemes per a un usuari pot ser incompatible amb el client d'un altre, i això s'ha de tenir en compte.

Això va passar amb IPv6. El vell NMDC no sap com fer-ho en principi, però el mateix ADC està preparat per a això. Tanmateix, no tot és tan senzill.

Només una mica de teoria

L'usuari "actiu" pot acceptar connexions entrants. En realitat, la sol·licitud de connexió que ve d'ell és en realitat invitació.

Un usuari "passiu" generalment només pot utilitzar sol·licituds sortints. A través del hub ell pregunta l'usuari actiu envia una invitació i s'estableix la connexió.

Ús d'IPv6 amb connexió directa avançada

I sí, aquest mecanisme no depèn de la versió del protocol IP utilitzat.

Cigne, escamarlans i lluç

Parlem del programari client.

Suport IPv6 DC++ és de naturalesa experimental. No hi ha configuracions separades per a això, i va ser encara més sorprenent per a mi veure diferents modes de funcionament per a diferents versions d'IP, amb passiu només per a la sisena, però això no és exacte.

No va ser possible obtenir el mode actiu durant la configuració manual, fins i tot quan s'utilitzava explícitament un domini IP amb un registre AAAA com a WAN, però en mode automàtic amb UPnP tot va funcionar com s'esperava.

AirDC++ també té suport per a connexions IPv6 i s'implementa de manera totalment independent d'IPv4. A més, aquest client modifica les etiquetes d'usuari de manera que es mostrin els modes de funcionament dels dos protocols IP simultàniament. Els mateixos hubs no saben com fer-ho (encara), la qual cosa és una llàstima.

He de fer una reserva immediatament: AirDC++ ho fa sol i per si mateix. En el futur, per comoditat, utilitzaré combinacions com AP o AA com a indicació dels modes d'operació actius o passius per a IPv4 i IPv6, respectivament, en lloc de la seva visualització a l'etiqueta de client real del concentrador real. És important.

En el nostre experiment farem servir FlylinkDC++ com a client gens familiaritzat amb IPv6. També cal destacar aquest suport NATT per a ell en el moment d'escriure aquest article no es va implementar enlloc.

Начало

En primer lloc, veurem connexions òbviament impossibles entre usuaris de diferents versions del protocol IP. S'utilitzarà per a la prova Hub preparat per a IPv6 amb els registres de recursos A i AAAA per al nom de domini que actuen com a adreça.

Ús d'IPv6 amb connexió directa avançada

Tingueu en compte que quan (de fet) intenteu contactar amb un usuari amb una adreça IP de la versió XNUMX, es mostra un error.

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

En traducció humana sembla

P4: – Puc aferrar-me a tu?
A6: – Aferra’t!
P4: – La vida és dolor 0_0

Un breu diccionari, si cal, aquí.

I si és al revés, i la connexió s'inicia A4, aleshores no es mostra cap error i la connexió simplement es bloqueja.

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

Ser, no semblar-ho

El que és important és el mode de connexió que es mostra al concentrador.

Els clients sense suport IPv6 hauran de veure els usuaris connectats a través d'ell com a clarament passius, simplement perquè el concentrador no s'omple per a ells. I4 o I6 camp en conseqüència.

Ús d'IPv6 amb connexió directa avançada
FlylinkDC++ vs. IPv6

En realitat, la situació és més senzilla i més complexa alhora.

Ús d'IPv6 amb connexió directa avançada
AirDC++ vs. IPv6

Més fàcil perquè IPv6 té prioritat sobre IPv4, i això és comprensible. És a través d'ell (tot i que la substitució està disponible mitjançant l'opció corresponent) que s'establirà la connexió amb el concentrador, i el client actiu l'oferirà al client passiu per a la connexió.

És més difícil, perquè si hi ha usuaris amb suport IPv6 al concentrador, però estan connectats estrictament mitjançant una adreça IPv4, aleshores...

Ús d'IPv6 amb connexió directa avançada

... llavors us podeu connectar (a l'atzar) sense tenir IPv4 en absolut.

Tingueu en compte que el client remot s'ha designat com un actiu, però es tracta com un passiu. Per què?

Llança'l en un gronxador

Ara intentem connectar clients amb conjunts diferents, però comuns en termes d'IPv4, de suport de protocols IP entre ells.

Ús d'IPv6 amb connexió directa avançada

Sí, és una llàstima que els usuaris passius hagin de fumar al marge. Però això no es pot evitar, ja que la seva adreça IP visible no és especialment important, per això són responsabilitats.

Ús d'IPv6 amb connexió directa avançada

Bah! El client actiu envia comandament passiu?.. Seria lògic esperar una connexió "encallada", però no, resulta que sota les condicions A4.

Per què això? Ens posem en contacte amb el desenvolupador i obtenim la resposta:

CTM no és bo si l'altre usuari no és compatible amb IPv6

I no pots discutir! Però això requereix una lògica interna, independent del centre (vegeu el codi aquí и aquí). Encara és impossible ajudar els passius, perquè

Mode actiu = TCPx+IPx

Els intents de connectar-se entre clients amb conjunts comuns de suport IPv6 IP tenen aquest aspecte. Deixa'm recordar-te, aconseguir PA No vaig tenir èxit amb DC++.

Ús d'IPv6 amb connexió directa avançada

I de nou una sorpresa. Resulta que el mode passiu per a IPv6, que demostra DC++, és una falsificació deliberada o un error.

Què serà el següent?

Actualment, hi ha exactament dues maneres de resoldre tots els possibles problemes de connexió dels usuaris en diferents modes i amb diferents conjunts de suport de protocols IP.

El primer és silenciar IPv6 per complet o, al contrari, crear un concentrador que només funcioni a través d'ell.

El segon és aquest extensió, que tot just s'acosta a l'etapa de proves.

Bé, si ets massa mandrós per configurar el mode actiu per treballar a DC, recorda:

A qui té, el que li serà donat, i a qui no té, fins i tot allò que creu que té, se li prendrà. D'ACORD. 8:18

Font: www.habr.com

Afegeix comentari