VPN રૂટ કે ફાયરવોલ નિયમ: પેકેટ કોણ ડ્રોપ કરે છે?

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

બે નિર્ણયો, એક પેકેટ, બે માલિકો

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

ફિલ્ટરિંગ અલગ છે. Linux હોસ્ટ પર netfilter હૂક્સ પેકેટ કોના માટે છે તેના આધારે ટ્રાફિકને વિભાજિત કરે છે: આઉટપુટ મશીન છોડે છે, ઇનપુટ તેના પર સમાપ્ત થાય છે, ફોરવર્ડ તેમાંથી પસાર થાય છે. જે ગેટવે VPN ક્લાયન્ટ સ્વીકારે છે અને તેમને LAN પર રૂટ કરે છે તેને ફોરવર્ડ માર્ગની જરૂર છે, અને તે જ તે સાંકળ છે જે મોટાભાગના ડિફોલ્ટ રૂપરેખાંકનો ખાલી છોડે છે.

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

શોધે ખરેખર શું પસંદ કર્યું તે વાંચો

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

ફિલ્ટરિંગ હૂક પર લાગુ થાય છે, રૂટ પર નહીં

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

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

ક્લાયન્ટ જે માર્ગ વાપરે છે તેમાંથી પ્રોબ મોકલો

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

દરેક ફેરફારને એવી જગ્યાએ મૂકો જ્યાં તે ફરીથી જોડાણ પછી ટકે

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

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

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