Да ли је прокси још на старој адреси тунела после поновног повезивања VPN-а?

Поновно повезивање може да остави ваш прослеђивач везан за адресу коју тунел више не поседује. Четири уређене провере, нумерисана предаја и прави тестни захтев.

Поновно покретање VPN клијента доказује само да се тунел вратио. О томе не говори ништа о проксију коме је речено да излази кроз њега. Squid, tinyproxy и већина осталих прослеђивача држе локалну изворну адресу коју су одредили при покретању док их нешто не присили на поновно учитавање. Када поновно повезивање додели нову адресу тунела, прослеђивач или пада на свакој одлазној вези, или почиње да излази кроз вашу уобичајену руту.

Тај други квар је опасан: тунел ради, странице се учитавају, а само је излазна адреса погрешна.

Почните од слушаоца, не од тунела

У игри су три адресе, а поновно повезивање помера само неке од њих. Слушалац је место на које показује ваш прегледач, обично 127.0.0.1 или LAN адреса, и њега не занима што се тунел променио. Одлазни локални извор је оно што прослеђивач тражи од језгра кад бира следећи хоп, и он је везан за уређај тунела. Јавни излаз је оно што бележи веб сервер, а то може бити преведена адреса неколико хопова даље.

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

Контејнерски и именски распореди тихо руше ту претпоставку. Прослеђивач у једном мрежном именском простору не може да се веже за тунел који постоји у другом, и никакво уређивање конфигурације то не поправља.

Четири провере пре него што било шта уредите

Прођите кроз њих редом. Прва провера која падне место је на којем се заустављате, јер касније претпостављају да раније важе.

  1. Потврдите да је тунел у употреби профил око којег је прокси изграђен, а не други профил који се сам повезао.
  2. Испишите адресу која је тренутно на том уређају и упоредите је с адресом у конфигурацији која ради.
  3. Питајте прослеђивач који је извор одредио, а не шта тврди датотека на диску.
  4. Потврдите да саобраћај с прослеђивача заиста подлеже политици усмеравања и заштитног зида коју очекујете.

Адреса уређаја је лака: ip -4 addr show dev tun0 исписује тренутну, а ip -4 route get 1.1.1.1 показује које би сучеље језгро одабрало за то одредиште. Прослеђивач који везује тачну адресу гласно пада кад адреса нестане. Прослеђивач који везује уређај или се враћа на подразумевани извор наставља да ради и цури, а то је тихи исход.

Ускладите документацију с издањем које покрећете, а не с првим резултатом претраге. Squid директива одлазне адресе документована је за v7 и раније, а документација v8 изричито каже да директива тамо није доступна, па скрипта изграђена око ње не преживљава ту границу (погледајте референцу Squid tcp_outgoing_address). Проверите сопственим парсером производа пре него што се било шта поново учита: squid -k parse пријављује грешке и излази не дирајући процес који ради.

Нумеришите сваки тунел и одбаците застареле замене

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

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

Отворени сокети неће следити нову адресу

Реконфигурисање прослеђивача не говори ништа о везама које су већ успостављене. Да ли ће се исцедити или умрети зависи од производа, па посматрајте понашање уместо да га претпостављате.

Захтев услужен преко сокета отвореног пре замене и даље излази старим путем, чак и кад је нова конфигурација исправна. Ако је то важно, одлучите изричито: дозволите кратак прозор цеђења и престаните да примате нови посао, или затворите старе сокете и прихватите грешке. Затим тестирајте свежом везом и држите тај резултат одвојено од провере цеђења. Везивање за извор такође није безбедносна граница. Кад саобраћај никада не сме да дотакне уобичајену руту, наметните то ознакама и правилима заштитног зида, укључујући DNS и IPv6, тако да неуспело учитавање остави прокси изричито искључен, а не отворен.

Докажите нови излаз свежим захтевом

Важан је захтев отворен после активације, а не ping и не већ кеширана страница. Затражите од проксија прави URL и прочитајте излазну адресу коју пријављује друга страна, па је упоредите с властитим виђењем тунела код клијента кад га добављач изложи.

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Ако поновно учитавање падне, зауставите сервис и поправите фрагмент; прокси који служи са застарелим излазом гори је од кратког прекида. Ако поновно учитавање успе али свежи захтев и даље излази негде неочекивано, вратите се провери усмеравања уместо да поново уређујете адресе. Забележите генерацију тунела према којој сте проверавали, да следеће поновно повезивање има нешто конкретно за поређење.

Повезани чланци