OpenVPN ને TAP થી TUN તરફ ખસેડવું: એક માઇગ્રેશન ક્રમ જે કામ કરે છે

dev tap ના બદલે dev tun મૂકવાથી ટનલ શું વહન કરે છે તે બદલાય છે, ફક્ત તેનું નામ નહીં। TAP ઇન્ટરફેસ Ethernet ફ્રેમ્સ બ્રિજને આપે છે, તેથી ક્લાયન્ટ એમ વર્તે છે જાણે ઓફિસના સ્વિચમાં જોડાયેલા હોય। TUN ઇન્ટરફેસ IP પેકેટ્સ વહન કરે છે, તેથી ક્લાયન્ટને રૂટની જરૂર પડે છે અને સામેના પક્ષને પરત માર્ગની જરૂર પડે છે। ક્લાયન્ટ, સરનામા યોજના અને LAN નો પરત માર્ગ — બધાએ આ ફેરફાર સાથે ખસવું પડે છે।

માઇગ્રેશન એ ટનલ જોડાયેલા નેટવર્કનું પુનઃડિઝાઇન છે, અને નીચેનો ક્રમ તેને ઉલટાવી શકાય તેવું રાખે છે।

Ethernet પર ખરેખર શું નિર્ભર છે તેની યાદી બનાવો

હોસ્ટ નહીં, એપ્લિકેશનોની યાદી બનાવો। દરેક રૂટેડ TCP કે UDP સેવાઓ, બ્રોડકાસ્ટ શોધ, ઓફિસ LAN માંથી DHCP, IP-સિવાયનો Ethernet પ્રોટોકોલ, કે બંને છેડા એક જ સબનેટમાં છે એવી ધારણા વાપરે છે કે નહીં તે નક્કી કરો। સામાન્ય IP પ્રવેશ રૂટેડ ડિઝાઇનમાં ટકે છે। કાચા Ethernet ફ્રેમ્સ જોઈતા પ્રોટોકોલ ટકતો નથી, અને કોઈ પણ રૂટિંગ તેને કામ કરાવશે નહીં। શોધ પર નિર્ભર એપ્લિકેશનોને કટઓવર પહેલાં નક્કી થયેલી વૈકલ્પિક વ્યવસ્થા જોઈએ, કટઓવર દરમિયાન નહીં।

એ યાદી સ્વીકૃતિ યાદી પણ છે। તમે જે પ્રવેશ સ્થાનાંતરિત કરી શકો નહીં તે દસ્તાવેજીકૃત અપવાદ બને છે, અથવા ફક્ત એ કાર્યભાર માટે નાનું TAP સેગમેન્ટ જીવંત રાખવાનું કારણ બને છે।

સરનામા અને પરત માર્ગની યોજના બનાવો

એવો ક્લાયન્ટ પ્રિફિક્સ પસંદ કરો જે LAN, જૂના બ્રિજ રેન્જ કે ક્લાયન્ટ પહેલેથી પહોંચે છે તેવા કોઈ નેટવર્ક સાથે ઓવરલેપ ન થાય।dev tun, topology subnet અને server 10.78.0.0 255.255.255.0, પણ આ એક ટુકડો છે, કામ કરતી પ્રોફાઇલ નહીં। તેની આસપાસ મંજૂર TLS, ઓળખ, પરિવહન અને પ્રવેશ નીતિ રાખો, અને એવો પ્રિફિક્સ વાપરો જે મુક્ત હોવાની તમે ચકાસણી કરી છે।

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

અલગ શ્રોતા પર પાયલટ કરો

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

ફરી જોડાણ અને પરત ટ્રાફિકની કસોટી સામેલ કરો। પૂર્ણ થતો હેન્ડશેક એ કહેતો નથી કે સામેનો પક્ષ જવાબ આપી શકે છે કે નહીં।

ક્લાયન્ટને રોલબેક સાથે જૂથોમાં ખસેડો

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

જૂથો તમને એ એપ્લિકેશન શોધવાની જગ્યા પણ આપે છે જે કોઈએ ઉલ્લેખ નથી કર્યો, જ્યારે જૂનો માર્ગ હજી સરખામણી માટે હાજર છે।

બ્રિજ ફક્ત સ્વીકૃતિ પછી નિવૃત્ત કરો

TAP ઉપકરણ દૂર કરવું છેલ્લું પગલું છે, પહેલું નહીં। કંઈપણ ડિલીટ કરતા પહેલાં તપાસો કે બ્રિજ હજી સર્વરનું સંચાલન સરનામું, મોનિટરિંગ માર્ગ કે અસંબંધિત કાર્યભાર વહન કરે છે કે નહીં। સ્ટાર્ટઅપ નિર્ભરતાઓ, બ્રિજ સભ્યપદ અને DHCP અનામતો તેમના માલિકો દ્વારા, એ જ ક્રમમાં નિવૃત્ત કરો, અને શું દૂર કર્યું તેની નોંધ રાખો।

માઇગ્રેશન ત્યારે પૂર્ણ થાય છે જ્યારે રૂટેડ પ્રવેશ મોડેલ યાદી માટે કામ કરે, ત્યારે નહીં જ્યારે TAP ઇન્ટરફેસ ip link ના આઉટપુટમાંથી અદૃશ્ય થાય।