Estas interese rigardi la evoluon de la dosier-kunhava reto, sed eĉ pli interese estas partopreni en ĝi.
Hodiaŭ, instalante kaj lanĉante modernan nabo, la lastatempe monfarita administranto ricevas aliron al preskaŭ ĉiuj evoluoj kaj sperto akumulitaj en ĉi tiu areo de siaj antaŭuloj. Ĝi havas sistemon preta por ekspansio kaj personigo, inkluzive kun la helpo de multaj skriptoj.
С naboj alie. La dezajno de ĉi tiu protokolo estas celita esti etendebla. Ĉu vi volas novan funkcion? Nu, proponu ĝin, reklamu ĝin, efektivigu ĝin, efektivigu ĝin, uzu ĝin.
Kiel rezulto, vi povas, kompreneble, eltiri pretan nabon el la skatolo, sed simple lanĉi ĝin kaj forgesi pri ĝi ne estos bona. Etendebleco en historia kunteksto ankaŭ implicas la ĉeeston de malsama nombro da malsamaj funkcioj de kliento kaj servila programaro, depende de la versio. Kaj kio funkcios sen problemoj por unu uzanto povas esti nekongrua kun la kliento de alia, kaj ĉi tio devas esti konsiderata.
Ĉi tio okazis kun IPv6. La maljunulo NMDC principe ne scias kiel fari ĝin, sed ADC mem estas preta por tio. Tamen, ne ĉio estas tiel simpla.
Nur iom da teorio
La "aktiva" uzanto povas akcepti envenantajn konektojn. Fakte, la konektopeto venanta de ĝi estas fakte invito.
"Pasiva" uzanto povas ĝenerale nur uzi eksiĝintajn petojn. Tra la nabo li demandas la aktiva uzanto sendas inviton - kaj la konekto estas establita.
Kaj jes, ĉi tiu mekanismo ne dependas de la versio de la IP-protokolo uzata.
Cigno, kankro kaj ezoko
Ni parolu pri klienta programaro.
IPv6-subteno estas eksperimenta en naturo. Ne ekzistas apartaj agordoj por ĝi, kaj des pli miris por mi vidi malsamajn operaciajn modojn por malsamaj versioj de IP, kun pasiva nur por la sesa, sed ĉi tio ne estas preciza.
Ne eblis akiri la aktivan reĝimon dum mana agordo eĉ kiam eksplicite uzis IP-domajnon kun AAAA-rekordo kiel WAN, sed en aŭtomata reĝimo uzante UPnP ĉio funkciis kiel atendite.
ankaŭ havas subtenon por IPv6-konektoj, kaj ĝi estas efektivigita tute aparte de IPv4. Plie, ĉi tiu kliento modifas uzantetikedojn tiel, ke ili montru funkciajn reĝimojn por ambaŭ IP-protokoloj samtempe. La naboj mem ne scias kiel fari tion (ankoraŭ), kio estas domaĝe.
Mi devas tuj fari rezervon: AirDC++ faras tion sole kaj por si mem. Estonte, por komforto, mi uzos kombinaĵojn kiel AP aŭ AA kiel indiko de aktivaj aŭ pasivaj reĝimoj de operacio por IPv4 kaj IPv6, respektive, prefere ol ilia ekrano en la reala klientetikedo sur la reala nabo. Ĝi estas grava.
En nia eksperimento ni uzos FlylinkDC++ kiel kliento tute ne konata kun IPv6. Oni ankaŭ rimarku, ke subteno por li en la momento de verkado de tiu ĉi artikolo nenie estis efektivigita.
Начало
Antaŭ ĉio, ni rigardos evidente neeblajn ligojn inter uzantoj de malsamaj versioj de la IP-protokolo. Estos uzata por la testo kun rimedo A- kaj AAAA-rekordoj por la domajna nomo agante kiel ĝia adreso.
Bonvolu noti, ke kiam vi (fakte) provas kontakti uzanton kun versio XNUMX IP-adreso, eraro montriĝas.
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 IPsunknownEn homa traduko ĝi sonas kiel
P4: – Ĉu mi povas alkroĉiĝi al vi?
A6: – Alkroĉu vin!
P4: – Vivo estas doloro 0_0
Mallonga vortaro, se necese, .
Kaj se estas inverse, kaj la konekto komenciĝas A4, tiam neniu eraro montriĝas kaj la konekto simple pendas.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Estu, ne ŝajnas esti
Gravas la koneksa reĝimo montrata sur la nabo.
Klientoj sen IPv6-subteno devos vidi uzantojn konektitajn per ĝi kiel klare pasivaj, simple ĉar la nabo ne loĝas por ili. I4 aŭ I6 kampo laŭe.
FlylinkDC++ vs. IPv6
En realeco, la situacio estas pli simpla kaj pli kompleksa samtempe.
AirDC++ vs. IPv6
Pli facila ĉar IPv6 havas prioritaton super IPv4, kaj tio estas komprenebla. Ĝuste per ĝi (kvankam superregado disponeblas uzante la respondan opcion) la konekto al la nabo estos establita, kaj la aktiva kliento proponos ĝin al la pasiva kliento por konekto.
Estas pli malfacila, ĉar se estas uzantoj kun IPv6-subteno sur la nabo, sed ili estas strikte konektitaj per IPv4-adreso, tiam...
... tiam vi povas konekti al ili (hazarde) tute sen havi IPv4.
Bonvolu noti, ke la fora kliento indikis sin kiel valoraĵon, sed estas traktata kiel respondeco. Kial?
Ĵetu lin en svingon
Nun ni provu konekti klientojn kun malsamaj, sed komunaj laŭ IPv4, aroj de IP-protokolo-subteno unu al la alia.
Jes, estas domaĝe, ke pasivaj uzantoj devas fumi flanke. Sed ĉi tio ne povas esti helpita, ĉar ilia videbla IP-adreso ne estas precipe grava - tial ili estas respondecoj.
Bah! La aktiva kliento sendas ?.. Estus logike atendi "ŝtopiĝintan" konekton, sed ne, ĝi rezultas sub la kondiĉoj A4.
Kial estas tio? Ni kontaktas la programiston kaj ricevas la respondon:
ne estas bona se la alia uzanto ne subtenas IPv6
Kaj vi ne povas argumenti! Sed ĉi tio postulas internan logikon, sendependan de la nabo (vidu kodon и ). Ankoraŭ ne eblas helpi pasivojn, ĉar
Aktiva reĝimo =
Provoj konekti inter klientoj kun oftaj IPv6 IP-subtenaj aroj aspektas tiel. Lasu min memorigi vin, atingi PA Mi ne sukcesis por DC++.
Kaj denove surprizo. Rezultas, ke la pasiva reĝimo por IPv6, kiun DC++ pruvas, estas aŭ intenca falsaĵo aŭ cimo.
Kio sekvas?
Nuntempe, ekzistas ekzakte du manieroj solvi ĉiujn eblajn problemojn kunliganta uzantojn en malsamaj reĝimoj kaj kun malsamaj aroj de IP-protokolo-subteno.
La unua estas silentigi IPv6 entute aŭ, male, krei nabon por funkcii nur per ĝi.
La dua estas ĉi tiu , kiu ĵus alproksimiĝas al la prova stadio.
Nu, se vi estas tro maldiligenta por agordi la aktivan reĝimon por labori en DC, memoru:
Kiu havas, kio estos donita al li, kaj kiu ne havas, eĉ tion, kion li opinias, ke li havas, estos forprenita de li. BONE. 8:18
fonto: www.habr.com