Прокси сървърът все още е на стария адрес на тунела след повторно свързване на 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

Ако презареждането се провали, спрете услугата и поправете фрагмента; прокси, което обслужва със стар изход, е по-лошо от кратко прекъсване. Ако презареждането успее, но свежата заявка все още излиза някъде неочаквано, върнете се към проверката на маршрутизирането, вместо да редактирате адреси отново. Запишете поколението на тунела, срещу което сте проверявали, така че следващото повторно свързване да има нещо конкретно за сравнение.

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