Протягом багатьох років преса писала про проблему, що зараз доступно дуже мало адрес IPv4. Але з іншого боку, я використовую серверну хостингову компанію, яка за невелику суму з радістю видає публічні IPv4 адреси. І моє приватне підключення до Інтернету має публічну IPv4-адресу.

Як це можливо? Невже проблема є такою поганою, як преса хоче, щоб ми вірили?

Це дуже погано. Ось перелік прикладів того, що я маю з перших рук із споживачами Інтернет-провайдерів, які роблять боротьбу з дефіцитом IPv4-адрес:

• Неодноразово пересуваючись навколо блоків IPv4 між містами, що спричиняє короткочасні відключення та скидання з'єднань для клієнтів.
• Скорочення часу оренди DHCP - від днів до хвилин.
• Дозвольте користувачам обирати, чи хочуть вони перекладати мережеві адреси (NAT) на обладнання для обслуговування клієнтів (CPE) чи ні, а потім заднім числом увімкніть його для всіх.
• Увімкнення NAT в CPE для клієнтів, які вже використали можливість відмовитися від NAT.
• Зменшення максимальної кількості одночасно активних адрес управління доступом до засобів масової інформації (MAC), що застосовуються CPE.
• Розгортання NAT (CGN) для клієнтів, які мали реальну IP-адресу під час реєстрації в послузі.

Все це знижує якість продукту, який Інтернет-провайдер продає своїм клієнтам. Єдине розумне пояснення того, чому вони роблять це своїм клієнтам, - це брак IPv4-адрес.

Дефіцит адрес IPv4 призвів до фрагментації адресного простору, що має кілька недоліків:

• Адміністративні витрати, які не тільки коштують часу та грошей, але також схильні до помилок і призводять до відключень.
• Велике використання ємності з адресною пам’яттю для вмісту (CAM) на магістральних маршрутизаторах, які через кілька років призвели до значного виходу з ладу декількох провайдерів, коли вони перейшли межу конкретної популярної моделі маршрутизаторів.

Без NAT не обійтися сьогодні з 3700 мільйонами маршрутизованих IPv4 адрес. Але NAT - крихке рішення, яке дає вам менш надійний зв’язок і проблеми, які важко налагодити. Чим більше шарів NAT, тим гірше буде. Два десятиліття напруженої роботи змусили одного шару NAT здебільшого працювати, але ми вже перейшли ту точку, коли одного шару NAT було достатньо, щоб подолати дефіцит IPv4-адрес.

Перш ніж у нас почали вичерпуватися адреси IPv4, ми не (широко) використовували NAT. Кожен комп'ютер, підключений до Інтернету, мав би свою унікальну глобальну адресу. Коли NAT був вперше представлений, він повинен був перейти від надання клієнтам ISP 1 реальної адреси на пристрій, який користувач / користувач використовував, до надання 1 клієнту 1 реальної адреси. Це вирішило проблему на деякий час (роки), коли ми повинні були перейти на IPv6. Замість переходу на IPv6 (здебільшого) всі чекали, коли всі перемкнуться, і тому (в основному) ніхто не скачував IPv6. Зараз ми знову стикаємося з тією ж проблемою, але цього разу розгортається другий шар NAT (CGN), щоб провайдери могли ділитися 1 реальною адресою між декількома клієнтами.

Виснаження IP-адреси не є великою справою, якщо NAT не страшний, в тому числі, коли кінцевий користувач не має над ним контролю (Carrier Grade NAT або CGN).

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

Отже (на мій погляд), чому НАТ - страшна, зла справа, якої слід уникати?

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

• Незалежність мережевого шару
• Зв'язки однорангових
• Послідовне іменування та розташування ресурсів
• Оптимальна маршрутизація трафіку, хости знають свою реальну адресу
• Відстеження джерела шкідливого трафіку
• Мережеві протоколи, які розділяють дані та контролюють окремі з'єднання

Подивимось, чи можу я пояснити кожен із цих пунктів.

Незалежність мережевого шару

Постачальники провайдерів повинні просто проходити навколо пакетів 3 рівня і не хвилюватись, що знаходиться в шарах вище цього. Якщо ви обходите TCP, UDP чи щось краще / більш екзотичне (можливо, SCTP? Або навіть якийсь інший протокол, який кращий, ніж TCP / UDP, але незрозумілий через відсутність підтримки NAT), ваш ISP не повинен турбота; все це повинно просто виглядати як дані для них.

Але це не так - не тоді, коли вони реалізують "другу хвилю" NAT, "Carrier Grade" NAT. Тоді вони обов'язково повинні переглядати та підтримувати протоколи 4 рівня, які ви хочете використовувати. Зараз це практично означає, що ви можете використовувати лише TCP та UDP. Інші протоколи будуть або просто заблоковані / скинуті (переважна більшість випадків у моєму досвіді), або просто передані останньому хосту "всередині" NAT, який використовував цей протокол (я бачив 1 реалізацію, яка робить це). Навіть пересилання до останнього хоста, який використовував цей протокол, не є справжнім виправленням - як тільки два хости використовують його, воно порушується.

Я думаю, що є деякі протоколи заміни TCP & UDP там, які наразі не перевірені та не використовуються саме через цю проблему. Не зрозумійте мене неправильно, TCP & UDP були вражаюче добре розроблені, і дивно, як вони обидва змогли змінити масштаби до того, як ми сьогодні використовуємо Інтернет. Але хто знає, що ми пропустили? Я читав про SCTP, і це звучить добре, але ніколи його не використовував, оскільки це було непрактично через NAT.

Підключення однорангових

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

Це впливає на ігри, голосовий / відеочат (наприклад, Skype), розміщення власних серверів тощо.

Є обхідні шляхи. Проблема полягає в тому, що ці способи вирішення коштують або час розробника, час та незручності для кінцевого користувача, або вартість інфраструктури послуг. І вони не дурні і іноді ламаються. (Дивіться коментарі інших користувачів про перебої в роботі Skype.)

Одне вирішення - переадресація портів, де ви запрограмуєте пристрій NAT для пересилання певного вхідного порту на певний комп'ютер за пристроєм NAT. Існують цілі веб-сайти, присвячені тому, як це зробити для всіх NAT-пристроїв. Дивіться https://portforward.com/ . Зазвичай це коштує часу кінцевого користувача і розчарування.

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

(Пам'ятаєте, що я говорив про розгортання NAT замість IPv6, перенесення ваги проблеми з мережевих адміністраторів на кінцевих користувачів та розробників додатків?)

Послідовне іменування / розташування мережевих ресурсів

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

Якщо у вас є веб-сервер всередині NAT, скажімо, на порт 192.168.0.23 порт 80, а ваш пристрій NAT (маршрутизатор / шлюз) має зовнішню адресу 35.72.216.228, і ви налаштували переадресацію портів для порту TCP 80, тепер ваш Доступ до веб-сервера можна використовувати, використовуючи порт 192.168.0.23 80 АБО 35.72.216.228 порт 80. Той, який ви повинні використовувати, залежить від того, ви знаходитесь всередині або поза NAT. Якщо ви перебуваєте за межами NAT і використовуєте адресу 192.168.0.23, ви не потрапите туди, де вас очікують. Якщо ви перебуваєте всередині NAT, і ви використовуєте зовнішній адресу 35.72.216.228, ви могли б отримати , де ви хочете, якщо ваша реалізація NAT є передовою один , який підтримує шпильку, але тоді веб-сервер, який обслуговує ваш запит, побачить запит як з вашого NAT-пристрою. Це означає, що весь трафік повинен проходити через NAT-пристрій, навіть якщо за мережею NAT є коротший шлях в мережі, і це означає, що журнали на веб-сервері стають набагато менш корисними, оскільки всі вони перераховують пристрій NAT як джерело з'єднання. Якщо ваша реалізація NAT не підтримує шпильки, то ви не потрапите туди, де розраховували піти.

І ця проблема загострюється, як тільки ви використовуєте DNS. Раптом, якщо ви хочете, щоб усе працювало належним чином для чогось, що знаходиться за NAT, ви хочете дати різні відповіді на адресу служби, розміщеної всередині NAT, виходячи з того, хто запитує (AKA split horizon DNS, IIRC). Гидота.

І це все, припускаючи, що у вас є хтось обізнаний про переадресацію портів та шпильку NAT та розділений DNS горизонту. Що з кінцевими користувачами? Які шанси налагодити все це правильно, коли вони купують маршрутизатор споживача та якусь камеру безпеки IP і хочуть, щоб він "просто працював"?

І це призводить мене до:

Оптимальна маршрутизація трафіку, хости знають свою реальну адресу

Як ми бачили, навіть при просунутій шпильці NAT трафік не завжди проходить, хоча й оптимальний шлях. Це навіть у тому випадку, коли досвідчений адміністратор налаштовує сервер і має шпильку NAT. (Дозволений, розділений горизонт DNS може призвести до оптимальної маршрутизації внутрішнього трафіку в руках мережевого адміністратора.)

Що відбувається, коли розробник додатків створює таку програму, як Dropbox, і поширює її кінцевим користувачам, які не спеціалізуються на налаштуванні мережевого обладнання? Зокрема, що трапляється, коли я розміщую 4 Гб файл у своєму спільному файлі, а потім намагаюся отримати доступ до наступного комп’ютера? Чи він безпосередньо передається між машинами, чи мені доводиться чекати, коли він завантажиться на хмарний сервер через повільне WAN-з'єднання, а потім чекати вдруге для завантаження через той же повільний WAN-з'єднання?

Для наївної реалізації вона буде завантажена і потім завантажена, використовуючи серверну інфраструктуру Dropbox, яка не відстає від NAT в якості посередника. Але якби дві машини могли зрозуміти, що вони знаходяться в одній мережі, вони могли просто безпосередньо перенести файл набагато швидше. Отож, для нашої першої менш наївної спроби впровадження ми можемо запитати ОС, якими IP-адресами (v4) є машина, а потім перевірити, чи немає інших машин, зареєстрованих у цьому ж акаунті Dropbox. Якщо він знаходиться в тому ж діапазоні, що і ми, просто перенесіть файл безпосередньо. Це може спрацювати у багатьох випадках. Але навіть тоді виникає проблема: NAT працює лише тому, що ми можемо повторно використовувати адреси. Що робити, якщо адреса 192.168.0.23 та 192.168.0. 42 адреса, зареєстрована в одному обліковому записі Dropbox, насправді є в різних мережах (наприклад, у вашій домашній мережі та у вашій робочій мережі)? Тепер вам доведеться відмовитися від використання інфраструктури сервера Dropbox для посередництва. (Зрештою, Dropbox намагався вирішити проблему, передаючи кожному клієнту Dropbox трансляцію в локальній мережі в надії знайти інших клієнтів. Але ці трансляції не перетинають жодних маршрутизаторів, які у вас можуть бути за NAT, це означає, що це не повне рішення ,особливо у випадку CGN .)

Статичні IP-адреси

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

Затуплення джерела шкідливого трафіку

Оскільки NAT переписує вихідні з'єднання так, ніби вони надходять із самого NAT-пристрою, вся поведінка, добре чи погано, перекочується в одну зовнішню IP-адресу. Я не бачив жодного NAT-пристрою, який записує кожне вихідне з'єднання за замовчуванням. Це означає, що за замовчуванням джерело минулого шкідливого трафіку можна простежити лише на пристрої NAT, через який він пройшов. Хоча обладнання більше корпоративного чи операторського класу може бути налаштоване для реєстрації кожного вихідного з'єднання, я не бачив жодного споживача маршрутизаторів, які це роблять. Я, звичайно, думаю, що буде цікаво дізнатися, чи (і на який термін) провайдери будуть зберігати журнал усіх TCP та UDP-з'єднань, здійснених через CGN, під час їх розгортання. Такі записи знадобляться для розгляду скарг на зловживання та скарги на захист DMCA.

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

Протоколи, які використовують друге з'єднання

Такі протоколи, як FTP і SIP (VoIP), як правило, використовують окремі з'єднання для контролю та фактичного вмісту даних. Кожен протокол, який це робить, повинен мати програмне забезпечення, яке називається ALG (шлюз рівня додатків) на кожному пристрої NAT, через який він проходить, або вирішити проблему з допомогою якогось посередника або пробивання отворів. На моєму досвіді, КЗП рідко, якщо взагалі колись оновлюються, і були причиною хоча б пари питань, з якими я розглядався із залученням SIP. Кожного разу, коли я чую, щоб хтось повідомляв, що VoIP не працює для них, оскільки звук працював лише в один бік, я моментально підозрюю, що десь є NAT-шлюз, який скидає пакети UDP, і він не може зрозуміти, що з цим робити.

Підсумовуючи, NAT має тенденцію до порушення:

• альтернативні протоколи до TCP або UDP
• однорангові системи
• доступ до чогось, що знаходиться за NAT
• такі речі, як SIP та FTP. ALGs для вирішення цього питання все ще спричиняє випадкові та дивні проблеми, особливо з SIP.

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

Я підозрюю, що без NAT VoIP був би всюдисущим та інтегрованим з PSTN, і що дзвінки з мобільного телефону чи комп’ютера були б безкоштовними (за винятком Інтернету, за який ви вже платили). Зрештою, навіщо мені платити за телефон, коли ми з вами можемо просто відкрити потік 64K VoIP, і він працює так само добре, як і PSTN? Схоже, сьогодні проблема №1 з розгортанням VoIP проходить через NAT-пристрої.

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

Одним з великих симптом виснаження IPv4, про який я не бачив згаданих в інших відповідях, є те, що деякі постачальники мобільних послуг почали працювати лише з IPv6 кілька років тому. Є ймовірність, що ви використовуєте IPv6 роками і навіть не знали цього. Мобільні провайдери новіші для Інтернет-ігор, і не обов’язково мають величезні раніше існуючі IPv4 асигнування. Вони також потребують більшої кількості адрес, ніж кабельних / DSL / волокон, тому що ваш телефон не може ділитися загальнодоступною IP-адресою з іншими членами вашого домогосподарства.

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

У головних RIR деякий час тому не вистачало місця для звичайних виділень. Тому для більшості провайдерів єдиними джерелами адрес IPv4 є власні запаси та ринки.

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

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

Важко передбачити, скільки буде пропозиція та пропозиція в кожній ціновій точці, а отже, яка буде ринкова ціна в майбутньому. Поки що ціна за ІР, здається, залишилася напрочуд низькою.

В ідеалі кожен хост в Інтернеті повинен мати можливість отримати IP-адресу глобального масштабу, однак виснаження IPv4-адреси справжнє, у фактів ARIN вже не вистачає адреси у їхньому вільному пулі .

Причина, чому кожен все ще може отримати доступ до Інтернет-послуг просто чудово, це завдяки методам трансляції мережевих адрес (NAT), які дозволяють багатьом хостам ділитися відкритими IP-адресами. Однак це не проходить без проблем.

ISP використовується для видачі компаніям блоків з 256 IP-адрес. Тепер провайдери спокусливі і дають вам (компанії) на кшталт 5. Ще в той час (2003 р.) Кожен ПК та підключений пристрій у вашому домі мали власну IP-адресу в Інтернеті. Тепер кабельний / DSN / Fios маршрутизатор має одну IP-адресу і видає ip-адреси 10.0.0.x на всі ПК у вашому домі. Короткий зміст: Інтернет-провайдер раніше витрачав IP-адреси, і тепер їх більше не витрачає.

Ви вже отримали багато відмінних відповідей, але я хотів би додати щось, про що ще не було сказано.

Так, виснаження IPv4 адреси погано, залежно від того, як ви її вимірюєте. Деякі компанії все ще мають величезний запас IPv4-адрес, але ми починаємо бачити обхідні шляхи, такі як NAT-клас.

Але багато хто з відповідей помиляються, коли звертаються на IPv6.

Ось перелік технологій, які можуть допомогти впоратися з дефіцитом адреси IPv4. У кожного є свої переваги та недоліки.

• IPv6

  • Перевага: стандартизована та доступна в більшості операційних систем.
  • Недолік: незважаючи на часті твердження протилежного, серйозні проблеми із безпекою. Ще в 2005 році американський CERT попереджав про проблеми безпеки, спричинені глобальним зверненням IPv6. IPv6 можна захистити належним чином, але, враховуючи стан споживачів маршрутизаторів, це може не статися.
  • Недолік: міграція вимагає часу, грошей та досвіду.
  • Недолік: багато пристроїв високого рівня споживачів серйозно помиляються. Наприклад, ряд маршрутизаторів D-Link підтримують IPv6, просто пересилаючи весь трафік, не пропонуючи жодного брандмауера.

Ще одне врахування: навіть якщо IPv6 повністю натрапив сьогодні, все одно знадобиться ще 20 років або близько того, щоб припинити використання IPv4, завдяки застарілому обладнання, яке люди будуть використовувати дуже довго (я все ще бачу сервери Windows 2003 та робочі станції Windows XP періодично! Не кажучи вже про всі принтери та камери та гаджети IoT, які не підтримують IPv6).

• CGNat:
  • Перевага: працює без змін у приміщенні замовника.
  • Відношення: підтримує лише вихідні з'єднання.
  • Відношення: може не підтримувати декілька протоколів.

Зрештою, CGNat буде недостатньо. Можливо, IPv6 піде на озброєння, але також цілком можливо, що ми побачимо NAT-клас для країни або щось подібне.

В даний час, як консультант, мені часто доводиться вказувати своїм клієнтам, що вони потрапляють на IPv6 (часто завдяки Teredo). Наступним питанням незмінно буде: "скільки коштує це виправити?" а потім "Скільки коштує його блокувати? Що ми втрачаємо, якщо вимкнути його?" Вгадайте, яке рішення буде кожен раз.

Підсумок: щоб відповісти на ваше запитання, так, виснаження IPv4 справжнє. І ми побачимо досить багато механізмів впоратися з цим. IPv6 може бути, а може і не закінчуватися рівнянням.

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

NAT - це те, що сталося, коли IPv6 була ідеєю, до того, як це було реальністю, і розподіл IP-адрес став справжньою проблемою (хто пам'ятає, коли вони роздавали класу C в основному для запиту?), А реальний світ тим часом потребував рішення. .

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

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

Нижче наводиться результат дослідження, до якого ми випадково ризикнули. Він використовує не що інше, як оригінальний протокол IPv4 RFC791 та давно зарезервований, але майже не використовуваний адресний блок 240/4 для розширення пулу IPv4 в 256 М разів. Ми подали проект IZF під назвою EzIP (фонетичний для Easy IPv4):

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

В основному, підхід EzIP не тільки вирішить проблеми з нестачею адреси IPv4, але й значною мірою пом'якшить першопричину вразливості кібербезпеки, а також відкриє нові можливості для Інтернету, все в межах домену IPv4. Насправді ця схема може бути застосована "похито" для окремих регіонів, де це необхідно. Це повинно полегшити терміни розгортання IPv6 протягом значного періоду часу та визнати недійсним ринок торгівлі адресами IPv4.

Будь-яка думка чи коментар буде дуже вдячна.

Abe (2018-07-15 17:29)

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

Особисто мені добре з NAT. Це, як правило, додатковий рівень захисту. Принаймні їм або доведеться пройти додатковий пристрій, або знайти спосіб непрямого викрадення мого зв'язку. Що стосується запущених серверів, це, як правило, поза межами та / або вважається порушенням договору з провайдером, якщо ви не оплачуєте його. Впевнені, що ти зможеш це зробити, і вони, ймовірно, не зроблять тебе з цього приводу, але вони могли.

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

Ніхто насправді не потребує електронної пошти, і надіслати щось на Drop-box або Google Drive, або мільйон інших подібних сервісів, це не зовсім ракетна наука, ані повільна. Я маю на увазі все синхронізується. Ви кидаєте його в папку. Якщо ви не дурний, як я, і все робите через ssh / sftp (гаразд не все ). І якщо у вас є якісь причини, що ви дійсно хочете запустити свій власний сервер, хмарний хостинг дешевий - у мене є виділений віртуальний сервер, який працює на Linux на ssd. Пропускна здатність швидко божевільна. Він завантажується швидше, ніж я можу набрати стрілку вгору та натиснути Enter. І це масштабується. Ціла установка коштує від 5 до 10 баксів на місяць, без резервного резервного копіювання та без рахунків за електроенергію.

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

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

Дійсно, я не думаю, що насправді бажано, щоб кожен пристрій мав власну адресу прямо там, що плаває в мережі. Якщо хтось захоче затуманити себе під час нападу на вас, це станеться незалежно. Але ти сидить качка, якщо просто сидиш там кульки під відкритим вітерцем. Ні, я візьму свій IPv4 і NAT в будь-який день. Але добре, що він є.

Anywa, засинаю зараз ... напевно, більше сказати, але я завітаю завтра, якщо я щось пропустив. Я впевнений, що є більше.