Два пристрої, один Wi-Fi, різні виходи VPN: що це вирішує

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

Три адреси, і лише одна з них виходить

У ноутбука є адреса в домашній мережі LAN, яка ідентифікує його в локальному сегменті, і може бути адреса тунелю, видана всередині VPN. Жодна з них не видима віддаленому сервісу. Цей сервіс фіксує публічну адресу виходу того пристрою, який зрештою надсилає пакет, після будь-яких перетворень у дорозі.

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

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

Що робить два виходи справді різними

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

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

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

Чому окремі профілі — не окремі виходи

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

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

Єдина надійна відповідь приходить із запиту, зробленого через ту схему, яку ви збираєтеся використовувати. Усе інше — здогад.

Де розмістити розділення

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

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

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

Перевірте вихід, який ви реально отримали

Робіть перевірку з того застосунку, який важливий, і порівнюйте ту саму родину адрес на обох пристроях. Результат IPv4 з одного й результат IPv6 з іншого не доводять нічого ні про один. Потім повторіть перевірку після перепідключення, бо призначення з пулу може змінитися між сесіями.

Запускайте це з термінала всередині політики тунелю, а не з пристрою, який її обходить. Неправильний хост дає впевнену неправильну відповідь.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

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