વેબસાઇટ્સ VPN દ્વારા લોડ થાય છે, પણ apt રિપોઝિટરી સુધી પહોંચતું નથી

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

કયો નિર્ણય નિષ્ફળ ગયો, એ પહેલાં નક્કી કરવા જેવી એકમાત્ર વાત છે.

સેટિંગને અડકતા પહેલાં ભૂલ વાંચો

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

કંઈપણ બદલતા પહેલાં તે ચોક્કસ લાઇન અને જે રિપોઝિટરીનું નામ તે લે છે તે કૉપિ કરો. „સમય પૂરો થઈ ગયો“ જેવી ઝાંખી યાદ જ દસ મિનિટની નિદાનને આખી બપોરમાં ફેરવે છે.

APT પોતાની અલગ પ્રોક્સી સેટિંગ્સ રાખે છે

APT /etc/apt/apt.conf.d/, મુખ્ય apt.conf અને APT_CONFIG દ્વારા નામ આપેલી દરેક ફાઇલ વાંચે છે. તે ડેસ્કટોપ પ્રોક્સી પ્રોફાઇલ, GNOME નેટવર્ક સેટિંગ કે બ્રાઉઝર એક્સ્ટેન્શન વાંચતું નથી. ટ્રાન્સપોર્ટ પ્રોક્સી પર્યાવરણ ચલોનું પાલન કરે છે, તેથી તમારા શેલમાં કામ કરતું export https_proxy=... બીજા પર્યાવરણમાં ચાલતા ટાઇમર વિશે કંઈ સાબિત કરતું નથી.

નિષ્ફળ થતી પ્રક્રિયા ખરેખર શું જુએ છે તે ડમ્પ કરો: apt-config dump | grep -i proxy.

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

પ્રોક્સી ત્યાં સેટ કરો જ્યાં રૂપરેખાંકનનો માલિક તેને અપેક્ષા રાખે છે

વ્યવસ્થાપક દ્વારા મંજૂર સ્પષ્ટ પ્રોક્સી માટે નવી ફાઇલમાં નાનો ટુકડો પૂરતો છે:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

ત્રીજી લાઇન એ ભાગ છે જે મોટાભાગના ઉદાહરણો છોડી દે છે. પ્રતિ-હોસ્ટ કી સામાન્ય મૂલ્યને બાજુ પર કરે છે, તેથી ટનલ દ્વારા પહોંચી શકાય તેવું આંતરિક મિરર પ્રોક્સી છોડી શકે છે જ્યારે બાકી બધું હજી તેમાંથી પસાર થાય છે. DIRECT એ માટે દસ્તાવેજીકૃત મૂલ્ય છે, ખાલી સ્ટ્રિંગ નહીં.

ટુકડાને નવી ક્રમાંકિત ફાઇલ તરીકે ઉમેરો, જેમ કે /etc/apt/apt.conf.d/95proxy. વિતરણની ફાઇલ ઓવરરાઇટ કરવાનો અર્થ એ છે કે આગલું પેકેજ અપડેટ તમારો ફેરફાર ચૂપચાપ પાછો ફેરવશે.

પ્રમાણપત્રો URIની બહાર રહે છે

APT ટ્રાન્સપોર્ટ સંદર્ભ પ્રમાણીકરણ માટે apt_auth.conf તરફ નિર્દેશ કરે છે, અને વપરાશકર્તાનામ તથા પાસવર્ડ ત્યાં જ જાય છે. તેમને પ્રોક્સી URIમાં એમ્બેડ કરવાથી તે પ્રક્રિયા યાદીઓ, શેલ ઇતિહાસ અને ટિકિટમાં ચોંટાડેલા દરેક રૂપરેખાંકન ડમ્પમાં પહોંચે છે. પ્રમાણીકરણ ફાઇલને કડક પરવાનગીઓ જોઈએ, કારણ કે તે પ્રમાણપત્રોનો ભંડાર છે.

સ્કીમ પણ તપાસો. HTTPS રિપોઝિટરી સુધી હજી HTTP પ્રોક્સી દ્વારા પહોંચી શકાય છે; ટ્રાન્સપોર્ટ મિરરની URI સ્કીમથી અલગ પસંદગી છે.

ગ્રાફિકલ સોફ્ટવેર કેન્દ્ર અલગ ફ્રન્ટ એન્ડ છે. જો તે PackageKit કે snap બેકએન્ડ વાપરે છે, તો APTનો ટુકડો તેના માટે કંઈ બદલતો નથી, તેથી ખાતરી કરો કે નિષ્ફળ વિનંતી કઈ પ્રક્રિયાએ કરી.

પથની ખાતરી કરો, ફક્ત નિકાસ કોડની નહીં

ટુકડો બેસી ગયા પછી લીલા પરિણામ પર ભરોસો કરવાને બદલે વિનંતી જુઓ. apt-get -o Debug::Acquire::http=true update કનેક્શનનો પ્રયાસ, પસંદ કરેલી પ્રોક્સી અને પ્રતિસાદ કોડ છાપે છે, જે ખોટી પ્રોક્સીને તમને નકારનારી પ્રોક્સીથી અલગ પાડે છે.

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

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