Az IPv6 használata az Advanced Direct Connect-ban

Érdekes figyelemmel kísérni a fájlmegosztó hálózat fejlődését, de még izgalmasabb benne részt venni.

Ma, amikor egy modern NMDC hubot telepít és indít el az újonnan kinevezett adminisztrátor, gyakorlatilag minden korábbi tapasztalat és fejlesztés hozzáférhetővé válik a számára. Olyan rendszert kap, amely készen áll a bővítésre és testreszabásra, többek között számos szkripttel.

Késleltetett streaming replikációt is beállíthatunk, de van néhány csapda, amelyek a replikációs slotokkal, a forró tartalék visszajelzésével stb. kapcsolatosak. A WAL archívum lehetővé teszi, hogy elkerüljük ezeket. ADC a huboknak másképp. E protokoll felépítése bővíthetőséget feltételez. Új funkcióra van szükséged? Nos, javasold, népszerűsítsd, valósítsd meg, valósítsd be, használd.

Translate to English

Ennek következtében, "dobozból" természetesen létrehozhatsz egy kész hubot, de ha csak elindítod és megfeledkezel róla, az nem lesz helyes. A történeti kontextusban a bővíthetőség azt is magában foglalja, hogy különféle funkciók állnak rendelkezésre az ügyfél- és szerver szoftverekben a verzió függvényében. És ami az egyik felhasználónál problémamentesen működik, az lehet, hogy egy másik klienssel nem lesz kompatibilis, és ezt figyelembe kell venni.

Így történt az IPv6-tal is. Az öreg NMDC alapvetően nem tudja kezelni, viszont az ADC készen áll rá. Azonban nem minden olyan egyszerű.

Csak egy kis elmélet

Az "aktív" felhasználó bejövő kapcsolatok fogadására képes. Valójában az általa indított kapcsolatfelvételi kérés meghívás.

A "passzív" felhasználó általában csak kimenő kéréseket használhat. A hubon keresztül kér egy aktív felhasználótól, hogy küldje el a meghívást – és így létrejön a kapcsolat.

És igen, ez a mechanizmus nem függ az IP protokoll verziójától.

Hattyú, rák és csuka

Beszéljünk az ügyfélszoftverről.

Az IPv6 támogatás a DC++ esetében kísérleti jellegű. Nincsenek külön beállításai, és annál meglepőbb volt számomra, hogy különböző működési módokat láttam a különböző IP verziók esetében, mivel a passzív éppen a hatodikra vonatkozik, de ez nem pontos.

Aktív módot kézi beállítással nem sikerült aktiválni, még akkor sem, ha egy AAAA rekorddal rendelkező domént használtam WAN IP-ként, de az automatikus módban az UPnP használatával minden a vártnak megfelelően működött.

AirDC++ támogatja az IPv6-os kapcsolatokat, amelyeket teljesen külön valósítanak meg az IPv4-től. Sőt, ez az ügyfél módosítja a felhasználói címkéket, hogy egyszerre jelenítse meg mindkét IP protokoll üzemmódját. Maguk a hubok ezt (még) nem tudják megtenni, ami kár.

Kezdjük azzal, hogy az AirDC++ ezt a magáéval is így teszi. A továbbiakban az egyszerűség kedvéért olyan kombinációkat fogok használni, mint AP vagy AA az IPv4 és IPv6 üzemmódok aktív vagy passzív jelölésére, nem pedig azok megjelenítésére a valós ügyfél címkéjében a valós hubon. Ez fontos.

Kísérletünkben FlylinkDC++-t fogjuk használni mint klienst, amely egyáltalán nem ismeri az IPv6-ot. Meg kell jegyezni, hogy a NATT támogatása ebben az időpontban még sehol nem valósult meg.

Kezdet

Első lépésként megvizsgáljuk a létezhetetlen kapcsolatokat a különböző IP protokoll-verziók felhasználói között. A teszt során IPv6 ready hubot fogunk alkalmazni, amely A- és AAAA-erőforrás rekordokkal rendelkezik a domain névhez, ami annak címeként szolgál.

Figyelem, itt (a valós) felhasználói cím elkérésének kísérleténél hibaüzenet jelenik meg, ha a hatodik verziójú IP-címet célozzuk meg.

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

Emberi nyelvre fordítva ez úgy hangzik, mint

P4: – Csatlakozhatok hozzád?
A6: – Csatlakozhatsz!
P4: – Az élet fáj 0_0

Egy rövid szótár, ha szükséges, itt.

Ha pedig fordítva van, és a kapcsolat kezdeményez A4, akkor hibaüzenet nem jelenik meg, és a kapcsolat egyszerűen "beragad".

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

Lenni, nem tűnni

Ami fontos, az a hubon látható kapcsolat üzemmódja.

Az IPv6-ot nem támogató kliensek kizárólag passzívnak fogják látni az olyan felhasználókat, akik rajta keresztül csatlakoznak, mert a hub nem tölti ki I4 vagy I6 a mezőt ennek megfelelően.

FlylinkDC++ vs. IPv6

Valójában a helyzet egyszerűbb és bonyolultabb egyben.

AirDC++ vs. IPv6

Egyszerűbb, mert az IPv6 prioritást élvez az IPv4-el szemben, és ez világos. Az éppen ez (bár megfelelő opción keresztül felülbírálás lehetséges) fogja létesíteni a kapcsolatot a hubbal, és az aktív kliens, amely csatlakozást kínál a passzívnak.

Bonyolultabb, mert ha a hubon IPv6 támogatással rendelkező felhasználók vannak, akik azonban kizárólag IPv4-címen csatlakoznak, akkor...

… akkor velük kapcsolatba léphetünk (vakarva) anélkül, hogy IPv4-et használnánk.

Kérlek, vedd észre, hogy a távoli kliens aktívnak jelölte magát, de passzívként kezeljük. Miért?

Hát, oda a hintába.

Most próbáljuk meg összekapcsolni a klienseket különböző, de IPv4 részben közös IP protokoll támogatási készletekkel.

Igen, kár, hogy a passzív felhasználóknak a háttérben kell maradniuk. De ezzel nem lehet segíteni, mivel a látható IP-címüknek nincs különösebb jelentősége – ezért passzívek.

Hoppá! Az aktív kliens küld passzív parancsot.?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.

Miért van ez? Megkerestük a fejlesztőt, és megkaptuk a választ:

CTM nem jó, ha a másik felhasználó nem támogatja az IPv6-ot.

És ez nem vitatható! De ehhez már belső, a hubtól független logika szükséges (lásd a kódot itt és itt). A passzívoknak pedig továbbra sem lehet segíteni, mert

Aktív mód = TCPx + IPx

A kliens közötti összekapcsolási kísérletek a részben IPv6-ot támogatók részéről a következőképpen néznek ki. Emlékeztetlek, hogy elérni PA a DC++-nek nem sikerült.

És újabb meglepetés. Kiderül, hogy a DC++ által bemutatott passzív mód az IPv6 számára szándékosan hamisítvány vagy hiba.

Mi következik?

Jelenleg pontosan két módszer létezik a felhasználók különböző módok és eltérő IP protokoll támogatási készletekkel való összekapcsolásának összes lehetséges problémájának megoldására.

Az első – teljesen elnyomni az IPv6-ot, vagy éppen ellenkezőleg, létrehozni egy hubot, amely csak rajta dolgozik.

A második – ez itt kiterjesztés, amely éppen csak tesztelési stádiumba lép.

Nos, és mivel lustálkodunk az aktív mód beállításakor a DC-ben, ne feledd:

Akinek van, annak adatik, akinek pedig nincs, attól elvétetik az is, amiről úgy gondolja, hogy van. Lk. 8:18

Forrás: habr.com