Методи побудови VPN на мережевому рівні. Розрахункова робота з Інформаційно-аналітичне забезпечення безпеки. Робота № 524847

Перехід до торгівельного партнера Binance

Методи побудови VPN на мережевому рівні

Інформація про навчальний заклад

ВУЗ:

Національний університет Львівська політехніка

Інститут:

Не вказано

Факультет:

УІ

Кафедра:

Не вказано

Інформація про роботу

Рік:

2013

Тип роботи:

Розрахункова робота

Предмет:

Інформаційно-аналітичне забезпечення безпеки

Завантажити

Частина тексту файла (без зображень, графіків і формул):

МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ «ЛЬВІВСЬКА ПОЛІТЕХНІКА» / Розрахункова робота з курсу: «Інформаційно-аналітичне забезпечення безпеки» на тему: «Методи побудови VPN на мережевому рівні» Львів - 2013 1. Поняття і класифікація VPN мереж 1.1 Що таке VPN VPN (Virtual Private Network - віртуальна приватна мережа) - логічна мережа, що створюється поверх іншої мережі, наприклад Internet. Незважаючи на те, що комунікації здійснюються по публічних мереж з використанням небезпечних протоколів, за рахунок шифрування створюються закриті від сторонніх канали обміну інформацією. VPN дозволяє об'єднати, наприклад, кілька офісів організації в єдину мережу з використанням для зв'язку між ними непідконтрольних каналів. За своєю суттю VPN володіє багатьма властивостями виділеної лінії, проте розгортається вона в межах загальнодоступної мережі, наприклад Інтернету. За допомогою методики тунелювання пакети даних транслюються через загальнодоступну мережу. Між кожною парою «відправник-одержувач даних» встановлюється своєрідний тунель - безпечне логічне з'єднання, що дозволяє інкапсулювати дані одного протоколу в пакети іншого. Основними компонентами тунелю є: · Ініціатор · Маршрутизуються мережу; · Тунельний комутатор; · Один або кілька тунельних термінаторів. Сам по собі принцип роботи VPN не суперечить основним мережних технологій і протоколів. 1.2 Класифікація VPN мереж Існують різні типи VPN і, залежно від функціональних вимог, різні методи їх побудови. Процес вибору може включати розгляд того, яка проблема вирішується, аналіз ризику при захисті інформації, передбаченому для конкретних впроваджень, питання масштабування при збільшенні розміру VPN, складності провадження VPN, а також обслуговування та відмовостійкості. Для спрощення опису різних типів VPN їх ділять на категорії, розміщені на різних рівнях системи протоколів TCP/IP. За типом використовуваного середовища: · Захищені VPN мережі. Найбільш поширений варіант приватних мереж. З його допомогою можливо створити надійну і захищену підмережу на основі ненадійної мережі, як правило, Інтернету. Прикладом захищених VPN є: IPSec, OpenVPN і PPTP. · Довірчі VPN мережі. Використовуються у випадках, коли передавальне середовище можна вважати надійним і необхідно вирішити лише завдання створення віртуальної підмережі в рамках більшої мережі. Питання забезпечення безпеки стають неактуальними. Прикладами подібних VPN рішенні є: MPLS та L2TP. Коректніше сказати, що ці протоколи перекладають завдання забезпечення безпеки на інші, наприклад L2TP, як правило, використовується в парі з IPSec. 2. За способом реалізації: · VPN мережі у вигляді спеціального програмно-апаратного забезпечення. Реалізація VPN мережі здійснюється за допомогою спеціального комплексу програмно-апаратних засобів. Така реалізація забезпечує високу продуктивність і, як правило, високий ступінь захищеності. · VPN мережі у вигляді програмного рішення. Використовують персональний комп'ютер зі спеціальним програмним забезпеченням, що забезпечує функціональність VPN. · VPN мережі з інтегрованим рішенням. Функціональність VPN забезпечує комплекс, вирішує також завдання фільтрації мережевого трафіку, організації мережного екрану і забезпечення якості обслуговування. 3. За призначенням: · Intranet VPN. Використовують для об'єднання в єдину захищену мережу кількох розподілених філій однієї організації, які обмінюються даними по відкритих каналах зв'язку. · Remote Access VPN. Використовують для створення захищеного каналу між сегментом корпоративної мережі (центральним офісом або філією) і одиночним користувачем, який, працюючи вдома, підключається до корпоративних ресурсів з домашнього комп'ютера або, перебуваючи у відрядженні, підключається до корпоративних ресурсів за допомогою ноутбука. · Extranet VPN. Використовують для мереж, до яких підключаються «зовнішні» користувачі (наприклад, замовники або клієнти). Рівень довіри до них набагато нижче, ніж до співробітників компанії, тому потрібне забезпечення спеціальних «рубежів» захисту, що запобігають або обмежують доступ останніх до особливо цінної, конфіденційної інформації. 4. За типом протоколу: Існують реалізації віртуальних приватних мереж під TCP / IP, IPX і AppleTalk. Але на сьогоднішній день спостерігається тенденція до загального переходу на протокол TCP / IP, і абсолютна більшість VPN рішень підтримує саме його. 5. За рівнем мережевого протоколу: За рівнем мережевого протоколу на основі зіставлення з рівнями еталонної мережевої моделі ISO / OSI. 2. Віртуальні мережі Мережевого рівня Мережевий рівень стеку протоколів TCP/IP містить систему IP-раутінгу. Існують декілька методів побудови VPN на Мережевому рівні. Із цієї точки зору доцільно здійснити короткий огляд відмінностей між моделями VPN – модель партнерів (peer) і модель накладання (overlay). У певному спрощенні, VPN-модель партнерів – це така, в якій обчислення шляху пересилання на Канальному рівні здійснюється на основі послідовних стрибків, де кожен вузол у проміжному шляху пересилання даних є партнером вузла для наступного стрибка. Традиційні маршрутовані мережі є прикладом моделі партнерів, бо кожен раутер на шляху є партнером свого сусіда для наступного стрибка. На відміну від цього, модель VPN з накладанням – це така модель, у якій проміжна мережа Канального рівня використовується для транзиту до іншого крайнього вузла на протилежному кінці мережі. Прикладами такої моделі є впровадження ATM, Frame Relay і тунелювання. Слід відзначити, що модель з накладанням створює серйозні проблеми з масштабуванням у випадках, коли вимагається велика кількість вхідних партнерів. Це витікає з факту, що кількість сусідів зростає у прямій залежності від кількості вхідних партнерів. Прості приклади цих двох моделей показані на рис.1 . Нехай роутери, які оточують внутрішню комутовану інфраструктуру, репрезентують вхідних партнерів і комутатори в основній внутрішній мережі сконфігуровані так, що всі вхідні вузли забезпечують тільки один стрибок на Рівні 3 до будь-якого іншого, утворюючи транзитну мережу. Це основа для мережі з накладанням. На відміну від цього, якщо комутатори були б замінені роутерами, то роутери, розташовані на краях мережі, тепер стають партнерами з роутерами наступного стрибка, а не з іншими вхідними роутерами. Це основа для VPN-моделі партнерів. Рис. 1. Модель VPN з накладанням (а) і модель партнерів (б). 2.1 Фільтрування маршрутів. Фільтрування матшрутів – це метод, у якому основна мережа здійснює тільки управління маршрутами до пункту, де тільки певні мережі приймають маршрути для інших мереж, які належать до їх власної спільноти за інтересами. Ця модель може розглядатися як модель партнерів, бо роутер всередині пункту VPN встановлює відносини роутінгу з роутером всередині мережі VPN-провайдера замість встановлення наскрізних відносин партнерства з роутерами в інших пунктах цієї VPN. Якщо спільний основний Internet взагалі переносить маршрути від усіх мереж, під’єднаних до нього, то архітектура даної моделі приймає, що тільки підмножина таких мереж формує VPN. Маршрути для цієї підмножини мереж фільтруються так, що вони не анонсуються до будь-якої іншої групи сполучених мереж і що всі інші не-VPN-маршрути не анонсуються у мережах, які належать до VPN. Рис. 2 Фільтрування маршрутів. Наприклад, на рис.2, якщо роутери сервіс-провайдера (SP) фільтрують роутінгову інформацію, прийняту від одного пункту мережі A до інших пунктів мережі A, то пункти, що не належать до мережі A (наприклад, пункти мережі B) не можуть знати про будь-які інші мережі, під’єднані до інфраструктури сервіс-провайдера (рис. 2). Таким чином, приватність послуг тут впроваджується через відсутність можливості для станцій даної VPN відповідати на пакети, які мають адресу джерела з-поза спільноти вузлів даної VPN. Таке використання часткової роутінгової інформації піддане багатьом видам помилкового конфігурування. Однією можливою проблемою з фільтрацією маршрутів є те, що вона дуже складна, якщо взагалі можлива, при забороні для абонентських мереж вказувати за замовчуванням на вхідний роутер наступного стрибка для трафіку, призначеного мережам поза спільнотою даної VPN. Однак поширеним явищем у VPN є те, що замовник сам конфігурує і адмініструє роутери в своєму розташуванні. Тоді з боку сервіс-провайдера доцільно помістити фільтри трафіку на роутері першого стрибка, щоб заборонити весь трафік, призначений для мереж поза спільнотою інтересів даної VPN. Слід також відзначити, що це середовище посередньо припускає існування спільного ядра роутінгу. Це, у свою чергу, веде до того, що кожна VPN повинна вживати адреси, які не перетинаються з адресами будь-якої іншої VPN у тій самій спільній інфраструктурі, і не може оголошувати довільні приватні адреси у VPN. Побічним ефектом у цій формі структури VPN є те, що дві VPN не можуть мати одного пункту взаємосполучення, або VPN у такому середовищі не може оперувати одним пунктом сполучення з Internet. Так званий “шлюз”, де весь зовнішній трафік пересилається через контрольний пункт, може регулювати як певні форми політики доступу, так і вести реєстр зовнішніх транзакцій. Спільне ядро роутінгу використовує один взірець роутінгу, базований виключно на адресі призначення. З іншого боку необхідно відзначити, що ця вимога виявляє одну із двоїстостей архітектур VPN. Віртуальні приватні мережі повинні оперувати у середовищі, ворожому щодо них, тому повинна здійснюватися протидія будь-якій вразливості, яку виявляє приватне середовище щодо доступу до нього з боку зовнішньої третьої групи. Однак віртуальні приватні мережі рідко є справді ізольованим середовищем і звичайно всі вони здійснюють певні форми зовнішньої взаємодії, дозволяючи конрольовану досяжність до інших VPN і до поширених публічних мереж. Протиріччя між захистом приватності та потребою зовнішнього доступу є постійною властивістю віртуальних приватних мереж. Впровадження сполучності між VPN вимагає від мережі маршрутування зовнішніх пакетів до пункту взаємозв’язку VPN і, якщо вони визнаються у пункті взаємозв’язку VPN, то вони можуть бути вислані через мережу за потрібною адресою призначення. Без використання технології трансляції мережевих адрес (Network Address Translation – NAT) у пункті взаємозв’язку входу до VPN, цей вид комунікаційної структури не може підтримуватися у наведеній архітектурі VPN (рис.3 ). Рис.3 . Використання трансляції мережевих адрес. Загалом техніка підтримки приватних спільнот за інтересами тільки шляхом фільтрації маршрутів є примітивним методом побудови VPN, схильним до адміністративних помилок і надмірного рівня незахищеності та мережевої негнучкості. Навіть із всеохоплюючою фільтрацією трафіку та маршрутів результуюче середовище не повністю стійке. Операційне службове навантаження, необхідне для підтримки додаткових систем традиційних фільтрів для роутінгу і трафіку із використанням сучасних технологій роутінгу, не дозволяє перевищити межу кількості VPN понад декілька сотень. Більші можливості для масштабованості надає використання BGP-спільнот як методу управління поширенням маршрутів. Використання атрибутів BGP-спільнот дозволяє провайдеру VPN “позначати” інформацію досяжності Мережевого рівня BGP (BGP Network Layer Reachability Information – BGP NLRI) атрибутами спільноти, так що управління конфігуруванням дозволяє поширювати роутингову інформацію відповідно до профілю спільноти (рис.4 ). Рис. 4. Спільноти BGP. Внаслідок того факту, що трафік від різних спільнот за інтересами повинен перетинати спільну інфраструктуру, реальна приватність даних відсутня в цій частині мережі, однак можна сказати, що доки сполучені підмережі або абоненти VPN-послуг не здатні виявити, що існують інші абоненти послуг, доти потоки трафіку даних багатьох абонентів пересилаються незахищеним чином у ядрі мережі надавача послуг. 2.2 Тунелювання. Рис. 5. Традиційна модель тунелювання. Висилання певної частини мережевого трафіку через тунель є іншим методом побудови VPN, більш ефективним від інших. Найбільш поширеним механізмом тунелювання є використання загальної роутингової інкапсуляції (Generic Routing Incapsulation – GRE) між джерелом і роутером призначення, між роутерами, або протоколів тунелювання між станціями, таких як L2TP, PPTP і DVMRP. Тунелювання можна розглядати як модель накладання, однак серйозність впливу масштабування приводить до того, що тунелі здійснюють за схемами “пункт-пункт” або “пункт-багато пунктів”. Тунелі “пункт-пункт” мають менше проблем з масштабуванням, ніж тунелі “пункт-багато пунктів”, за винятком ситуацій, коли окремий вузол починає будувати багато тунелів “пункт-пункт” з багатьма кінцевими пунктами. Коли лінійна проблема масштабування уведена від цього пункту, то керованість тунелів “пункт-пункт” здійснюється виключно через адміністративне навантаження і тим самим через самі тунелі. З другого боку, тунелі “пункт-багато пунктів”, які використовують транзитний механізм, щоб збільшити кількість кінцевих пунктів на відстані одного стрибка від довільного іншого, потім створюють значно більш серйозну проблему масштабування. 2.2.1 Традиційний режим тунелювання Тунелі GRE загалом конфігуруються між джерельним (вхідним) роутером і роутером призначення (вихідним), так що пакети, призначені для пересилання крізь тунель (вже форматовані із інкапсуляцією даних у заголовок “звичайного” пакету, визначеного протоколом), інкапсулюються з новим заголовком (заголовком GRE) і поміщаються в тунель з адресою призначення до кінцевого пункту тунелю (нового наступного стрибка). Коли пакет досягає кінцевий пункт тунелю, заголовок GRE видаляється і пакет пересилається до призначення, як вказано в заголовку оригінального IP-пакету (рис. ). Тунелі GRE у загальному випадку є тунелями “пункт-пункт”, тобто для тунелю існує одна адреса джерела і звичайно один кінцевий пункт тунелю. Однак існують певні впровадження виготівників, які дозволяють конфігурувати тунелі “пункт-багато пунктів”, які мають одну адресу джерела і багато призначень. Коли це впровадження загалом вживається із протоколом роутінгу з наступним стрибком (Next-Hop Routing Protocol – NHRP), то ефективність і вигідність NHRP є сумнівною і повинна тестуватися перед впровадженням. Варто відзначити, що NHRP відомий здатністю створювати петлі, коли він вживається для встановлення скорочень між роутерами. Однак тунелі мають ряд дуже привабливих властивостей при використанні для побудови VPN. Архітектурна концепція полягає у створенні віртуальних приватних мереж як сукупності тунелів через спільну основну мережу. Кожен пункт під’єднання до спільної мережі конфігурується як фізичний зв’язок, який використовує адресацію і роутінг від спільної основної мережі та один або декілька сумісних тунелів. Кожен кінцевий пункт тунелю логічно пов’язує цей пункт під’єднання до інших віддалених пунктів у тій самій VPN. Техніка тунелювання використовує вхідну адресу тунелю, визначену всередині адресного простору спільної основної мережі, тоді як пакети, які транспортуються всередині тунелю, вживають адресний простір VPN, що у свою чергу змушує кінцеві пункти тунелю до розміщення у тих пунктах мережі, де VPN і основна мережа взаємосполучені. Перевага такого підходу полягає в тому, що роутінг для VPN ізольований від роутінгу у спільній основній мережі. Віртуальні приватні адреси можуть знову використовувати той сам адресний простір всередині багатьох VPN без жодного взаємного впливу, що забезпечує значну незалежність VPN від основної мережі. Ключова вимога для багатьох VPN полягає в тому, що ці VPN звичайно не можуть вживати глобально унікальний або скоординований адресний простір, і це часто є послідовною вимогою для підтримки багатьох VPN, які незалежно вживають той самий блок адрес. Така конфігурація не може підтримуватися всередині архітектури VPN із керованою фільтрацією маршрутів. Тунель також може інкапсулювати різні сімейства протоколів, так що можна імітувати багато функціональних можливостей виділених приватних мереж. Знову, вимога щодо підтримки багатьох протоколів у форматі, який забезпечує функціональність цих протоколів, є критичною вимогою для багатьох архітектур підтримки VPN. Коли спільна IP-мережа не може підтримувати такі послуги при керованому фільтруванні маршрутів, то архітектура тунелювання може сегментувати VPN-приватний протокол у спільній основній мережі. Іншою суттєвою перевагою тунелювання є відділення спільного основного середовища роутінгу від роутінгу у VPN. Для VPN спільна основна мережа допускає власність певної кількості кіл “пункт-пункт” і VPN може використовувати протокол роутінгу через віртуальну мережу, який узгоджує адміністративні вимоги VPN. Так само спільна основна мережа може використовувати побудову роутінгу, яка узгоджена з адміністративними вимогами основної мережі (або сукупності основних мереж) і не обмежується протоколами роутінгу, використаними клієнтськими мережами VPN. Могло б здаватися, що тунелювання GRE є універсальним засобом для побудови VPN. Однак існують певні недоліки при використанні тунелів GRE як механізму для VPN, переважно внаслідок адміністративного навантаження, масштабування при великій кількості тунелів, якості послуг і характеристик. Оскільки тунелі GRE повинні конфігуруватися вручну, то існує пряма залежність між кількістю тунелів, які повинні бути сконфігуровані, та обсягом адміністративного навантаження, необхідного для їх конфігурування та обслуговування, бо кожного разу, коли кінцеві пункти тунелю повинні бути змінені, то вони мусять бути переконфігуровані вручну. Також доки обсяг обробки даних, необхідний для інкапсуляції пакетів для GRE залишається малим, доти існує пряма залежність між кількістю конфігурованих тунелів і загальним обсягом обробки, необхідної для GRE-інкапсуляції. До речі, тунелі можуть бути структуровані для автоматичного перемикання, але існує ряд недоліків такого підходу, які диктуються старанним розглядом пов’язаних питань роутінгу і характеристик. Найгіршим випадком такого автоматичного генерування тунелю є виникнення конфігураційної петлі, коли тунель пересилає трафік до себе самого. Ефективність роутінгу також зменшується внаслідок великої кількості суміжних партнерів роутінгу при повній сітці тунелів. Додаткові турботи при тунелюванні GRE викликає здатність механізмів класифікації трафіку до ідентифікації трафіку з достатньо дрібною деталізацією, яка не ставала б завадою для характеристик пересилання. Якщо процес класифікації трафіку, використаний для ідентифікації пакетів (які повинні пересилатися через тунель), заважає обслуговувати прийнятні швидкості пересилання пакетів, то це приводить до погіршення характеристик. Приватність мережі обмежена вразливістю тунелю і не є абсолютною. Пакети, які використовують форматування GRE, можуть бути уведені у VPN від джерел із третьої сторони. Щоб досягнути вищого ступеня цілісності приватності VPN, необхідно впровадити вхідні фільтри, узгоджені з конфігурацією тунельної структури. Також необхідно гарантувати, щоб роутери CPE адмініструвалися надавачем послуг VPN, бо конфігурування кінцевих пунктів тунелю є критичною компонентою загальної архітектури цілісності приватності. Існує проблема із використанням GRE-тунелів у такий спосіб, бо більшість надавачів послуг VPN не бажають адмініструвати роутери CPE. Дехто навіть може вказувати, що наявність виділеного роутера CPE заперечує одній з основних передумов VPN – використанню спільної інфраструктури для зменшення загальних мережевих коштів. У моделі VPN з накладанням відсутнє управління, за допомогою якого здійснювалося б виділення шляху в основній спільній мережі або забезпечувалася б стабільність такого шляху, що може приводити до погіршення характеристик VPN. Крім технологічних аспектів, головним питанням є те, чи адміністрування VPN передоручається мережевому провайдеру, чи здійснюється у межах адміністративних функцій VPN. Одне з більш серйозних питань при побудові VPN за допомогою тунелювання є те, чи не існує віртуального способу визначення вартості маршруту через тунель, оскільки справжній шлях маскується транзитною природою тунелю. Це веде до дуже неоптимального роутінгу в тому сенсі, що пакет може проходити шлях, визначений механізмом транзитного пересилання, який є суттєво неоптимальний, тоді як природні протоколи роутінгу з наступним стрибком могли б знайти більш ефективний спосіб для пересилання пакетів до їх призначення. 2. 2.2 Віртуальні приватні мережі з доступом через комутовані канали Існують окремі технології (із використанням власних механізмів виготівників, так і механізмів, базованих на стандартах), наявні для побудови віртуальних приватних мереж з доступом через комутовані канали (Virtual Private Dial Network –VPDN). Зокрема, два принципові методи впровадження VPDN, популярність яких зростає – це тунелі L2TP і PPTP. З історичної перспективи L2TP є технічним об’єднанням специфікації більш раннього протоколу L2F і протоколу PPTP. Оскільки PPTP включений до операційних систем більшості персональних комп’ютерів, то він стає більш популярним. Із цієї точки зору слід відзначити різницю між тунелями, ініційованими клієнтом, і ініційованими сервером мережевого доступу (Network Access Server – NAS). Перший раніше називали “добровільним” тунелем, тоді як другий –“вимушеним” тунелем. Добровільний тунель називається так тому, що тунель створюється на запит користувача для спеціального призначення; вимушений тунель створюється без жодної дії з боку користувача і не дозволяючи йому жодних змін по суті. L2TP як модель із вимушеним тунелюванням – це механізм “вивантаження” абонента комутованих каналів до іншого пункту мережі або до іншої мережі. У цьому сценарії абонент викликає мережевий сервер доступу (Network Access Server – NAS), базуючись на локально сконфігурованому профілі або на узгодженнях NAS із сервером політики захисту та ефективній аутентифікації. Тунель L2TP динамічно встановлюється до наперед визначеного кінцевого пункту, у якому закінчується сесія PPP (рис.6 ). Рис.6. Механізм тунелювання з використанням L2TP. PPTP як модель з добровільним тунелюванням дозволяє робочій станції конфігурувати і встановлювати індивідуальні тунелі “пункт-пункт” до довільно розташованих PPTP-серверів без проміжної участі NAS в узгодженнях і встановленні тунелю. У цьому сценарії абонент комутованих каналів здійснює виклик до NAS, однак PPP-сесія завершується в NAS як у традиційній моделі PPP. Наступна PPTP-сесія тоді встановлюється між кінцевою системою клієнта і довільним вихідним PPTP-сервером, із яким клієнт бажає встановити з’єднання і який може бути досяжний через традиційну роутінгову інформацію. Після цього користувач надає певні повноваження PPTP-серверу (рис.7 ). Рис.7 Механізм тунелювання з використанням PPTP. 2.3. Шифрування на Мережевому рівні Технології шифрування надзвичайно ефективні для забезпечення сегментації та віртуалізації, необхідних для VPN, і можуть бути впроваджені майже на кожному рівні стеку протоколів. Розвиненим стандартом для шифруванні на Мережевому рівні в Internet є IPSec (IP Security). Список літератури P. Ferguson, G. Huston. What is a VPN? http://firstvpn.com/papers/cisco/vpn.pdf Virtual Private Networking: An Overview. – http://msdn.microsoft.com/workshop/server/feature/vpnovw.asp J. M. Davidson. Virtual Private Networks: The Next Evolutionary Step. – http://www.nts.com/library/tlvpnhtppr.html PPTP and Implementation of Microsoft Virtual Private Networking. – http://www.zeev.com/Inter/nrpptp.htm Virtual Private Network Security Components. A technical White Paper. – http://www.checkpoint.com/products/vpn1/vpnwp.html J. Ryan. A Practical Guide to the Right VPN Solution. The Technology Guide Series. – http://www.techguide.com J. Ryan. Designing and Implementing a Virtual Private Network (VPN). The Technology Guide Series. – http://www.techguide.com J. Ryan. How to Build Secure LANs with IPSec. The Technology Guide Series. – http://www.techguide.com

Розрахункова робота Інформаційно-аналітичне забезпечення безпеки

Tatti

18.09.2013 13:09-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись