Nasa lumang address pa rin ba ng tunnel ang proxy pagkatapos muling kumonekta ang VPN?

Ang muling pagpapatakbo ng VPN client ay nagpapatunay lamang na bumalik ang tunnel. Wala itong sinasabi tungkol sa proxy na inutusang lumabas sa pamamagitan nito. Ang Squid, tinyproxy at karamihan ng iba pang forwarder ay hinahawakan ang lokal na source address na nahanap nila noong pagsisimula hanggang may pumilit sa kanilang mag-load muli. Kapag ang muling pagkonekta ay nagbigay ng bagong address ng tunnel, ang forwarder ay nabibigo sa bawat palabas na koneksyon, o nagsisimulang lumabas sa iyong karaniwang ruta.

Ang pangalawang pagkabigo ang mapanganib: buhay ang tunnel, naglo-load ang mga pahina, at ang address ng labasan lang ang mali.

Magsimula sa listener, hindi sa tunnel

Tatlong address ang nasa laro, at ang muling pagkonekta ay gumagalaw lamang ng ilan sa kanila. Ang listener ay kung saan nakaturo ang browser mo, karaniwang 127.0.0.1 o isang address ng LAN, at wala itong pakialam na nagbago ang tunnel. Ang palabas na lokal na source ay ang hinihiling ng forwarder sa kernel na gamitin kapag nag-dial ng susunod na hop, at ito ay nakatali sa device ng tunnel. Ang pampublikong labasan ay ang itinatala ng web server, at maaaring isang isinalin na address na ilang hop ang layo.

Ang paghahanap ng pampublikong IP ay sumasagot lamang sa huling tanong. Hindi nito masasabi kung aling lokal na address ang dapat italì ng forwarder, dahil ang isang pampublikong labasan ay maaaring magtago ng ilang panloob na source. Basahin ang address mula sa may-ari ng koneksyon: ang output ng status ng client, ang interface mismo, o ang namespace kung saan nakatira ang tunnel. Ang pagkuha ng unang interface na mukhang tunnel ang pangalan ay nagbibigay ng maling sagot sa sandaling may pangalawang profile.

Ang mga layout ng container at namespace ay tahimik na sumisira sa palagay na ito. Ang forwarder sa isang network namespace ay hindi makakatalì sa tunnel na nasa iba, at walang dami ng pag-edit ng configuration ang makakagawa nito.

Apat na pagsusuri bago ka mag-edit ng kahit ano

Sundin ang mga ito nang sunod-sunod. Ang unang pagsusuring nabigo ang lugar kung saan ka hihinto, dahil ipinapalagay ng mga susunod na tama ang mga nauna.

1. Tiyakin na ang ginagamit na tunnel ay ang profile kung saan itinayo ang proxy, hindi isang pangalawang profile na kusang kumonekta.
2. I-print ang address na kasalukuyang nasa device na iyon at ihambing sa address sa tumatakbong configuration.
3. Itanong sa forwarder kung aling source ang nahanap nito, hindi kung ano ang sinasabi ng file sa disk.
4. Tiyakin na ang trapiko mula sa forwarder ay talagang nasa ilalim ng patakaran ng routing at firewall na inaasahan mo.

Ang address ng device ay madali: ip -4 addr show dev tun0 ay nagpi-print ng kasalukuyan, at ip -4 route get 1.1.1.1 ay nagpapakita kung aling interface ang pipiliin ng kernel para sa destinasyong iyon. Ang forwarder na nagtatalì ng eksaktong address ay nabibigo nang malakas kapag nawala ang address. Ang forwarder na nagtatalì ng device, o bumabalik sa default na source, ay patuloy na gumagana at tumutulo, at iyon ang tahimik na resulta.

Itugma ang dokumentasyon sa release na pinapatakbo mo, hindi sa nangungunang resulta ng paghahanap. Ang direktiba ng palabas na address ng Squid ay nakadokumento para sa v7 at mas maaga, at ang dokumentasyon ng v8 ay malinaw na nagsasabing hindi available ang direktiba doon, kaya ang script na itinayo sa paligid nito ay hindi lumalampas sa hangganang iyon (tingnan ang sanggunian ng Squid tcp_outgoing_address). Beripikahin gamit ang parser ng produkto mismo bago mag-load muli ng kahit ano: squid -k parse ay nag-uulat ng mga error at lumabas nang hindi hinahawakan ang tumatakbong proseso.

Bilangan ang bawat tunnel at itapon ang mga lumang palitan

Ang muling pagkonekta ay isang paglilipat, at ang paglilipat ay nangangailangan ng pagkakasunod-sunod. Lagyan ng tag ang bawat naobserbahang koneksyon ng counter o timestamp na tumataas sa bawat matagumpay na pagtatatag, pagkatapos ay dalhin ang tag na iyon sa loob ng kandidatong configuration. Kapag ang tag sa isang kandidato ay mas luma kaysa sa kasalukuyan, itapon ang kandidato sa halip na ilapat ito, dahil ang mabagal na update na isinulat para sa dating tunnel ay sasapawan ang mga setting ng kasalukuyan. Pagsamahin ang mga pagsabog ng pangyayari upang ang nanginginig na link ay magbigay ng isang paglipat sa halip na labinlima.

Ayusin ang trabaho sa apat na galaw: pawalang-bisa ang lumang estado ng labasan, hintayin ang may-ari ng koneksyon na iulat ang pagkumpleto, buuin lamang ang pinamamahalaang piraso, pagkatapos ay beripikahin at i-activate sa pamamagitan ng service manager. Ang muling pagbuo ng buong file mula sa dalawang halaga ng address ay ang paraan kung paano tahimik na nawawala ang mga paghihigpit ng listener, authentication at patakaran ng destinasyon. Igalang din ang sinadyang paghinto. Ang katulong na patuloy na nag-dial ng tunnel na pinatay ng user ay isang bug, hindi katatagan.

Hindi susunod ang mga bukas na socket sa bagong address

Ang muling pag-configure ng forwarder ay walang sinasabi tungkol sa mga koneksyong naitatag na. Kung maubos o mamatay ang mga ito ay depende sa produkto, kaya obserbahan ang pag-uugali sa halip na ipagpalagay ito.

Ang kahilingang inihain sa isang socket na binuksan bago ang palitan ay lumalabas pa rin sa lumang landas, kahit tama ang bagong configuration. Kung mahalaga iyon, magpasya nang malinaw: payagan ang maikling window ng pag-ubos at itigil ang pagtanggap ng bagong trabaho, o tapusin ang lumang socket at tanggapin ang mga error. Pagkatapos ay subukan gamit ang bagong koneksyon at panatilihing hiwalay ang resultang iyon sa pagsusuri ng pag-ubos. Ang pagtatalì sa source ay hindi rin hangganan ng seguridad. Kapag ang trapiko ay hindi dapat kailanman humawak sa karaniwang ruta, ipatupad ito gamit ang mga marka at patakaran ng firewall, kasama ang DNS at IPv6, upang ang nabigong pag-load muli ay mag-iwan sa proxy na malinaw na patay sa halip na bukas.

Patunayan ang bagong labasan gamit ang bagong kahilingan

Ang mahalaga ay kahilingang binuksan pagkatapos ng activation, hindi ping at hindi page na nasa cache na. Hilingin sa proxy ang totoong URL at basahin ang address ng labasan na iniulat ng malayong dulo, pagkatapos ay ihambing sa sariling pananaw ng client sa tunnel kapag may ipinakita ang provider.

Panatilihing magkahiwalay na utos ang pag-parse, pag-load muli at kahilingan upang ang pagkabigo ay tumuro sa isang hakbang. Ang unang dalawa ay walang binabago kapag nabigo, at iyon mismo ang dahilan kung bakit tumatakbo sila bago ang restart.

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

Kung nabigo ang pag-load muli, ihinto ang serbisyo at ayusin ang piraso; ang proxy na naglilingkod nang may lumang labasan ay mas masahol kaysa sa maikling pagtigil. Kung nagtagumpay ang pag-load muli ngunit ang bagong kahilingan ay lumalabas pa rin sa isang lugar na hindi inaasahan, bumalik sa pagsusuri ng routing sa halip na i-edit muli ang mga address. Itala ang henerasyon ng tunnel na sinuri mo, upang ang susunod na muling pagkonekta ay may konkretong ihahambing.