શું દરેક OpenVPN પીઅરને remote લાઇનની જરૂર છે? બિલકુલ નહીં
remote નક્કી કરે છે કે પ્રથમ પેકેટ ક્યાં જાય છે; તે ક્લાયન્ટ, સર્વર કે TLS ભૂમિકા પસંદ કરતું નથી. બંને બાજુ કોપી કરતા પહેલાં ગોઠવણી વાંચો.
બે પીઅર રૂપરેખાંકનો સાથે સાથે સરખાવવામાં આવે છે, એકમાં remote લાઇન છે અને બીજામાં નથી, અને તારણ એ છે કે તેમાંથી એક તૂટેલું છે. આ અનુમાન પૂરતા વાર ખોટું હોય છે કે તેને ઉકેલવા યોગ્ય ગણાય. નિર્દેશ પ્રથમ પેકેટ ક્યાં મોકલવું જોઈએ તે વર્ણવે છે. તે પસંદ કરતું નથી કે પ્રક્રિયા શરૂ કરનાર ક્લાયન્ટ તરીકે કે રાહ જોતા ગેટવે તરીકે કાર્ય કરે છે, અને તે નક્કી કરતું નથી કે કઈ બાજુ બીજીને પોતાની ઓળખ સાબિત કરે છે.
remote ખરેખર શું નિર્દિષ્ટ કરે છે
remote એન્ટ્રી યજમાનનું નામ આપે છે, વૈકલ્પિક રીતે પોર્ટ અને ટ્રાન્સપોર્ટ, અને વૈકલ્પિક રીતે એવી ઘણી એન્ટ્રીઓ જે ક્રમમાં અજમાવવામાં આવે છે.
તેની ગેરહાજરીનો અર્થ નિશ્ચિત છે, અનિશ્ચિત નહીં: પ્રક્રિયા રાહ જુએ છે અને તે પીઅર પ્રમાણીકરણ ન કરે ત્યાં સુધી કોઈ સરનામાંથી આવતા પેકેટ પર કાર્ય કરતી નથી. તેથી ફરતા વપરાશકર્તાઓને સેવા આપતા ગેટવેને તેમાંથી કોઈનું નામ અગાઉથી આપવાનું કોઈ કારણ નથી.
એન્ટ્રીને સરનામાંના સંબંધ તરીકે વાંચો. દૂરનો છેડો વિશ્વસનીય છે કે નહીં તે પ્રમાણપત્રો અને ચકાસણી વિકલ્પો જવાબ આપે છે, સરનામું લખાયું છે એ હકીકત નહીં.
ત્રણ ગોઠવણીઓ જવાબ નક્કી કરે છે
ફરતા ક્લાયન્ટને ગંતવ્યની જરૂર છે, કારણ કે તેણે શરૂ કરવું પડે છે અને તેના વિના ગેટવે ક્યાં છે તેની તેને ખબર નથી. બહુ-ક્લાયન્ટ ગેટવેને વપરાશકર્તા દીઠ ગંતવ્યની જરૂર નથી, કારણ કે ક્લાયન્ટ આવે છે અને પ્રમાણીકરણ કરે છે. જાણીતા છેડા ધરાવતી જાણી જોઈને બનાવેલી બે-પીઅર કડીમાં એક બાજુ, બંને બાજુ કે કોઈ બાજુ ગંતવ્ય હોઈ શકે, કઈ બાજુ શરૂ કરે તેના આધારે.
સામાન્ય ગેટવેમાં નિશ્ચિત ક્લાયન્ટ સરનામું પેસ્ટ કરવું એ તે શ્રેણીઓને અવગણવાથી થતી ભૂલ છે. તે એક જ પીઅર માટે કામ કરે છે જેનું સરનામું નોંધાયું હતું અને બાકીના બધાને ભ્રમિત કરે છે.
નિર્દેશમાં એવું કંઈ નથી જે રૂપરેખાંકનને બહુ-ક્લાયન્ટ સર્વરમાં ફેરવે, અને તેની હાજરીમાં એવું કંઈ નથી જે સર્વર ભૂમિકાને અટકાવે. OpenVPN 2.6 સંદર્ભ વૈકલ્પિક દલીલો અને remote વગરના વર્તનને અલગ રીતે દસ્તાવેજ કરે છે, જે તેમની સ્વતંત્રતાનો સંકેત છે.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
ટ્રાન્સપોર્ટ ભૂમિકાઓ બીજો અક્ષ છે
TCP માં એક બાજુ રાહ જુએ છે અને બીજી જોડાણ સ્થાપિત કરે છે. આ ગંતવ્યથી અલગ નિર્દેશો છે, અને તેમને ભેગા કરવાથી એવી જોડી બને છે જે બંને રાહ જુએ છે અથવા બંને જોડાણ સ્થાપિત કરે છે.
TCP સ્રોત-ફિલ્ટર ભૂમિકા પણ છે, તેથી સર્વરમાં ક્યારેય remote હોઈ શકે નહીં એ સીધું વિધાન ખોટું છે.
UDP માં સ્થાપિત કરવા જેવું કોઈ જોડાણ નથી, તેથી બંને છેડા અનુરૂપ UDP ટ્રાન્સપોર્ટ વાપરે છે અને નિર્દેશ ફક્ત કહે છે કે ક્યાં નિશાન લેવું. પ્રમાણીકૃત પીઅરના સરનામાંના ફેરફારો વધુ એન્ટ્રીઓ ઉમેરવાને બદલે સમર્પિત વર્તન દ્વારા સંભાળવામાં આવે છે. ટ્રાન્સપોર્ટ બરાબર હોવો એ ગંતવ્યનો અર્થ હોય તેની પૂર્વશરત છે, અને બંનેને ભેગા કરવાથી એવા રૂપરેખાંકનો બને છે જે વિશ્વસનીય લાગે છે અને ક્યારેય હેન્ડશેક પૂર્ણ કરતા નથી.
remote ની ગેરહાજરી ખુલ્લું દરવાજો કેમ નથી
ગંતવ્ય વગરની પ્રક્રિયા પણ પ્રમાણીકરણ ન કરતા પીઅરનો ટ્રાફિક નકારે છે, અને લોકો જ્યારે ગેરહાજર લાઇનને બધા માટે ખુલ્લા શ્રોતા તરીકે વાંચે છે ત્યારે આ ભાગ ચૂકી જાય છે.
પ્રમાણીકરણ અને ગંતવ્ય સ્વતંત્ર છે, અને વિશ્વાસ માટે પ્રથમ જ મહત્વનું છે.
ઊલટી ભૂલ વધુ જોખમી છે. નિશ્ચિત સ્રોત સરનામું ઍક્સેસ નિયંત્રણ જેવું લાગી શકે કારણ કે તે ચોક્કસ અને ચકાસવામાં સરળ છે, પરંતુ તે બીજા છેડે કોણ છે તે વિશે કંઈ સાબિત કરતું નથી. પ્રમાણપત્ર ચકાસણી રાખો, અને પ્રમાણપત્રને તેની ભૂમિકા સાથે જોડતી ઓળખ ચકાસણીઓ પણ રાખો. તેમને સરનામાંના મેળથી બદલવું વાસ્તવિક નિયંત્રણને તેના દેખાવ સાથે બદલે છે.
રૂપરેખાંકન શું ધારે છે તે લખો
દરેક બાજુ માટે ત્રણ વસ્તુઓ નોંધો: પ્રથમ પેકેટ પીઅર સુધી કેવી રીતે પહોંચે છે, કઈ બાજુ ટ્રાન્સપોર્ટ સ્વીકારી શકે છે, અને દરેક બાજુ બીજા વિશે શું ચકાસે છે.
તે ધારણાઓ જ ડિઝાઇન છે. નિર્દેશો ફક્ત તેમની જોડણી છે.
જો બે ફાઇલો અલગ હોય, તો એક ખોટી છે એમ ધારવાને બદલે તપાસો કે તેઓ અલગ ધારણાઓ વ્યક્ત કરે છે કે નહીં. સમમિત ફાઇલ જોડી કાર્યકારી ટનલ માટે ન આવશ્યક છે ન પર્યાપ્ત, અને અસમમિતતા ઘણી વાર તે ભાગ હોય છે જે ટોપોલોજીને કામ કરાવે છે.