Како забележити и проверити коришћену излазну адресу VPN-а

Питајте стони VPN клијент које сте сервере користили и искрен одговор је обично назив локације. Тај назив је улазна тачка коју сте изабрали, а адреса са које је отишао ваш саобраћај може бити сасвим други рачунар. Ништа у апликацији није осмишљено да задржи други број, па запис мора настати у тренутку употребе. Постоје два приступа и само један од њих преживи сусрет са предметом подршке.

Два записа, а само један од њих постоји

Поглед самог клијента је у најбољем случају списак изабраних локација са временским ознакама. То је одлука о дизајну, а не пропуст: адресе су оперативни детаљ, ротирају између додела, а откривање пресликавања отежава и подршку и обраду злоупотребе. Добављачи стављају инстанце у облаку испред својих мрежа управо зато да крајња тачка може да се премести без да икоме кажу. Оно што вам апликација показује јесте ваш избор, а не пут којим је саобраћај прошао.

Запис који можете да изградите јесте локална датотека са једном јавном адресом и једном временском ознаком UTC по реду. Мањи је, ружнији и много кориснији, јер описује тачно оно што и спољни посматрач може да види.

Опција А: сами забележите излазну адресу

Услуга одјека враћа изворну адресу са које је захтев стигао, а то је по дефиницији излазна адреса. Покрените снимање након што тунел јави да је повезан, јер ће клијент који каже повезано пре него што се утврде руте и DNS забележити адресу пре тунела и затровати дневник већ од првог реда.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Два детаља чине тај одломак корисним, а не украсним. Временска ознака и адреса деле један ред, па каснија обрада не мора да спарује записе, а umask 077 чува датотеку приватном од тренутка настанка. Покрећите га једном по вези, а не једном по покретању, и држите једну датотеку по уређају.

Дневник бележи када сте користили тунел и из које сте се мреже појавили, што је ближе историји прегледања него бројачу. Изаберите период чувања који можете да браните, држите датотеку изван заједничких фасцикли за синхронизацију и бришите је намерно.

Опција Б: затражите историју од добављача

Неки добављачи воде дневнике веза и одговориће на питање подршке временском ознаком и називом сервера. Тај запис описује њихову инфраструктуру, а не ваш саобраћај, и вреди само онолико колико вреде њихов прозор чувања и њихова воља да погледају. Описује и сесију, а не захтев. Прозор је обично кратак и мери се са добављачеве стране тунела.

Добављачи који оглашавају да не воде дневнике не могу то да припреме на захтев, а списак недавних локација на страни клијента није исто. Тражење излазне адресе од добављача без дневника обично се заврши објашњењем зашто ти подаци не постоје.

Шта сваки запис може да докаже у предмету подршке

Два записа одговарају на различита питања и управо у табели поређење престаје да буде академско.

Само је прва колона под вашом контролом. Добављачев запис може да потврди да је налог био повезан у одређено време, али не може да потврди који су захтеви користили тунел и неће навести адресу коју добављач третира као оперативни детаљ. Ниједан запис не идентификује особу, јер заједничка излазна адреса може у истом минуту да носи много корисника.

Упоредите оба са референцом пре него што поверујете било коме

Адреса сама по себи не доказује ништа. Снимите директну адресу пре повезивања, тунелирану после и упоредите их. Идентичне вредности значе да тунел не преноси тај захтев, било због подељеног тунела, надређеног проксија или клијента који се вратио на директан пут.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Поновите поређење за DNS и за IPv6, јер одјек адресе доказује пут једног HTTP захтева и ништа о томе који је резолвер одговорио. Уређај који пропушта на једном може на другом да изгледа сасвим здраво.