ખાલી VPN ટેબલ પોતે કંઈ અટકાવતું નથી

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

કંઈ તૂટ્યું નથી; નીતિ આધારિત રાઉટિંગ આ રીતે નિર્ધારિત છે.

ટેબલમાં કંઈ ન હોય ત્યારે શોધ ચાલુ રહે છે

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

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

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

ટર્મિનલ ક્રિયાઓ શોધ સમાપ્ત કરે છે

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

ખાલી ટેબલની શોધને બદલે VPN શોધ પછી ટર્મિનલ નિયમ આવી શકે છે. એ જ ચિહ્ન સાથે, 42 ટેબલના નિયમ પછી મૂકાયેલ prohibit ક્રિયા, જ્યારે એ ટેબલ કંઈ આપતું નથી ત્યારે શોધ સમાપ્ત કરે છે અને main ટેબલને બીજી તક આપવાને બદલે વહીવટી અસ્વીકાર પરત આપે છે. Unreachable અને blackhole પણ ટર્મિનલ છે, મોકલનાર માટે અલગ ભૂલ વર્તન સાથે.

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

વાસ્તવિક ચિહ્ન અને ઇન્ટરફેસ સાથે ચકાસો

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

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

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

બે નિષ્ફળતા સ્થિતિઓ, એક નહીં

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

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

નીતિને IPv6 પર અલગથી લાગુ કરો, અને મંજૂર કરેલા એન્ડપોઇન્ટ અપવાદોને ગર્ભિત નહીં પણ સ્પષ્ટ રાખો.