net.ipv4.conf.default.forwarding tun0 ને કેમ અડ્યા વગર રહેવા દે છે

તમે net.ipv4.conf.default.forwarding=1 સેટ કર્યું, VPN ફરી શરૂ કર્યું, અને ટનલ હજી પણ એ પેકેટો ફેંકી રહી છે જે ગેટવેએ રૂટ કરવા જોઈએ. ફાઇલમાં સેટિંગ સાચું લાગે છે, અને ઇન્ટરફેસ હજી પણ જણાવે છે કે ફોરવર્ડિંગ બંધ છે. કંઈ તૂટ્યું નથી: તમે એ મૂલ્ય બદલ્યું છે જે ભવિષ્યના ઇન્ટરફેસ વારસામાં લે છે, એ નહીં જે જીવંત ટનલ વાપરે છે.

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

ત્રણેય મૂલ્યો એકસાથે વાંચો

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

સામાન્ય પરિણામ છે ip_forward = 0, default.forwarding = 1 અને tun0.forwarding = 0. પહેલા બે હોસ્ટની ભૂમિકા વિશે સહમત નથી, અને ત્રીજું દર્શાવે છે કે ઇન્ટરફેસ ખરેખર શું કરે છે. આ સંયોજન એવા હોસ્ટ સાથે મેળ ખાય છે જે ક્યારેય રાઉટર તરીકે ગોઠવાયું નથી, ફક્ત ટેમ્પલેટ મૂલ્ય મળ્યું છે. ત્રણ આંકડા એકબીજા સાથે વિરોધાભાસી નથી; તેઓ ત્રણ જુદા પ્રશ્નોના જવાબ આપે છે. ટેમ્પલેટ મૂલ્ય લખવું પણ હોસ્ટની ભૂમિકા નક્કી કરતું નથી.

કેમ ગ્લોબલ સ્વિચ જ ખસે છે

net.ipv4.ip_forward ગેટવે-વ્યાપી નિયંત્રણ છે. તેને બદલવાથી એ જ ક્રિયાના ભાગ રૂપે પ્રતિ-ઇન્ટરફેસ ફોરવર્ડિંગ સેટિંગ્સ અપડેટ થાય છે, તેથી એક જ લખાણ હાલની ટનલને ફોરવર્ડ કરવાનું શરૂ કરાવી શકે છે. default.forwarding ફક્ત પછીથી શરૂ થતા ઇન્ટરફેસ વાવે છે, તેથી પહેલેથી અસ્તિત્વમાં હોય તેવી ટનલ જે મૂલ્ય સાથે જન્મી હતી તે જ રાખે છે.

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

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

સેટિંગને યોગ્ય જગ્યાએ કાયમી બનાવો

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

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

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

ખોટા સાધનથી આ સુધારશો નહીં

જ્યારે ફોરવર્ડિંગ તૂટેલું લાગ્યું, ત્યારે ફાયરવોલ ફ્લશ કરવાનો કે masquerading ઉમેરવાનો લોભ થાય. બંનેમાંથી કોઈ ફોરવર્ડિંગ સ્વિચને સંબોધતું નથી. ફોરવર્ડિંગ સ્થિતિ, ફોરવર્ડ કરવાની પરવાનગી, લક્ષ્ય માટે રૂટ અને પરત માર્ગ — આ ચાર અલગ જરૂરિયાતો છે, અને ફક્ત પહેલી જ sysctl છે.

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

IPv6 કેસ અલગ રાખો

અહીં બધું IPv4 છે. IPv6 ફોરવર્ડિંગ, રાઉટર જાહેરાતો અને accept_ra વર્તનના પોતાના નિયંત્રણો છે, અને ipv4 માર્ગને ipv6 સેટિંગમાં કોપી કરવાથી એવી ફાઇલ બને છે જે વિશ્વસનીય લાગે છે અને ઉપયોગી કંઈ કરતી નથી. ડ્યુઅલ-સ્ટેક ગેટવેને બંને સેટ ઇરાદાપૂર્વક ગોઠવેલા જોઈએ.

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