Проброс портів на точці доступу Android: три точки входу

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

Почніть там, де служба справді працює

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

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

У збірці з налагодженням adb shell може перелічити сокети через /proc/net/tcp, але для більшості людей чесним джерелом є статус самого застосунку. Це також позбавляє від пастки перевіряти сокет, який застосунок відкрив на несподіваній для вас адресі.

Перша точка входу: інший пристрій у точці доступу

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

Ламають це дві речі. Застосунок прив'язаний до loopback, або клієнтська політика на телефоні не дозволяє локальне з'єднання. Якщо застосунок виконує автентифікацію, перевіряйте протоколом самого застосунку, а не голим TCP-з'єднанням, бо слухач, який приймає, а потім відхиляє, здалеку виглядає так само, як закритий порт.

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

Друга точка входу: шлях оператора

Дістатися до телефона з мобільної мережі — інша задача, і найчастіше для IPv4 вона просто не працює. Оператори тримають апарати за спільним перетворенням, тому RFC 6598 і виділив спільний діапазон адрес саме для такої схеми. У небажаного вхідного з'єднання немає перетворення, через яке можна прийти, і жодне локальне налаштування його не створює, адже перетворювач — не ваш пристрій.

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

Третя точка входу: вихід VPN

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

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

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

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

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

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

• Слухаючий сокет розташований на адресі, доступній потрібному партнеру, а не на loopback.
• Партнер використовує адресу, що належить цій точці входу, а не адресу виходу зі сторінки стану.
• Будь-яке перетворення на боці оператора чи провайдера — підтримувана функція, а не додане вами локальне правило.
• Запит і відповідь ідуть через один і той самий мережевий контекст, і автентифікація застосунку все ще проходить.