ફક્ત TCP 443 ની મંજૂરી આપતા નેટવર્ક UDP સરળતાથી પસાર થવા દેતા નેટવર્ક સાથે સહઅસ્તિત્વ ધરાવે છે, અને એક સર્વરે બંનેને સેવા આપવી પડે છે. proto udp વાળી પ્રોફાઇલ બીજા જૂથને જવાબ આપે છે અને પહેલા સાથે નિષ્ફળ જાય છે, અને proto tcp કહેવા માટે એ જ રૂપરેખા સંપાદિત કરવાથી બીજું લિસનર બનતું નથી. આ નિર્દેશ એક પ્રક્રિયા માટે એક જ પરિવહન પસંદ કરે છે. બાકીનું બધું તે મર્યાદામાંથી અનુસરે છે.

કાં તો તમે એકથી વધુ પ્રક્રિયા ચલાવો, અથવા એવી આવૃત્તિ ચલાવો જે એકસાથે ઘણા સોકેટ બાંધી શકે.

2.7 પહેલાં એક પ્રક્રિયા એક જ પરિવહન બાંધે છે

કોમ્યુનિટી OpenVPN એ સોકેટ બાંધે છે જે proto વર્ણવે છે, અને તે નિર્દેશ ઇન્સ્ટન્સ માટે એક જ પરિવહન પસંદ કરે છે. TCP અને UDP અલગ સ્ટેક છે, તેથી એ જ પોર્ટ નંબર એક જ સમયે બંને દ્વારા ધરાવી શકાય, પણ એક પ્રક્રિયા દ્વારા નહીં. તેથી 2.6 શ્રેણી તમને દરેક ડીમન માટે એક પરિવહન આપે છે. OpenVPN 2.7 એ સર્વરો માટે તે મર્યાદા દૂર કરી, જે એક જ પ્રક્રિયામાં અનેક --local વિધાનો દ્વારા અનેક સોકેટ બાંધી શકે છે.

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

બે ઇન્સ્ટન્સ ચલાવવાની ત્રણ રીતો

TAP ઇન્ટરફેસ સાથે, દરેક પરિવહન માટે એક ઇન્સ્ટન્સ ચલાવો અને હોસ્ટ પર બે tap ઉપકરણોને બ્રિજ કરો. બંને ક્લાઇન્ટ સમૂહ એક જ બ્રોડકાસ્ટ ડોમેનમાં પૂરા થાય છે, જેનાથી એક સરનામા પૂલ તેમને આવરી શકે છે અને બ્રોડકાસ્ટ પર નિર્ભર પ્રોટોકોલ કામ કરતા રહે છે. TUN સાથે બ્રિજિંગ ઉપલબ્ધ નથી, તેથી સૌથી સરળ વિભાજન દરેક ઇન્સ્ટન્સને તેનું પોતાનું સબનેટ આપે છે અને રાઉટિંગ બંને ક્લાઇન્ટ સમૂહને અલગ રાખે છે. ત્રીજો વિકલ્પ એક જ પૂલ રાખે છે, જેમાં દરેક ઇન્સ્ટન્સ learn-address સ્ક્રિપ્ટને બોલાવે છે જે તે ઇન્સ્ટન્સના ઉપકરણ દ્વારા ક્લાઇન્ટ માટે /32 રૂટ સ્થાપિત કરે છે.

તે ત્રીજી ગોઠવણ એ છે જે લોકો માંગે છે અને જેને સૌથી વધુ કાળજીની જરૂર છે, કારણ કે સ્ક્રિપ્ટ ડેટા પાથનો ભાગ બની જાય છે અને ઉમેરો, અપડેટ અને કાઢી નાખવાની ઘટનાઓને યોગ્ય રીતે સંભાળવી પડે છે.

ArrangementInterfacesAddress poolCost
Bridged TAP pairTwo tap devices joined by a bridgeOne shared poolBroadcast traffic and bridge maintenance
Two TUN subnetsTwo tun devices, no bridgeOne pool per instanceRouting rules and two plans
Shared pool with routesTwo tun devices plus a hookOne pool across bothA script on the data path

બંને ઇન્સ્ટન્સ અલગ રાખો

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

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

પ્રોફાઇલને લિસનર સાથે મેળવો

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

ફાયરવોલ નિયમો એ જ વિભાજન અનુસરે છે: UDP 1194 માટેનો નિયમ TCP 1194 વિશે કંઈ કહેતો નથી, અને એક સરનામા માટેનો નિયમ બીજા લિસનરને આવરી લેતો નથી.

પહેલાં સર્વરનું દૃશ્ય વાંચો

સર્વર પર ss -lntup થી શરૂ કરો અને ખાતરી કરો કે TCP અને UDP બંને લિસનર દેખાય છે. પછી દરેક પ્રકારનો એક ક્લાઇન્ટ જોડો અને અલગ સરનામાંવાળી બે એન્ટ્રી માટે સ્ટેટસ આઉટપુટ તપાસો. જો સોકેટ અસ્તિત્વમાં હોય અને કોઈ ક્લાઇન્ટ ન આવે, તો ડીમન તેમને જોવા પહેલાં પાથ કે ફાયરવોલ પેકેટો નકારી રહ્યા છે.

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

સંબંધિત લેખો