Linux VPN ના જવાબો ગાયબ થાય છે? rp_filter અને રૂટ તપાસો

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

સ્રોત માન્યતા શું નક્કી કરે છે

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

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

અસરકારક મોડ વાંચો, એક ફીલ્ડ નહીં

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

ત્રીજી લાઇનમાંની રૂટ શોધ એ ભાગ છે જે લોકો છોડી દે છે. તે તમને કહે છે કે કર્નેલ સ્રોત વિશે શું માને છે, અને એ જ તપાસનું ઇનપુટ છે.

તપાસ બદલતાં પહેલાં અસંગતિ શોધો

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

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

પહેલી પ્રતિક્રિયા તરીકે સ્રોત તપાસ વૈશ્વિક રીતે બંધ ન કરો. તે ચોક્કસ નિદાનને વિશાળ વર્તન પરિવર્તન સાથે બદલે છે જે તમારે પછી યાદ રાખવું પડશે.

પસંદગીનું સમાયોજન જેનું તમે બચાવ કરી શકો

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

એવો કિસ્સો સામેલ કરો જે હજી પણ નકારાવો જોઈએ. જો એ કિસ્સો હવે સફળ થાય, તો સમાયોજને તમે સુધારવા માંગતા એક જ પથ કરતાં વધુ નબળું કર્યું છે.

IPv4 અને IPv6 અલગ રાખો

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

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