Пристигат тикети в поддръжката, в които се казва, че приложението показва един адрес, а сървърът е записал друг, и след това питат кой от двата лъже. Никой не лъже; това са две наблюдения на две различни неща. Адрес, вързан към интерфейс, адрес, вързан към сокет, и адрес на източник, който вижда отдалечена услуга, отговарят на три отделни въпроса. VPN добавя мрежов контекст към телефона и не свива тези три в едно число за цялото устройство. Прочетете имената на полетата в тикета, преди да четете адресите.

Какво обикновено описва тикетът

Представете си телефон на Wi-Fi с вдигнат тунел. Wi-Fi интерфейсът държи LAN адрес, тунелният интерфейс държи зададен вътрешен адрес, а заявка, която излиза през тунела, пристига в публична услуга от какъвто и източник да оцелее след евентуално преобразуване по пътя. Приложение, което печата вътрешния адрес, и сървър, който записва преобразувания източник, и двете докладват точно, и двете стойности никога няма да съвпаднат.

Трите наблюдения се различават по това какво могат да докажат, а не само по това какво описват.

ObservationWhat it describesWhat it cannot prove
An address on a local interfaceOne configured attachment: Wi-Fi, cellular or a tunnelThe source a remote site receives
A socket's local endpointThe binding used by that one connectionThe address after translation further along
The peer address at a serviceWhat arrived at that observation pointAny other interface on the phone

Дръжте тази таблица до кода, който попълва тези стойности в тикет, защото повечето объркване тук е объркване на колони, а не мрежова повреда.

На какво може и на какво не може да отговори извикване на сокет

На ниво API getsockname отчита локалната крайна точка, която понастоящем е вързана към конкретен сокет. За свързан сокет това е източникът, който ядрото е избрало за тази връзка, което вече е по-конкретно от всеки списък на интерфейси. Това не е търсене на публичен адрес и извикването му върху несвързан сокет не ви казва почти нищо. Каквото и да върне, то може да бъде пренаписано по-късно по пътя, така че само собственото наблюдение на услугата е меродавно за това какво е получила услугата.

На платформите на Apple страната на интерфейсите има отделна повърхност: настройките на тунела изброяват адресите, зададени на тунелния интерфейс. Четенето им казва как е конфигуриран тунелът и не казва кой път е поела дадена заявка, защото маршрутизацията и правилата за отделните приложения решават това за всяка връзка.

Разделеният тунел прави разликата видима. Една заявка може да излезе през тунела, а следващата, насочена към друга дестинация или семейство адреси, да не излезе, така че два резултата от едно и също приложение секунди един след друг могат да бъдат честни и различни.

Изберете наблюдението, което отговаря на въпроса

Избирайте съзнателно, вместо да инструментирате всичко. За това какво вижда бекендът, записвайте източника в бекенда, а когато отпред стои обратен прокси, четете адреса на клиента от заглавката за препращане, която вашето внедряване действително задава, а не от нещо, изпратено от клиента.

За да разберете дали тунелът е конфигуриран, четете интерфейса. За да разберете дали трафикът на това приложение го е използвал, изпратете трафик от това приложение към дестинация, която контролирате, и сравнете източника в двата края.

Правилата за отделни приложения заслужават собствено изречение. Резултатът от браузър е доказателство за този браузър, а управляван тунел за отделни приложения може да постави две приложения на един и същ телефон по различни пътища в един и същ момент. Проверката на покритието означава изпращане на трафик от въпросното приложение, в въпросното семейство адреси.

Имената на интерфейсите не са детектор

Не използвайте име на интерфейс и като проверка за VPN. Имената не са публичен договор и телефонът може да има няколко прикачвания, докато само едно от тях носи вашата заявка.

Назовавайте полето по наблюдението, което държи. local_interface_address, socket_local_endpoint и service_observed_source са тромави и еднозначни, а еднозначността е това, което искате, когато стойността попадне в тикет за поддръжка седмица по-късно. Една колона с име device IP ще събере и трите и после ще ѝ се вярва като на едно.

Дръжте идентичността извън колоната за адрес

Споделен изход на VPN не е идентичност на потребител, а частен адрес не е идентификационни данни за достъп. И двете описват път, а не човек, и третирането на което и да е от тях като удостоверяване превръща маршрутна случайност в решение за оторизация.

Когато някой попита какъв адрес има телефонът, полезният отговор е въпрос за това коя връзка и кой наблюдател. Определението на getsockname си заслужава да бъде цитирано за средния случай, защото решава въпроса със сокета, без да се преструва, че решава другите два.

След това запишете кое от трите вашият продукт действително трябва да показва, и изтрийте другите две от интерфейса.

Подобни статии