DOI :: Routing in the I2P network. floodfils | Маршрутизація у мережі I2P. Флудфіли.

Грабовий

8 хв

Переглянути оригінал

"Open Source" і "децентралізація" - це два основних шильдики, що забезпечують гарне перше враження про проект. Нерідко популярні проекти лукавлять на ці теми або взагалі вводять своїх користувачів в оману, будучи пропрієтарними та частково централізованими. Наприклад, напіввідкритий Telegram та досить помітно централізований TOR.

А що ми знаємо про I2P? Пропоную докладно розібратися в тому, що забезпечує складність та працездатність абсолютно децентралізованої мережі: Флудфіли – своєрідні дошки оголошень.

Введення у тему

Почнемо з того, що внутрішньомережеві імена I2P ніяк не співвідносяться з будь-якими IP-адресами, як це відбувається у традиційному інтернеті. Отже, немає і маршрутизації мережами та підмережами, яку забезпечує концепція IP. Більше того, статус мережі, безпосередньо пов'язаний з анонімністю, має щось спиратися. Погодьтеся, питання тут явно не про оптимально короткі шляхи від точки до точки, а скоріше про щось протилежне: непередбачувані маршрути та тонну хитромудрої криптографії.

Ідентифікатори внутрішньомережевих ресурсів, наприклад, адреси сайтів, не містять будь-якої інформації про фізичне місцезнаходження сервера. Звична адреса, що закінчується на ".b32.i2p", - всього лише хеш SHA256 від повної адреси, який включає набір криптографічних ключів. Повна адреса у зв'язці з інформацією про тунелі, що входять, називається лізсетом, який необхідний для встановлення зв'язку з прихованим сервісом.

Відомо, що хеш-функція необоротна, тобто. зі значення хешу неможливо відновити вихідні дані, від яких унікальний рядок було взято. Розуміння цього призводить до логічного висновку, що отриману b32-адресу необхідно дозволити приблизно так, як це відбувається у звичайній мережі, коли по домену ім'я визначається IP-адреса цільового ресурсу: інформацію повертає DNS-сервер у відповідь на запит користувача по конкретному імені. В I2P замість заздалегідь відомих DNS-серверів використовуються флудфіли – дошки оголошень, де приховані ресурси публікують інформацію про себе, щоб можна було звернутися до них.

Існує кілька фундаментальних відмінностей від традиційної системи доменних імен:

• У I2P немає відповідальних за реєстрацію (не плутайте з прив'язкою коротких адрес «.i2p», тому що вони, по-простому кажучи, безкоштовно прив'язуються до вже існуючої довгої адреси «.b32.i2p»);

• Важливо неправильно постійно зберігати лізсет одному місці, т.к. будь-який з флудфілів може бути зловмисним. Розміщення інформації про лізсет має бути непередбачуваним для флудфілів, але логічним для тих, хто її шукає;

• Лізсет містить у собі не тільки повну адресу ресурсу, що складається з криптографічних ключів, але й інформацію про тунелі, що входять. Усі тунелі існують лише 10 хвилин, тому лізсет повинен регулярно оновлюватися, щоб ресурс залишався доступним ззовні.

Як локальний I2P-роутер знаходить прихований сервіс

Логіка, яка дозволяє публікуватися прихованому ресурсу (destination) на непередбачуваному флудфілі (floodfill), а потім іншому користувачеві знайти цей опублікований лізсет на практиці дуже витончена:

Береться цільова адреса (наприклад, та, яку користувач ввів у URI-рядок браузера) і сьогоднішня дата. З блоку цієї інформації виводиться хеш SHA256. Потім здійснюється пошук флудфіла в локальній базі роутера: перебираються всі існуючі. В середньому їх кількість коливається від сотні до кількох тисяч, залежить від умов роботи конкретного I2P-роутера. Для звернення за лізсетом використовується той, який при операції ВИКЛЮЧАЄ АБО з блоком «цільова b32-адреса + сьогоднішня дата» дасть найменше значення.

Якщо опитаний флудфіл не має у своєму розпорядженні потрібного лізсету, він повертає три флудфіли зі свого списку, які, на його думку, є найбільш підходящими для адреси, до якої ми хочемо звернутися. Після опитування додаткових флудфілів, у разі невдачі, адреса вважається недоступною.

За такою логікою працює публікація лізсету. Для публікації вибираються два найвідповідніші флудфіли. При отриманні нового лізсету, кожен із двох флудфілів повідомляє його трьом найбільш підходящим флудфілам зі своєї бази. У цьому поширення закінчується.

Кінцева точка (destination), що публікує свій лізсет, перевірять якість публікації. Після відправки лізсету на флудфіл очікується відповідь. Якщо відповіді немає, лізсет відправляється на наступний флудфіл. У разі успішної публікації флудфіл повертає список своїх сусідів, з якими поділився лізсетом. Відбувається контрольне звернення до названих сусідів. Отримані лізсети перевіряються і якщо всі вони є копіями того, що спочатку відіслав ініціатор, публікація вважається завершеною. Публікація лізсету відбувається кожні десять хвилин у міру старіння тунелів.

Звідки беруться флудфіли

Флудфіл – це роль, яку може взяти на себе будь-який роутер. Природно, що такий роутер має бути легко доступним для зовнішніх звернень: мати відкритий робочий порт та білу IP-адресу. Усі необхідні настройки – один параметр у конфігураційному файлі: floodfill = true.

Адреса роутера

Ідентифікатори кінцевих точок розібралися: це сутності без фізичних адрес, які розташовані на невідомих I2P-роутерах. А що з адресами та ідентифікаторами самих роутерів, тим більше, що й флудфіли за своєю суттю також є роутерами?

У домашнього інтернет-роутера є IP-адреса, серверні програми в звичайному інтернеті – IP-адреса і порт.

I2P-роутери також мають адресу: це набір криптографічних публічних ключів. Адреси роутерів схожі на адреси прихованих кінцевих точок, які були розглянуті вище. Адреса роутера – це набір криптографічних ключів – практично те саме, що і base64-адреса кінцевої точки. Для короткого запису використовується хеш SHA256, який дає на виході 32 байти. По суті, це аналог b32-адреси. Щоб не плутати адреси роутерів та адреси кінцевих точок, ідентифікатори роутерів (router ident) записуються у кодуванні base64 (перший рядок на скріншоті).

Трафік між роутерами зашифрований на рівні транспортних протоколів мережі: NTCP2 (крипто-аналог TCP) та SSU (крипто-аналог UDP). Це приховує абсолютно весь трафік I2P від ​​стороннього спостерігача, наприклад домашнього інтернет-провайдера. При цьому транспортна криптографія не зав'язана ключами роутера. Ключі роутера використовуються опціонально в залежності від типу трафіку, що проходить. Поглиблення у тему різних верств шифрування може викликати когнітивний розлад непідготовленого читача, тому повернемося ближче до теми.

Адреса роутера не містить даних про підключення до нього, лише публічні ключі. Також це відбувається з адресами прихованих сервісів, де для звернення до ресурсу потрібен лізсет з тунелями, що входять. У роутера замість лізсету RI (router info) – файл, що включає повну адресу та інформацію про фізичну доступність. Цей файл статичний, тому немає потреби його перезапитувати кожні десять хвилин.

Отриманий Router Info зберігається у локальній директорії "netDb". RI містить спеціальні прапори (Router Caps), які повідомляють про пропускну спроможність роутера і про статус флудфілу (або відсутність цього статусу). Надалі новий роутер може бути використаний як транзитний вузл при побудові тунелів.

У лізсеті завжди вказується лише короткий ідентифікатор першого роутера вхідного тунелю (gateway). Щоб звернутися до цього роутера, останній вузол нашого вихідного тунелю резолвіт отриманий адресу вузла через відомий йому флудфіл і в разі успіху починає передачу інформації в тунель, що входить нашого адресата.

Більше того, при побудові тунелю аналогічним чином дозволяються ідентифікатори роутера-сусіда кожним учасником тунелю, якщо в локальному сховищі потрібного Router Info не виявилося. Але це знову легкий відступ від теми флудфілів до тунелів.

Дослідження мережі

Під терміном дослідження мережі розуміється регулярне звернення кожного роутера до відомих флудфілів у пошуках нових роутерів. Часто цей процес називається розширенням малюнка мережі чи зондуванням.

Суть у наступному: відправляється випадкове значення, у відповідь на яке флудфіл відправляє три найближчі в математичному сенсі Router Info. Близькість обчислюється логічною операцією «ВИКЛЮЧНЕ АБО». По суті, це функція стандартного звернення до флудфілу в пошуках адреси, тільки адреса генерується випадковою, тому флудфіл повертає трьох сусідів, до яких ми могли б звернутися, продовжуючи пошук адреси.

Дослідницькі звернення здійснюються через спеціальні тунелі, які невибагливі до швидкості передачі. Як правило, якщо на роутері з низькою пропускною здатністю з'являються транзитні тунелі, вони є дослідницькими.

Дослідження мережі через тунелі (а не безпосередньо роутер-флудфіл) є мірою боротьби з атаками типу «Затемнення» та «Сівіла», які спрямовані на ізоляцію користувача в периметрі зловмисних флудфілів, які навмисно можуть ігнорувати запити конкретного роутера. Завдяки ланцюжку транзитних вузлів у дослідницькому тунелі флудфіл не знає, який роутер насправді запитує три нові роутери для розширення свого малюнка мережі. Детально моделі атаки на I2P розглянуті у статті .

Так загалом виглядає повністю незалежна система маршрутизації анонімної мережі I2P, побудована на флудфілах. При цьому флудфіли тримають не десять довірених організацій, товариш майор чи Ангела Меркель, а тисячі та тисячі добровольців.

Пару слів для власників флудфілів

Режим флудфілу збільшує обсяг споживаних ресурсів роутера. Це потрібно враховувати на дуже слабких пристроях на кшталт одноплатних комп'ютерів. Або треба було враховувати раніше… Завдяки розвитку I2P у вигляді впровадження сучасної криптографії, питання стає настільки неактуальним, що незабаром зовсім може бути опущено.

Справа в тому, що всі звернення до флудфілу приходять зашифрованим його асиметричним ключем шифрування. У старій реалізації це ключ ElGamal , який потребує багато процесорного часу. В актуальному режимі роботи використовується криптографія на еліптичній кривій (тип шифрування ECIES_X25519_AEAD, кодове позначення 4). У міру оновлення мережі, старе ресурсомістке шифрування залишається в минулому, оскільки за замовчуванням використовується новий тип.

Вже сьогодні є вдалі приклади роботи i2pd у режимі флудфілу на роутерах OpenWRT. Про перспективи перетворення кавоварки на анонімус поговоримо в одній з наступних статей.

Оригінальну статтю опубліковано в блозі дата-центру ITSOFT.

Просмотры: