VPN ગેટવે ફરી શરૂ થાય ત્યારે IPv4 ફોરવર્ડિંગ ટકી રહે તેમ કરો

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

ગેટવે સુધી પહોંચવું એ ફોરવર્ડિંગ જેવું નથી

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

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

મૂલ્ય ત્યાં વાંચો જ્યાં પેકેટ ખરેખર છે

હોસ્ટ નેમસ્પેસમાં રૂટ કરતા ગેટવે પર, એક આદેશ પ્રશ્નનો જવાબ આપે છે: sysctl net.ipv4.ip_forward. જ્યારે ઇનગ્રેસ અને આગળનો રસ્તો નામવાળા નેમસ્પેસમાં રહે છે, ત્યારે એ નેમસ્પેસને પૂછો: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. હોસ્ટ મૂલ્ય નેમસ્પેસ મૂલ્યનો વિકલ્પ નથી, અને હોસ્ટ પર એક હોવું કોઈપણ વસ્તુનો પુરાવો નથી.

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

સેટિંગને એક જ માલિક આપો

પરંપરાગત systemd હોસ્ટ ગેટવે પર, ટકાઉ સ્વરૂપ એડમિનિસ્ટ્રેટર પસંદ કરેલા નામવાળી drop-in ફાઇલ છે, જેમ કે /etc/sysctl.d/60-vpn-forwarding.conf, જેમાં net.ipv4.ip_forward = 1 હોય છે. ફાઇલ લખો, પછી તે જ ફાઇલ લોડ કરો જેથી જીવંત સ્થિતિ પણ બદલાય: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, અને પછી વાંચીને ચકાસો. ફાઇલનું નામ ઉદાહરણ છે, અનામત VPN પાથ નહીં, અને શરૂઆતનો નંબર મહત્વનો છે કારણ કે પછી ગોઠવાયેલી ફાઇલો જીતે છે.

પ્રાધાન્ય એ જગ્યા છે જ્યાં ટકાઉપણું શાંતિથી તૂટે છે. વિતરણના લોડર તેમજ તમારી પોતાની drop-in તપાસો, કારણ કે procps sysctl --system અંતમાં /etc/sysctl.conf પણ વાંચે છે, જ્યારે systemd નો sysctl.d ક્રમ સંપૂર્ણપણે અલગ ક્રમ છે. પછીની સોંપણી એ જ કીને તરત જ પાછી મૂકી શકે છે, જેથી તમારી ફાઇલ સાચી અને અસરકારક મૂલ્ય ખોટું રહે. એ દલીલ જીતવા માટે હાલની એડમિનિસ્ટ્રેટર ફાઇલ પર ફરીથી ન લખો; માલિક શોધો અને ત્યાં બદલો.

બૂટ પછી બનાવેલ નેમસ્પેસ હોસ્ટ drop-in દ્વારા જરાય નિયંત્રિત થતું નથી. તેનું સેટિંગ જે તેને બનાવે છે તેનું છે, પછી તે કન્ટેનર રનટાઇમ હોય કે નેમસ્પેસ માટેનું પ્રોવિઝનિંગ યુનિટ. પ્રશ્ન ટાળવા માટે કન્ટેનરને વિશાળ હોસ્ટ વિશેષાધિકારો આપવા એ સાચો માલિક ઓળખવા માટે દસ મિનિટ ખર્ચવા કરતાં ખરાબ સોદો છે.

સ્વિચ ફેરવતા પહેલા તેની કિંમત જાણો

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

તે એ પણ બાકાત રાખે છે કે જ્યારે પણ ક્લાયન્ટ હોસ્ટ સુધી પહોંચી શકતું નથી ત્યારે તેને બંધ-ચાલુ કરવું. જો મૂલ્ય પહેલેથી એક છે, તો ખામી રસ્તામાં બીજે ક્યાંક છે, અને એ જ કીને ત્રીજી વાર ફરીથી લખવાથી તે ખસશે નહીં.

ટકાઉપણું સાબિત કરો, પછી બાકીનો રસ્તો ચકાસો

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

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

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