તમારા VPN ગેટવેને હજી પણ અદ્યતન સ્થાપિત કરવાનો માર્ગ જોઈએ

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

ગેટવે બંધ કરવો યોગ્ય છે. તેને એટલું ચુસ્ત બંધ કરવું કે પેચ લેવાનું બંધ કરે, તે બીજો નિર્ણય છે, અને સામાન્ય રીતે અજાણતાં લેવાયેલો.

સ્થાનિક આઉટપુટ ક્લાયન્ટ ફોરવર્ડિંગ નથી

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

તે પરીક્ષણોમાંથી બચી જતી નીતિગત ખાલી જગ્યા પણ સમજાવે છે, કારણ કે ટનલ પાછળના લેપટોપથી ઝડપી તપાસ સાબિત કરે છે કે ફોરવર્ડિંગ સાંકળ કામ કરે છે અને યજમાનના પોતાના કનેક્શન વિશે કંઈ કહેતી નથી. ગેટવેને બે વિષયો તરીકે જુઓ: ફોરવર્ડિંગ સાંકળવાળું રાઉટર અને આઉટપુટ સાંકળવાળું યજમાન. બંનેને એક મતની જરૂર છે, અને સામાન્ય રીતે ફક્ત એક જ લખાય છે.

નિષ્ફળ થયેલા તબક્કાનું નામ આપો

અદ્યતન ભૂલો જુદી જુદી સીમાઓનાં નામ આપે છે, અને કઈ નિષ્ફળ થઈ તે વાંચ્યા પહેલાં પોર્ટ નિયમ પર ઝંપલાવવું બપોર બગાડે છે. ન ઉકેલાતું રિપોઝિટરી નામ resolver નો પ્રશ્ન છે, પરિવહનનો પ્રશ્ન નથી.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

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

નિયમ ઉમેરતા પહેલાં સ્રોત યાદી વાંચો

યાદ રહેલા સ્રોતોને બદલે વાસ્તવિક સ્રોત URI અને અસરકારક પ્રોક્સી ગોઠવણીની યાદી બનાવો. સાદા HTTP માટે લખાયેલો નિયમ ત્યારે નકામો છે જ્યારે સ્રોત HTTPS હોય, અને શેલને જાણતી પ્રોક્સી બૂટ વખતે બીજા વાતાવરણ સાથે શરૂ થતી સેવા માટે અદૃશ્ય હોઈ શકે છે.

APT માં HTTP પરિવહનનું દસ્તાવેજીકરણ પર્યાવરણીય અને APT-વિશિષ્ટ પ્રોક્સી સેટિંગ્સ આવરી લે છે, જેમાં દરેક યજમાન માટેની પસંદગીઓનો સમાવેશ થાય છે, અને તેના HTTPS પરિવહનની પોતાની ચકાસણી સેટિંગ્સ છે. બ્રાઉઝરનો માર્ગ અને પેકેજ મેનેજરનો માર્ગ અલગ માર્ગો છે, એક જ મશીન પર પણ.

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

જાળવણીનો એક માર્ગ પસંદ કરો અને તેના પર ટકી રહો

ત્રણ બચાવપાત્ર વિકલ્પો છે: જાળવણી ટ્રાફિક ટનલ દ્વારા, સંચાલિત અદ્યતન પ્રોક્સી દ્વારા, અથવા સાંકડા સીધા અપવાદ દ્વારા. એક જાણી જોઈને પસંદ કરો અને resolver ને તેની સાથે સહમત કરો, કારણ કે એવું વિભાજન જેમાં નામ એક દિશામાં ઉકેલાય અને કનેક્શન બીજી દિશામાં જાય તે એવી નિષ્ફળતાઓ ઊભી કરે છે જે કોઈ સમજાવી શકતું નથી.

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

તપાસ નબળી ન કરતાં ચકાસો

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

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

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