Pi VPN સર્વર: રેસીપીથી નહીં, ફોનની એપથી શરૂ કરો

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

એ ક્રમ જે પુનર્બાંધકામ બચાવે છે

Pi પર કંઈપણ ઇન્સ્ટોલ કરતા પહેલાં ફોનનું ઓપરેટિંગ સિસ્ટમ અને ચોક્કસ VPN એપ લખી લો. આ જોડી નક્કી કરે છે કે કયો પ્રોટોકોલ બિલકુલ શક્ય છે. પ્રોફાઇલમાં કોઈ પરિચિત ફીલ્ડ હોય એટલા માત્રથી ક્લાયન્ટ એપ બીજું ક્લાયન્ટ બનતું નથી.

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

એપ નિશ્ચિત થયા પછી સર્વરની પસંદગી સાંકડી થાય છે અને બાકીના બાંધકામને લક્ષ્ય મળે છે.

ફોનની એપ ખરેખર શું અમલમાં મૂકે છે

પ્રકાશિત ક્લાયન્ટ યાદી એપ્લિકેશનનું વર્ણન કરે છે, સેવાનું નહીં. Android માટે OpenVPN Connect એપ OpenVPN સર્વરની અપેક્ષા રાખે છે; તે સર્વરની બાજુ પૂરી પાડતી નથી. પ્રોફાઇલ સમાન દેખાય ત્યારે તે IPsec કે L2TP ક્લાયન્ટ પણ બનતું નથી.

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

સર્વર પેકેજ પ્રતિ વચન આપતા પહેલાં એપના વર્તમાન દસ્તાવેજોમાં જુઓ કે તે કયા પ્રોફાઇલ ફોર્મેટ આયાત કરે છે. પાંચ મિનિટનું વાંચન પુનર્બાંધકામ કરતાં સારું છે.

ચાર ભાગનો કરાર

ચાર વસ્તુઓ નોંધો અને એકસાથે રાખો: ફોનનું ઓપરેટિંગ સિસ્ટમ અને એપ આવૃત્તિ, Pi પર સર્વરનો અમલ, પ્રમાણીકરણ અને વિશ્વાસ નીતિ, અને બાહ્ય અંતિમ બિંદુ. ચારમાંથી દરેક બાકીના ત્રણને અમાન્ય કરી શકે છે.

એપ અપગ્રેડ, સર્વર પેકેજમાં ફેરફાર અથવા નવી સર્ટિફિકેટ ઓથોરિટી કરાર તોડે છે, અને ફોનથી નિષ્ફળતા દર વખતે એકસરખી દેખાય છે. ચાર લખેલા હોવા એ જ તમને ઓળખવા દે છે કે કયો ભાગ ખસ્યો છે.

ઓળખપત્રોના અલગ કામ છે

નક્કી કરો કે પ્રોફાઇલ ક્લાયન્ટ સર્ટિફિકેટ, વપરાશકર્તાનામ અને પાસવર્ડ, કે સમર્થિત સંયોજન વાપરે છે, અને બંને છેડા સહમત કરાવો. સર્વરની ઓળખ અને વિશ્વસનીય CA સામગ્રી પણ ક્લાયન્ટ સ્વીકારશે તેની સાથે મેળ ખાવી જોઈએ.

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

હાથે પ્રોફાઇલ જોડવાને બદલે સેવા દ્વારા સમર્થિત નિકાસ અને આયાત પ્રવાહ વાપરો. હાથે બનાવેલા પ્રોફાઇલમાં સામાન્ય રીતે ફક્ત ડેસ્કટોપ માટેની સૂચનાઓ હોય છે જે મોબાઇલ એપ અવગણે છે અથવા નકારે છે.

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

પહોંચ એ અલગ કરાર છે

ફોનને સર્વરના બાહ્ય અંતિમ બિંદુ સુધી પહોંચવું પડે છે વાસ્તવિક અપસ્ટ્રીમ ગોઠવણી દ્વારા. ઘરના રાઉટરનું ભાષાંતર, ફિલ્ટરિંગ અને ઓપરેટરનું NAT બધું બંને વચ્ચે બેસે છે. ડાયનેમિક DNS નામ અંતિમ બિંદુને ફક્ત સ્થિર નામ આપે છે; તે અંદર આવતો માર્ગ બનાવતું નથી.

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

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