IPv6 શાખા ઉપસર્ગ: સર્વર પર iroute-ipv6 કે route-ipv6?

લગભગ એક જ નામની બે સૂચનાઓ દરેક કામ કરતા ઉદાહરણમાં આવે છે, અને એકને બીજા વિના કૉપી કરવાથી એવી ટનલ બને છે જે સાચી દેખાય છે અને શાખા ઉપસર્ગ ચૂપચાપ ગુમાવે છે. તેઓ એક જ સીમાની બે જુદી બાજુએ જુદું કામ કરે છે: એક સર્વરના કર્નલને શીખવે છે કે ઉપસર્ગ ક્યાં રહે છે, અને બીજી OpenVPN ને શીખવે છે કે કયો પ્રમાણિત ક્લાયન્ટ તેને વહન કરે છે. બંને સાચા હોય તો ઉપસર્ગ વહે છે; એક સાચું હોય તો પેકેટને માર્ગ છે પણ માલિક નથી.

બે સૂચનાઓ, બે જુદાં કામ

route-ipv6 એ સામાન્ય માર્ગ સ્થાપન છે: સર્વર એક કર્નલ માર્ગ ઉમેરે છે જે ઉપસર્ગને તેના ટનલ ઇન્ટરફેસ તરફ દર્શાવે છે. iroute-ipv6 ચોક્કસ ક્લાયન્ટના સંદર્ભનું છે અને આંતરિક માલિકી જાહેર કરે છે, તેથી ડેમન જાણે છે કે તે ઉપસર્ગની ટ્રાફિક ચોક્કસ ક્લાયન્ટને મોકલવી જોઈએ, નહીં કે કર્નલ માર્ગ સંયોગવશ સંબોધે તે પીઅરને.

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

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

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

કઈ ક્યાં જાય છે

માર્ગ સર્વરની વ્યવસ્થિત કન્ફિગરેશનમાં જાય છે, જ્યાં તે તે જ સર્વર પ્રક્રિયા પર લાગુ થાય છે. iroute ક્લાયન્ટ-વિશિષ્ટ ફાઇલમાં જાય છે, જે શાખા ઉપકરણની પ્રમાણિત ઓળખના નામે છે.

એવું ફાઇલ નામ જે વાસ્તવિક ઓળખ સાથે મળતું નથી તે ક્યારેય વંચાતું નથી, અને લક્ષણ બરાબર ગુમ iroute જેવું હોય છે. સર્વરે પ્રમાણિત કરેલી ઓળખ તપાસો, પછી ફાઇલ નામ અક્ષરે-અક્ષરે તપાસો.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

પૂલ અને શાખા ઉપસર્ગ અલગ રાખો, કારણ કે તેમનો ઓવરલેપ એવી કોયડો બનાવે છે જેને કોઈ સૂચના હલ કરી શકતી નથી.

બીજા ક્લાયન્ટને શું જોઈએ

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

તેને શાખાને જ ન મોકલો, કારણ કે તે ઉપકરણ પાસે ઉપસર્ગ પહેલેથી જોડાયેલા નેટવર્ક તરીકે છે.

તેને બધાને મોકલવું પરિણામોવાળી પસંદગી છે: પછી દરેક ક્લાયન્ટ માને છે કે શાખા ટનલ દ્વારા પહોંચી શકાય છે, તે ક્લાયન્ટો સહિત જેમને તમે ક્યારેય આ પ્રવેશ આપવા નહોતા માગ્યા. જાહેરાત વ્યવહારમાં પ્રવેશનો નિર્ણય છે, જોકે સૂચના પ્લમ્બિંગના કામ જેવી લાગે. સર્વર વિકલ્પ સંદર્ભ iroute-ipv6 ને ક્લાયન્ટ-વિશિષ્ટ માલિકી તરીકે દસ્તાવેજ કરે છે, અને આ જ તે ભેદ છે જે રાખવો કિંમતી છે.

શાખા ઉપકરણ પર પાછા ફરવાનો માર્ગ

માલિકી ત્યારે જ મદદ કરે છે જ્યારે શાખા પેકેટ ફોરવર્ડ કરે અને તેનું LAN જવાબ આપવા જાણે. શાખા ઉપકરણ પર IPv6 ફોરવર્ડિંગ સક્ષમ કરો, અને ખાતરી કરો કે તેના LANના હોસ્ટ VPN પૂલની ટ્રાફિક પાછી શાખા તરફ મોકલે છે, પૂલ ન જાણતા ડિફૉલ્ટ માર્ગ તરફ નહીં.

તે પાછા ફરવાનો માર્ગ IPv6માં તે ગુમ માર્ગ સમસ્યાનો સમકક્ષ છે જે લોકોને IPv4માં મળે છે.

તેને LANના હોસ્ટથી VPN પૂલના સરનામાની ક્વેરી સાથે તપાસો, શાખાથી જ નહીં. રાઉટર પર કરેલી ક્વેરી તમારા વપરાશકર્તાઓના પ્રશ્ન કરતાં જુદા પ્રશ્નનો જવાબ આપે છે, અને બંને પૂરતી વાર જુદા પડે છે કે વધારાનો આદેશ કિંમતી થાય.

જ્યારે જોડી હજી પૂરતી ન હોય

કેટલાક તૈનાતી આ માર્ગ બિલકુલ વાપરતા નથી. કર્નલનો ડેટા માર્ગ અને ઉત્પાદન-વ્યવસ્થિત સર્વરો પાસે પોતાની સમર્થિત માર્ગ હેન્ડલિંગ છે, અને userspace ઉદાહરણ સીધું સ્થાનાંતરિત ન થાય.

બીજા માટે લખાયેલી માર્ગદર્શિકા પરથી સૂચનાઓ કૉપી કરતા પહેલાં ખાતરી કરો કે તમારું બિલ્ડ કયો ડેટા માર્ગ વાપરે છે.

અને અંતે, સરનામાંઓનો વ્યાપ યાદ રાખો: અનન્ય સ્થાનિક ઉપસર્ગ જેવું fd00:7a::/64 ડિઝાઇનથી ખાનગી છે અને જાહેર IPv6 પહોંચ વિશે કંઈ કહેતું નથી. તેને આંતરિક પ્રવેશ ગણો, અને ઇન્ટરનેટ બહાર જવાને પોતાની નીતિવાળો અલગ વિષય રાખો.