Чи можливо об'єднати Інтернет-провайдер і мобільний телефон? Я хочу розділити завантаження та завантаження [дублікат]

Я хотів би використовувати свій Інтернет-провайдер лише для завантаження, а 4G-з'єднання мобільних телефонів лише для завантаження. Це тому, що швидкість завантаження провайдера у мене низька, але завантаження нормально, а завантаження 4G - чудове та безкоштовне (я плачу лише за завантаження).

Так один ПК, два з'єднання: ISP для завантаження та 4G для завантаження. За це я б платив так само, як сьогодні, але збільшив завантаження з 0,1 Мбіт / с до приблизно 60 Мбіт / с.

Хоча розділити завантаження та завантаження між з'єднаннями практично неможливо (як детально описано в інших відповідях), можливе ручне вирішення.

Ви можете маніпулювати з'єднанням за замовчуванням, перемикаючи його залежно від завдання, яке ви хочете розпочати. З'єднання за замовчуванням у Windows спочатку підключений інтерфейс, його порядок обчислюється метрикою (яка, як правило, ставить бездротовий вище кабелю).

Ви можете легко перекрити метрику ручним порядком у розширених налаштуваннях мережевих підключень. Як змінити з'єднання за замовчуванням у Windows . (Має працювати однаково від XP до 8.1 з незначними або без відмінностей)

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

Майте на увазі, що деякі програми (наприклад, менеджери завантаження / завантаження) відкриватимуть з'єднання за завданням, а не за сеанс, тому ваш пробіг може відрізнятися.

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

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

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

Доповнення: Це може бути можливим, але обсяг реалізації цього робить непрактичним. Крім того, навіть якщо вам вдасться завантажити весь свій трафік на мобільний прив’язок, як довго, на вашу думку, пройде, перш ніж ISP оновить ваші умови обслуговування? Там, швидше за все, є політика добросовісного використання. Ось вимоги.

• IP-код підключення джерела трафіку, що виходить за допомогою мобільного зв'язку, відповідає трафіку, який виходить через з'єднання провайдера, щоб він повертався через Інтернет-провайдер. Це можна зробити за допомогою iptables.
• Маршрут місцевого трафіку за допомогою мобільного канату. Щось таке: 'route add 192.168.0.0/16 mask 255.255.0.0 [зовнішній IP мобільного тетера]. Можливо, запустіть DDNS, щоб уникнути необхідності часто оновлювати це.

http://lartc.org/howto/lartc.rpdb.multiple-links.html

https://sandilands.info/sgordon/address-spoofing-with-iptables-in-linux

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

Можна використовувати обидва Інтернет-доступу для обміну завантаженням завантаження / завантаження, але завжди лише за з'єднання. Отже, одне з'єднання TCP (або UDP) може переходити лише через одне посилання. Це згадується і в іншій відповіді - для вихідних пакетів TCP ви повинні отримувати пакети підтвердження, і вони повинні проходити через той самий інтерфейс.

Ви можете вручну змінити таблицю маршрутизації, наприклад, перед тим, як робити велику завантаження на YouTube, щоб переадресувати весь трафік на YouTube через Інтернет із більшою швидкістю завантаження, а потім змінити його назад. Але це буде важко, оскільки youtube використовує багато різних IP-адрес (маршрутизація працює на IP, а не на імена хостів). Але для FTP-сервера компанії це може бути здійснено.

Це стосується всього домашнього доступу до Інтернету, де вам надається IP-адреса від вашого провайдера. Отже, на першому ISP ви отримуєте, наприклад, IP 1.2.3.4, але на мобільний телефон ви отримуєте IP свого оператора телефонної мережі, наприклад 5.6.7.8. Весь зв'язок (вихідні та вхідні дані) повинен мати лише одну з цих IP-адрес.

Для комерційного та серверного хостингу в Інтернеті ви можете отримати одну IP-адресу, яка не залежить від провайдера, і ви можете одночасно використовувати більше Інтернет-з'єднань.

Ви повинні мати з'єднання з накладенням (тунель), яке підтримує різні кінцеві точки для потоку вгору та за течією. Єдиний мені відомий протокол, який в основному підтримує це LISP (протокол поділу ідентифікатора локатора). Якщо ви можете знайти провайдера LISP недалеко від вас, можливо, ви зможете придбати у них послугу на додаток до ваших поточних з'єднань. Це, мабуть, не буде безкоштовно.

Технічно кажучи, ця можливість вбудована у всі мережі, побудовані на основі IP-адреси (у вас має бути IP-адреса, яка публічно може бути маршрутизована) та активована лише шляхом зміни таблиці маршрутизації на стороні клієнта. Швидше за все, трафік, призначений для власної локальної мережі провайдера, буде продовжувати надсилатися через цей інтерфейс, тоді як увесь інший трафік буде виходити через ваш шлюз за замовчуванням.

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

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

Якщо у вас немає загальнодоступної IP-адреси, то, крім фільтрування зворотного шляху, шар NAT / PAT не дозволить цьому працювати (ваша вихідна IP-адреса, використовувана вашим комп'ютером, буде безглуздою для іншої мережі, і не буде правильно переписати, якщо пакет не виходить через маршрутизатор NAT / PAT).

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

Отже, "все", що вам потрібно зробити, - це переконати свого Інтернет-провайдера (включаючи їх постачальників вгору за течією) або (а) відключити фільтрацію зворотного шляху або (b) встановити небажаний маршрут. Цього не відбудеться, основні маршрутизатори не можуть обробити три мільярди маршрутів, щоб мати один для кожної унікальної публічної IP-адреси. Тому дуже рідко є маршрути для будь-якого блоку менше / 20, за винятком внутрішнього провайдера, де маршрути існують для всіх локальних підмереж.

Коротка відповідь: у 95% випадків цього неможливо зробити, а ваш - це 95% випадків.

По-перше, дозвольте мені сказати, що мало сенсу говорити про маршрутизацію окремо для завантаження та завантаження, тому що навіть для завдань з інтенсивним завантаженням деякі пакети вимагають потоку назад до джерела, тобто будь-яке завантаження вимагає певного потоку завантаження (це менш справедливо для UDP, ніж для TCP, але це не забувайте).

Якби ми каналізували завантаження з’єднання, яке здебільшого завантажувалося, через інший NIC, ніж той, який використовується для завантаження, джерело завантаження побачило б, що відповіді на його пакети походять з іншої IP-адреси, ніж тієї, на яку він відправлення пакетів; це основна функція захисту - ігнорування пакетів, які вважають, що вони пов'язані з певним з'єднанням, але походять від сторонніх адрес. Отже, частина розмови для завантаження буде припинена, а зв’язок припиниться. Це мало спільного з провайдерами та їх послугами: це відбувається навіть між двома ПК в одній локальній мережі, якщо одна з двох намагається підключитися до IP-адреси, використовуючи в одному і тому ж з'єднанні два різних NICS (отже, два різних IP-адреси) .

Це причина, чому ми говоримо про з'єднання, а не для завантаження / завантаження. Але тоді можна переформулювати ваше запитання наступним чином: чи можу я мати ПК, який має два NIC, підключені до мережі, використовувати два NIC для двох різних з'єднання, скажімо, повільне з'єднання для повільної, виснажливої ​​роботи, наприклад електронної пошти, і швидке з'єднання для швидкого процесу, як завантаження веб-сторінки?

Коротка відповідь на це добре поставлене питання: у Windows, * Nix (включаючи MacOS) та Android no.У Linux так, ви можете.

Причина, чому ви не можете цього зробити в Windows (будь-якій версії), * Nix та Android, полягає в тому, що будь-яка таблиця маршрутизації може мати лише один шлюз за замовчуванням (* тобто * адреса, на яку ви надсилаєте всі пакети, не призначені для вашої локальної мережі), і ці ОС може обробляти лише одну таблицю маршрутизації: отже, єдиний шлюз.

Натомість, для того, щоб розподілити різні програми на різні інтерфейси, вам потрібні два різних функціональності: один, можливість двох запускати дві таблиці маршрутизації одночасно, і два, можливість прив’язувати програми до будь-якої таблиці маршрутизації. Тільки ядро ​​Linux (на кілька років, що випереджає конкуренцію) має ці можливості, як це було написано. Ядро * Nix частково компенсує це шляхом розумного використання свого брандмауера, pfsense, не досягнувши, проте, повного результату.

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

Однак для того, щоб використовувати різні NIC (і, отже, IPS) залежно від програми, потрібні простори мережних імен , функція ядра Linux, яка дозволяє створити окрему оболонку з власним мережевим стеком. Тепер процеси, запущені всередині цієї окремої оболонки, будуть спрямовані відповідно до таблиці маршрутизації простору мережевих імен, а не для основного ПК.

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

Підводячи підсумок, в Linux (і тільки в Linux) ви можете запустити окремий мережевий простір імен, який, наприклад, підключений через VPN до робочого місця, щоб ви отримали доступ до своїх робочих ресурсів, і, якщо ви запускаєте Firefox, здається, ви бачитесь на своєму робочому місці, одночасно працюючи в Google Chrome поза мережевим простором імен, і, таким чином, вам здається, що ви бачитесь вдома.

Розщеплення пов'язаних з'єднань між різними постачальниками буде можливим лише у тому випадку, якщо у вас є одна IP-адреса, досяжна / маршрутна від обох постачальників. Цей IP зазвичай надається вам як частина більшого блоку адрес через BGP. І якби у вас це було, ви могли б зробити це за допомогою BGP, використовуючи в BGP функцію, що називається попередньо відкладений шлях та правилами місцевих переваг.

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

Якщо з іншого боку, ви насправді запитуєте, чи можна віддавати перевагу з’єднанню 4G для сеансу завантаження, як правило, під час завантаження файлів через ftp / sftp або http. А для звичайного веб-перегляду цей трафік використовує ваш Інтернет-провайдер, тоді я думаю, що відповідь може бути. Але, можливо, для роботи вам доведеться класифікувати сеанс як завантажувальний або завантажувальний. Оскільки ftp і http та інші протоколи можна використовувати однаково для завантаження чи завантаження, ви не можете визначити це за номером порту. Тож єдиною альтернативою є перегляд даних середнього потоку. На цьому етапі рішення було б прийняте, оскільки дані вже надходять. Тож це неможливо автоматизувати.

Отже, у вашому випадку. НІ. (принаймні, не тоді, коли ти на березі).

Вам потрібен хост, яким ви керуєтеся доступними з обох підключень.

Налаштуйте на цьому хості два тунелі VPN, кожен з яких переходить з іншого інтерфейсу на вашій стороні. Як тільки у вас з’явиться, це як би мати два кабелі Ethernet. Ви можете використовувати зв'язок, щоб використовувати їх разом як більший кабель, а потім спробувати пропустити трафік через нього.

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