OpenVPN ક્લાયન્ટ પાછળનું સબનેટ કેમ પહોંચી શકાતું નથી?

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

tun ઇન્ટરફેસમાં પ્રતિ-ક્લાયન્ટ આગળનું હોપ હોતું નથી. કર્નલ ઘણા પીઅર સાથેનું એક જ ઇન્ટરફેસ જુએ છે, તેથી દૂરના LAN માટે કયો ક્લાયન્ટ પેકેટ મેળવશે તે નિર્ણય OpenVPN પ્રોસેસની અંદર લેવો પડે છે. તે નિર્ણય iroute થી ગોઠવાય છે, અને તેના વિના પેકેટને જવાનું કોઈ સ્થળ નથી.

સર્વર ઇન્ટરફેસ દ્વારા નહીં, ક્લાયન્ટ દ્વારા રૂટ કરે છે

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

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

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

ક્લાયન્ટનું નામ આપતી iroute એન્ટ્રી લખવી

iroute ક્લાયન્ટ-વિશિષ્ટ કન્ફિગરેશન ફાઇલમાં રહે છે, સર્વરના મુખ્ય કન્ફિગરેશનમાં નહીં. client-config-dir વિકલ્પ સાથે સર્વરને ડિરેક્ટરી તરફ નિર્દેશ કરો, પછી એવી ફાઇલ બનાવો જેનું નામ ક્લાયન્ટના સર્ટિફિકેટનું સામાન્ય નામ છે અને તેમાં પ્રીફિક્સ મૂકો.

જેની LAN 10.20.0.0/24 છે અને જેનું સર્ટિફિકેટ સામાન્ય નામ branch-router છે તેવી શાખા માટે, તે પાથની ફાઇલમાં iroute 10.20.0.0 255.255.255.0 જેવી લાઇન હોય છે. મુખ્ય કન્ફિગરેશનને ફક્ત ડિરેક્ટરી વિકલ્પની જરૂર છે; પ્રીફિક્સ ક્લાયન્ટ પાસે રહે છે.

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

એક ક્લાયન્ટ ઘણા પ્રીફિક્સ ધરાવી શકે છે. દરેક નેટવર્ક માટે એક iroute લાઇન ઉમેરો અને મેપિંગ ઓડિટપાત્ર રહે તે માટે યાદી તે ક્લાયન્ટની બાકીની સેટિંગ્સ પાસે રાખો.

બંને દિશામાં પરત માર્ગ બનાવવો

દૂરના LAN સુધી પેકેટ પહોંચાડવા એ અડધું કામ છે. ક્લાયન્ટે તે LANનું ટ્રાફિક ટનલમાં પણ મોકલવું પડે છે, જે સામાન્ય રીતે ક્લાયન્ટને રૂટ પુશ કરીને કરવામાં આવે છે: push "route 10.8.0.0 255.255.255.0" જેવી લાઇન દરેક ક્લાયન્ટને કહે છે કે સર્વર-બાજુના નેટવર્ક સુધી કેવી રીતે પહોંચવું. શાખા માટે, સમકક્ષ રૂટ સર્વર-બાજુએ જે પણ પહોંચવું જોઈએ તેના માટે ટનલ તરફ નિર્દેશ કરે છે.

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

સર્વર હોસ્ટ પર ફોરવર્ડિંગ સક્ષમ હોવું જોઈએ. તેના વિના કર્નલ ટનલમાંથી પેકેટ સ્વીકારે છે અને તેને LAN ઇન્ટરફેસ પર પસાર કરવાનો ઇનકાર કરે છે, જે ક્લાયન્ટની દૃષ્ટિએ ખૂટતા iroute જેવું જ દેખાય છે.

યોગ્ય પ્રોબ સાથે પહોંચ માન્ય કરવી

દૂરના છેડે ping કરીને અનુમાન કરવાને બદલે સ્તરે સ્તરે પરીક્ષણ કરો. સર્વરથી તપાસો કે પ્રીફિક્સ માટે આંતરિક મેપિંગ અસ્તિત્વમાં છે અને કર્નલ રૂટ ટનલ તરફ નિર્દેશ કરે છે. ક્લાયન્ટથી ખાતરી કરો કે પુશ કરેલો રૂટ ઇન્સ્ટોલ થયો છે અને LAN સરનામા માટે તેનો ડિફોલ્ટ માર્ગ ટનલ છે.

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

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