એક જ Pi પર Pi-hole અને VPN: શું ઓપરેટિંગ સિસ્ટમ હજી સપોર્ટેડ છે?

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

સપોર્ટ રિલીઝ શાખા નક્કી કરે છે, પરિવારનું નામ નહીં

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

તમારા Pi પર હજી બૂટ થતી જૂની ઇમેજ સપોર્ટનો પુરાવો નથી. બોર્ડ ઠીક છે, પેકેજ ઇન્ડેક્સ જૂનું છે, અને અસંગતિ પછી દેખાય છે, જ્યારે ઇન્સ્ટોલર એવી નિર્ભરતા ખેંચે છે જે રિલીઝ હવે પૂરી કરી શકતું નથી.

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

બાઇનરી લક્ષ્યને તમારા વપરાશકર્તા-જગત સાથે મેળવો

આર્કિટેક્ચર એ વધુ શાંત નિષ્ફળતા છે. 32-બિટ વપરાશકર્તા-ભૂમિ સાથે 64-બિટ કર્નલ ઘણા બોર્ડ પર વાસ્તવિક, સપોર્ટેડ સંયોજન છે, અને તે 32-બિટ FTL બાઇનરીને ફરિયાદ વિના ચલાવે છે, ત્યાં સુધી કે તમે ફક્ત arm64 માટે પ્રકાશિત કંઈક ઇન્સ્ટોલ કરો. ઇમેજ પસંદ કરતા પહેલાં બંને અર્ધ છાપો, અને આઉટપુટને તમારી નોંધની બાજુમાં રાખો.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

જો એ બે આર્કિટેક્ચર લીટીઓ મેળ ખાતી નથી, તો તમે મિશ્ર સેટઅપ પર છો: ફક્ત Pi-hole માટે ચાલુ, બીજી સેવા સ્વદેશી લાઇબ્રેરી માંગે ત્યાં નાજુક. સ્વચ્છ 64-બિટ ઇમેજ પર ફરી ફ્લેશ કરવું સામાન્ય રીતે અસંગતિ પેદા કરનારી ટૂલચેન ફરી બનાવવા કરતાં ઝડપી છે.

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

એક બોક્સ, બે સેવા, નેટવર્કનો એક માલિક

પહેલું પેકેજ ઉપર જાય તે પહેલાં નક્કી કરો કે સરનામાંકન, રિઝોલ્વર અને ટનલ કોની છે, નહીં તો બે સેવા એક જ ફરજ પર દાવો કરશે અને કોઈ ચોખ્ખી જીતશે નહીં. Piને તમારા રાઉટર આપતા DHCP પૂલની બહાર સ્થિર સરનામું આપો, અને ટનલને તેના પોતાના સબનેટ પર રાખો: Pi માટે 192.168.50.10 અને ટનલ માટે 10.42.0.0/24 એક ચાલુ વિભાજન છે, અને સંખ્યાઓ પોતે મનસ્વી છે જ્યાં સુધી તે તમારું રાઉટર પહેલેથી જે સેવા આપે છે તેની સાથે અથડાય નહીં. પછી લખો કે કયો કોમ્પોનન્ટ પોર્ટ 53 પર જવાબ આપે છે, કયો DHCP વહેંચે છે જો તમે તેનો ઉપયોગ કરો છો, અને ટનલ ચાલુ હોય ત્યારે કયાની પાસે ડિફોલ્ટ રૂટ છે. હેડલેસ ઇમેજ પર એ છેલ્લું કામ NetworkManager અથવા systemd-networkdનું છે, અને પ્રદાતા ક્લાયન્ટ ઇન્સ્ટોલ કરવો જે રિઝોલ્વર રૂપરેખાંકન પણ ફરીથી લખે છે એ રીત છે જેમાં લોકો જીવંત ટનલ અને મૃત DNS સાથે અટકી જાય છે.

બોક્સ વહેંચવું ઠીક છે. ભૂમિકા વહેંચવી ઠીક નથી. Pi-hole પોર્ટ 53 પર એકમાત્ર શ્રોતા બનવા માંગે છે, અને VPN ડિમન પોતાનું DNS સેટિંગ ક્લાયન્ટ સુધી ધકેલવા માંગે છે, તેથી પસંદ કરો કે ક્લાયન્ટને બેમાંથી કોના પર ભરોસો કરવો જોઈએ અને બીજાને રસ્તામાંથી હટી રહેવા ગોઠવો.

જ્યાં શક્ય હોય ત્યાં વ્યવસ્થાપન માર્ગને ટનલની બહાર રાખો. જો રિઝોલ્વર અને ટનલ સાથે નિષ્ફળ જાય, તો પણ તમે LAN સરનામા પર SSH પહોંચી શકાય તેમ ઇચ્છશો, અને તેનો અર્થ છે કે સંચાલન સેવા બંનેમાંથી કોઈની પર નિર્ભર ન હોવી જોઈએ.

આગલા અપગ્રેડને પસંદગીનો ભાગ બનાવો

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

હોલ્ડ કરેલા પેકેજ એ સામાન્ય કારણ છે કે અપગ્રેડ સફળ લાગે અને કંઈ બદલે નહીં. હોલ્ડ એક પછી એક જાણી જોઈને દૂર કરો, અને નોંધો કે કઈ સેવાને પિનની જરૂર હતી.

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

જ્યારે કોઈ એક રિલીઝ બંને સેવાઓ સાથે મેળ ખાતી નથી

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

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

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