OpenVPN iroute વિરુદ્ધ કર્નલ રૂટ: કયો ખૂટે છે?

10.77.20.0/24 માટેનું પેકેટ OpenVPN સર્વર પર બે અલગ નિર્ણય લે છે: ઓપરેટિંગ સિસ્ટમે તેને VPN ઇન્ટરફેસને સોંપવું પડે છે, અને OpenVPN ને જાણવું પડે છે કે કયો જોડાયેલ ક્લાયન્ટ એ પ્રીફિક્સનો માલિક છે. ખૂટતો કર્નલ રૂટ તેને ટનલ પહેલાં પડતો મૂકે છે, અને ખૂટતો પીઅર રૂટ તેને પછી પડતો મૂકે છે. બંને નિષ્ફળતાઓ દૂરના LAN પરથી એકસરખી દેખાય છે, અને તમારી પાસે કઈ છે તે નિદાન કરવા માટે દરેક બાજુ એક આદેશ જોઈએ છે.

ક્લાસિક યુઝરસ્પેસ ડેટા પથમાં કર્નલ રૂટ પેકેટને ટનલ પ્રોસેસમાં લઈ જાય છે અને iroute તે પ્રોસેસને કહે છે કે કયા પીઅરે તે મેળવવું જોઈએ. એક પણ બીજાનું સ્થાન લેતું નથી, અને તેમાંથી માત્ર એક જ ધરાવતું રૂપરેખાંકન પહેલા ping સુધી વાજબી લાગશે.

બે નિર્ણય, એક રૂટ નહીં

સાઇટ-થી-સાઇટ લિંકની કલ્પના કરો જ્યાં 10.77.20.0/24 એક જ ક્લાયન્ટ પાછળ બેઠું છે. સર્વરનો કર્નલ રૂટ, ઉદાહરણ તરીકે ip route add 10.77.20.0/24 dev tun0, મેળ ખાતાં પેકેટને ટનલ ઉપકરણ પર મોકલે છે. પછી OpenVPN ક્લાયન્ટ રૂપરેખાંકન ડિરેક્ટરીમાંના iroute નોંધોમાંથી બનેલા પોતાના આંતરિક કોષ્ટકને જુએ છે, જેથી નક્કી કરે કે કઈ પીઅર જોડાણ તેમને મેળવે છે. કર્નલ રૂટ વિના પેકેટ પ્રોસેસ સુધી કદી પહોંચતું નથી, અને પીઅર રૂટ વિના તે પ્રોસેસ સુધી પહોંચે છે અને ક્યાંય જતું નથી.

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

iroute ક્યાં રહે છે અને શું કહે છે

નોંધ ક્લાયન્ટના common_name પ્રમાણે નામવાળી પ્રતિ-ક્લાયન્ટ ફાઇલમાં, client-config-dir હેઠળ, iroute 10.77.20.0/24 તરીકે જાય છે. ફાઇલનામની મેળવણી સુશોભન નથી: OpenVPN પ્રમાણિત ઓળખ શોધે છે અને બરાબર એ જ નામવાળી ફાઇલ વાંચે છે, તેથી site-a નામની ફાઇલ ફક્ત એ ક્લાયન્ટ માટે જ લાગુ પડે છે જેનું સામાન્ય નામ site-a છે. જો એવી ફાઇલ વિનાના ક્લાયન્ટને સંપૂર્ણપણે નકારવા હોય તો ccd-exclusive ઉમેરો, જે ત્યારે યોગ્ય સેટિંગ છે જ્યારે દરેક ક્લાયન્ટ સાઇટ ગેટવે હોય. દરેક ગેટવે માટે એક ફાઇલ રાખો અને તેને તમે ખરેખર બહાર પાડતા પ્રમાણપત્રના વિષય પ્રમાણે નામ આપો.

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

જાળ: ફાઇલ છે, ઓળખ ખોટી

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

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

પીઅરની પાર પથ પૂરો કરો

પીઅર માલિકી પથની મધ્યમાં છે, અંતમાં નહીં. ક્લાયન્ટે ટનલમાંથી પેકેટ તેના LAN માં ફોરવર્ડ કરવાં પડે, એટલે કે તે હોસ્ટ પર IP ફોરવર્ડિંગ સક્ષમ હોવું જોઈએ અને ફાયરવોલ નિયમ પસાર થવા દેવો જોઈએ. દૂરના LAN ના હોસ્ટને ટનલ સરનામા માટે પરત પથની જરૂર છે: કાં તો ગેટવે તરફ પાછો દોરતો રૂટ, અથવા ક્લાયન્ટ બાજુ ઇરાદાપૂર્વકની NAT ડિઝાઇન. ડિસ્ટ્રિબ્યુશનના ડિફોલ્ટને ધારી લેવાને બદલે sysctl net.ipv4.ip_forward વડે ક્લાયન્ટ પર ફોરવર્ડ સેટિંગની પુષ્ટિ કરો.

જો અન્ય VPN ક્લાયન્ટને તે સબનેટ સુધી પહોંચવું હોય, તો ગોઠવણ ફરી વધે છે: સર્વરને client-to-client જોઈએ છે, અને તે ક્લાયન્ટે પ્રીફિક્સ ટનલ દ્વારા રૂટ કરવું પડે છે. એમાંથી કંઈ પણ સર્વરના પોતાના રૂટ કોષ્ટકમાંથી આવતું નથી.

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