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

જો ફરી-લોડ નિષ્ફળ જાય, તો સેવા બંધ કરો અને ટુકડો સુધારો; જૂના આઉટગોઇંગ સાથે સેવા આપતું પ્રોક્સી ટૂંકા વિક્ષેપ કરતાં ખરાબ છે. જો ફરી-લોડ સફળ થાય પણ તાજી વિનંતી હજી અણધાર્યા સ્થળેથી બહાર જાય, તો ફરી સરનામાં સંપાદિત કરવાને બદલે રૂટિંગ તપાસ પર પાછા ફરો. તમે જે ટનલ પેઢી સામે ચકાસણી કરી તે નોંધો, જેથી આગલી ફરી-કનેક્શન પાસે સરખાવવા માટે કંઈક ઠોસ હોય.