ઓફિસ LAN પર VPN ક્લાયન્ટ દરેક જવાબ કેમ ગુમાવે છે

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

ફેંકવાની ઘટના કંઈ પેકેટ વાંચે તે પહેલાં જ થાય છે

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

અહીં ક્લાયન્ટ પોતાના ટનલ પર 10.66.0.9 ધરાવે છે, અને OpenVPN સર્વર ઓફિસ પ્રીફિક્સની અંદર 192.168.80.10 પરથી જવાબ આપે છે. 192.168.80.25 પરનો સહકર્મી ટનલના સરનામાં પર પિંગ કરે છે, તેથી વિનંતી LAN પાર કરે છે, સર્વર તેને ટનલમાં મોકલે છે, અને તે ઓફિસના સ્રોત સરનામા સાથે ક્લાયન્ટના ટનલ ઇન્ટરફેસ પર પહોંચે છે. તે મશીનના રાઉટિંગ કોષ્ટકમાં ઓફિસ પ્રીફિક્સ ઇથરનેટ ઉપકરણનું છે, ટનલનું નહીં. માન્યકરણ આગમન ઇન્ટરફેસની રાઉટ સાથે સરખામણી કરે છે, અસંગતિ શોધે છે અને પેકેટ કાઢી નાખે છે, તેથી સહકર્મી સંપૂર્ણ નુકસાન જુએ છે જ્યારે બંને છેડા સ્વસ્થ ટનલનું જણાવે છે.

અરીસાની દિશાનો પણ એ જ આકાર છે: જ્યારે ક્લાયન્ટ ઓફિસ તરફ શરૂ કરે છે, ત્યારે એ જ કારણસર ઓફિસની બાજુએ જવાબો કાઢી નાખવામાં આવી શકે છે. માત્ર એક દિશામાં ચકાસાયેલો સુધારો સામાન્ય રીતે બીજી ટિકિટ તરીકે પાછો આવે છે.

કોઈપણ sysctl ને અડવા પહેલાં અમલમાં રહેલી મોડ સાબિત કરો

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

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

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

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

દરેક rp_filter મોડ ખરેખર શું સ્વીકારે છે

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

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

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

અસ્પષ્ટતા દૂર કરતો સૌથી નાનો ફેરફાર પસંદ કરો

ઢીલી મોડ અનુકૂળ સૌથી નાનો ફેરફાર છે, અને તે નિરુપદ્રવ સ્વિચ નહીં પણ કડકતામાં સાચો ઘટાડો છે. ટોપોલોજી પરવાનગી આપે ત્યારે સારો વિકલ્પ હોય છે: ઓવરલેપ દૂર કરો, અને અસ્પષ્ટતા અદૃશ્ય થાય છે.

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

તમે ગમે તે પથ પસંદ કરો, તેને જીવંત આદેશમાં નહીં પણ sysctl drop-in માં નોંધો. all અને default કી બંને સાથે સેટ કરો, જેથી ફરી જોડાવાથી કડક મોડ ચુપચાપ પાછી ન આવે.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

ઢીલી મોડ શું છોડે છે, અને ક્યાં

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

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

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