IPv6 kasutamine täiustatud otseühendusega

Failijagamisvõrgu arengut on huvitav jälgida, kuid veelgi huvitavam on selles osaleda.

Täna paigaldame ja käivitame kaasaegse NMDC keskuses, pääseb äsja vermitud administraator ligi peaaegu kõigile oma eelkäijate selles valdkonnas kogutud arengutele ja kogemustele. Sellel on süsteem, mis on valmis laiendamiseks ja kohandamiseks, sealhulgas paljude skriptide abil.

С ADC rummud muidu. Selle protokolli kujundus on mõeldud laiendatavaks. Kas soovite uut funktsiooni? Noh, pakkuge, reklaamige, rakendage, rakendage, kasutage.

Tõlgi inglise keelde

Selle tulemusel saate loomulikult karbist välja võtta valmis jaoturi, kuid selle lihtsalt käivitamine ja selle unustamine pole hea. Laiendatavus ajaloolises kontekstis tähendab ka erineva arvu erinevate funktsioonide olemasolu kliendi- ja serveritarkvaras, olenevalt versioonist. Ja see, mis ühe kasutaja jaoks probleemideta töötab, ei pruugi teise kliendiga ühilduda ja sellega tuleb arvestada.

See juhtus IPv6-ga. Vanamees NMDC seda põhimõtteliselt ei oska, aga ADC ise on selleks valmis. Siiski pole kõik nii lihtne.

Lihtsalt väike teooria

"Aktiivne" kasutaja saab sissetulevaid ühendusi vastu võtta. Tegelikult on sellelt pärinev ühenduse taotlus tegelikult kutse.

"Passiivne" kasutaja saab üldjuhul kasutada ainult väljaminevaid päringuid. Rummu kaudu ta просит aktiivne kasutaja saadab kutse – ja ühendus on loodud.

Ja jah, see mehhanism ei sõltu kasutatava IP-protokolli versioonist.

Luik, jõevähk ja haug

Räägime klienditarkvarast.

IPv6 tugi DC ++ on oma olemuselt eksperimentaalne. Eraldi seadistusi selle jaoks pole ja seda üllatavam oli minu jaoks näha IP erinevate versioonide jaoks erinevaid töörežiime, passiivset ainult kuuenda jaoks, kuid see pole täpne.

Manuaalse konfigureerimise ajal ei olnud võimalik aktiivset režiimi saada isegi siis, kui WAN-ina kasutati AAAA-kirjega IP-domeeni, kuid automaatrežiimis UPnP-d kasutades töötas kõik ootuspäraselt.

AirDC++ toetab ka IPv6-ühendusi ja see on IPv4-st täiesti eraldiseisev. Lisaks muudab see klient kasutaja silte nii, et kuvatakse samaaegselt mõlema IP-protokolli töörežiimid. Rummud ise ei oska seda (veel) teha, millest on kahju.

Pean kohe broneerima: AirDC++ teeb seda üksi ja enda jaoks. Edaspidi kasutan mugavuse huvides kombinatsioone nagu AP või AA IPv4 ja IPv6 aktiivsete või passiivsete töörežiimide näitamiseks, mitte nende kuvamiseks tegeliku jaoturi tegelikul kliendisildil. See on tähtis.

Oma katses kasutame FlylinkDC++ kui klient, kes pole IPv6-ga üldse tuttav. Samuti tuleb märkida, et toetus NATT tema jaoks ei olnud seda artiklit kirjutamise ajal kusagil rakendatud.

Algus

Kõigepealt vaatleme ilmselgelt võimatuid ühendusi IP-protokolli erinevate versioonide kasutajate vahel. Kasutatakse testi jaoks IPv6 valmis jaotur domeeninime ressursi A ja AAAA kirjetega, mis toimivad selle aadressina.

Pange tähele, et kui proovite (tegelikult) võtta ühendust versiooni XNUMX IP-aadressiga kasutajaga, kuvatakse tõrketeade.

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

Inimtõlkes kõlab see nii

P4: – Kas ma võin sinu külge klammerduda?
A6: – Klammerduge!
P4: – Elu on valu 0_0

Vajadusel lühike sõnastik, siin.

Ja kui see on vastupidi ja ühendus algab A4, siis viga ei kuvata ja ühendus lihtsalt hangub.

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

Ole, ei näi olevat

Oluline on jaoturil kuvatav ühendusrežiim.

Kliendid, kellel puudub IPv6 tugi, peavad nägema selle kaudu ühendatud kasutajaid selgelt passiivsetena lihtsalt seetõttu, et jaotur ei asu nende jaoks I4 või I6 välja vastavalt.

FlylinkDC++ vs. IPv6

Tegelikkuses on olukord lihtsam ja samal ajal keerulisem.

AirDC++ vs. IPv6

Lihtsam, sest IPv6 on IPv4 ees ülimuslik ja see on arusaadav. Just selle kaudu (kuigi alistamine on saadaval vastava valiku abil) luuakse ühendus jaoturiga ja aktiivne klient pakub seda passiivsele kliendile ühendamiseks.

See on keerulisem, sest kui jaoturis on IPv6 toega kasutajaid, kuid nad on ühendatud rangelt IPv4-aadressi kaudu, siis ...

... siis saate nendega ühenduse luua (juhuslikult) ilma IPv4ta.

Pange tähele, et kaugklient on määranud end varaks, kuid seda käsitletakse kohustusena. Miks?

Viska ta hoo sisse

Nüüd proovime omavahel ühendada kliente, kellel on erinevad, kuid IPv4 osas levinud IP-protokolli toega komplektid.

Jah, kahju, et passiivsed kasutajad peavad kõrvalt suitsetama. Kuid seda ei saa aidata, kuna nende nähtav IP-aadress pole eriti oluline - seepärast on nad kohustused.

Bah! Aktiivne klient saadab passiivne käsk?.. Loogiline oleks oodata "kinnijäänud" ühendust, aga ei, see selgub tingimustel A4.

Miks nii? Võtame arendajaga ühendust ja saame vastuse:

CTM ei ole hea, kui teine ​​kasutaja ei toeta IPv6

Ja te ei saa vaielda! Kuid see nõuab jaoturist sõltumatut sisemist loogikat (vt koodi siin и siin). Passiive on ikka võimatu aidata, sest

Aktiivne režiim = TCPx+IPx

Katsed luua ühendus tavaliste IPv6 IP-tugikomplektidega klientide vahel näevad välja sellised. Lubage mul teile meelde tuletada, saavutage PA Mul ei õnnestunud DC++ puhul.

Ja jälle üllatus. Selgub, et IPv6 passiivne režiim, mida DC++ demonstreerib, on kas tahtlik võlts või viga.

Mis edasi?

Praegu on kõigi võimalike probleemide lahendamiseks eri režiimides ja erinevate IP-protokolli toega kasutajate ühendamisel täpselt kaks võimalust.

Esimene on IPv6 täielik vaigistamine või, vastupidi, jaoturi loomine, mis töötab ainult selle kaudu.

Teine on see laienemine, mis on just lähenemas testimisetapile.

Noh, kui olete DC-s töötamiseks aktiivse režiimi seadistamiseks liiga laisk, pidage meeles:

Kellel on, sellele antakse, ja kellel ei ole, sellelt võetakse ära seegi, mida ta arvab olevat. OKEI. 8:18

Allikas: www.habr.com