શું હાર્ડવેર NAT ઓફલોડ તમારા VPN રાઉટિંગ નિયમો તોડે છે?

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

ઝડપવર્ધકને દોષ આપતા પહેલાં બે દાવાઓને અલગ કરવા યોગ્ય છે: કે એક નિયમ લાગુ થવાનું બંધ થયું, અને કે એક કાઉન્ટર અપડેટ થવાનું બંધ થયું. આ એક જ અવલોકન નથી.

ત્રણ અલગ ઝડપવર્ધન એકસાથે ભેળવી દેવાય છે

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

Linux ના flowtable એ સૌથી વધુ વાંચવા લાયક દસ્તાવેજીકૃત કિસ્સો છે, કારણ કે સ્થાપિત ફ્લોને ઝડપી માર્ગને સોંપી શકાય છે. પછી તેમનું હિસાબીકરણ અને સ્થિતિ સંચાલન ક્લાસિક ફોરવર્ડિંગથી અલગ પડે છે, અને તેથી જ કાઉન્ટરો વિચિત્ર દેખાવા લાગે છે.

ચલવાનું બંધ થયેલું કાઉન્ટર થોડું જ સાબિત કરે છે

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

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

ત્રણ શરતો નક્કી કરે છે કે ઓફલોડ નીતિ તોડે છે કે નહીં

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

તમે જે સંયોજન ચલાવો છો તેના માટે વેન્ડરનું દસ્તાવેજીકરણ વાંચો, સામાન્ય રીતે રાઉટર મોડેલ માટે નહીં. ફર્મવેર સંસ્કરણો આ જવાબો ચૂપચાપ બદલે છે.

નીતિની કસોટી કરો, થ્રુપુટની નહીં

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

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

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

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