DS-Lite блокує вхідний хостинг IPv4, а не вихідний VPN
Стан трансляції йде за стороною, яка починає з’єднання. Простежте вихідний запит через B4 і AFTR, а потім подивіться, чому хостинг не працює.
DS-Lite — це спосіб дати клієнтові з’єднання IPv4 через мережу доступу, яка передає лише IPv6. Домашній маршрутизатор не має власної виділеної публічної адреси IPv4, і цей єдиний факт переконує людей, що IPv4 VPN не може працювати з такого з’єднання. У вихідному напрямку він зазвичай працює добре. З’єднання транслює провайдер, і далека сторона бачить звичайного клієнта IPv4. Ламається зворотний напрямок: хостинг того, що очікує незапитаний вхідний IPv4. Різниця в тому, яка сторона починає розмову.
Яка сторона починає з’єднання
Клієнт, який ініціює з’єднання, створює стан трансляції по ходу. Транслятор провайдера бачить перший пакет, виділяє зіставлення і пересилає його. Зворотний трафік відповідає цьому зіставленню, бо зіставлення вже існує.
Сервер, який чекає з’єднань, не має такого стану для створення. Хтось ззовні має досягти адреси й порту, які провайдер не погодився зіставляти, і це зовсім інший запит.
Простежте вихідний запит
Архітектура в RFC 6333 називає обидва кінці. Елемент на боці клієнта — це B4, який інкапсулює IPv4 в IPv6. Елемент на боці провайдера — це AFTR, який виконує трансляцію адреси й пересилає пакет як IPv4.
Client's IPv4 VPN packet
→ Customer B4
→ IPv4 carried over the provider's IPv6 network
→ AFTR address translation
→ IPv4 VPN server
VPN-сервер отримує звичайне з’єднання IPv4 з трансльованої адреси провайдера. Йому не потрібен режим DS-Lite, спеціальний порт або знання того, що мережа доступу клієнта — лише IPv6. Саме це люди пропускають: далека сторона не може цього визначити.
Власна конфігурація клієнта така сама звичайна. Їй потрібен робочий шлях IPv4 до сервера, який забезпечують B4 і AFTR, і потрібно, щоб ім’я хоста сервера розв’язувалося в адресу IPv4.
Чому вхідний хостинг — це той випадок, який не працює
Запуск сервера VPN на IPv4 удома — це рішення, що стикається зі спільною адресацією провайдера. Транслятор провайдера володіє публічною адресою й таблицею зіставлень і не має причин створювати постійне вхідне зіставлення для одного абонента.
Правило переадресації порту на домашньому маршрутизаторі не може налаштувати AFTR. Правило є реальним і правильним на локальному пристрої, і воно нічого не змінює вище за течією, тому симптом виглядає як проблема з брандмауером, яка не минає.
Тут трансляція операторського рівня також відрізняється від однієї публічної адреси: навіть правильна локальна переадресація може потрапити на адресу, яку поділяють багато абонентів.
Діагностуйте, перш ніж змінювати план доступу
Спершу підтвердьте наданий режим. Власний подвійний стек, DS-Lite і мережа лише з IPv6, що використовує інший механізм трансляції, — це три різні схеми, і маркетингові назви провайдера не завжди збігаються з технічною.
Далі встановіть чотири спостереження для вихідного збою. Чи розв’язує клієнт ім’я хоста VPN в адресу призначення IPv4? Чи працює просте з’єднання IPv4, а не запит браузера, який міг тихо використати IPv6? Який транспорт і порт пробує клієнт, і чи бачать журнали кінцевої точки цю спробу взагалі? Чи стається збій під час початкового обміну, після періоду простою або лише на великих передачах?
Ці чотири відповіді вказують на фільтрування, вичерпання стану трансляції, неправильну кінцеву точку або обробку розміру пакета. Жодне з них не встановлюється тим, що на сторінці облікового запису видно DS-Lite.
Уважно читайте зміни провайдера
Зміна облікового запису може збігтися з робочим з’єднанням, змінивши кілька властивостей одразу. Запишіть, яка властивість змінилася, бо нова назва пакета — не технічне пояснення.
Вказівка ввімкнути подвійний стек неоднозначна, доки хтось не підтвердить, що провайдер справді надає. Якщо вважати її універсальною вимогою для клієнтів IPv4 VPN, припущення перетворюється на політику.
Якщо реальна вимога — вхідний хостинг IPv4, обговоріть із провайдером підтримувану вхідну схему, власну адресацію або інший проєкт доступу. Якщо вимога — ноутбук, що досягає віддаленого сервера, запитайте натомість саме про цей вихідний потік. Порядок роботи: назвіть напрямок, підтвердьте наданий режим, перевірте простий IPv4 і один транспорт, і змінюйте план доступу лише якщо напрямок справді цього потребує.