Дали проксито сѐ уште е на старата адреса на тунелот по повторно поврзување на 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

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

Поврзани статии