Проксі ўсё яшчэ на старым адрасе тунеля пасля перападключэння VPN?

Перазапуск кліента VPN даказвае толькі тое, што тунель вярнуўся. Ён нічога не кажа пра проксі, якому было загадана выходзіць праз яго. Squid, tinyproxy і большасць іншых форвардераў трымаюць лакальны адрас крыніцы, які яны вызначылі пры запуску, пакуль нешта не прымусіць іх перазагрузіцца. Калі перападключэнне выдае новы адрас тунеля, форвардер або правальвае кожнае зыходнае злучэнне, або пачынае выходзіць праз ваш звычайны маршрут.

Другая няўдача — небяспечная: тунель працуе, старонкі загружаюцца, і толькі адрас выхаду памылковы.

Пачніце са слухача, а не з тунеля

У гульні тры адрасы, і перападключэнне зрушвае толькі некаторыя з іх. Слухач — гэта тое, куды накіраваны ваш браўзер, звычайна 127.0.0.1 або адрас лакальнай сеткі, і яму ўсё роўна, што тунель змяніўся. Зыходная лакальная крыніца — гэта тое, што форвардер просіць ядро выкарыстаць пры наборы наступнага хопа, і яна прывязана да прылады тунеля. Публічны выхад — гэта тое, што запісвае вэб-сервер, і ён можа быць трансляваным адрасам праз некалькі хопаў.

Пошук публічнага 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

Калі перазагрузка правалілася, спыніце службу і выправіце фрагмент; проксі, які працуе са старым выхадам, горшы за кароткі перапынак. Калі перазагрузка ўдалася, але свежы запыт усё яшчэ выходзіць некуды нечакана, вярніцеся да праверкі маршрутызацыі замест чарговай праўкі адрасоў. Запішыце пакаленне тунеля, супраць якога вы правяралі, каб наступнаму перападключэнню было з чым канкрэтна параўнаць.