સ્ટેટલેસ VPN એજ ફાયરવોલ પર DNS જવાબ કેમ નિષ્ફળ જાય છે

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

બે વિનિમય એક જ વિનિમય નથી

ટ્યુપલ લખી લો અને ભૂલ સ્પષ્ટ થઈ જાય છે. વિનંતીનો ડેસ્ટિનેશન પોર્ટ જવાબનો સ્રોત પોર્ટ બની જાય છે, જે પોર્ટ 53 માટે ઇનબાઉન્ડ નિયમ ઉમેરતી વખતે મોટાભાગના લોકો જે કલ્પના કરે છે તેનાથી ઊલટું છે:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

સ્ટેટલેસ એજ વિરુદ્ધ સ્ટેટફુલ હોસ્ટ ફાયરવોલ

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

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

પરવાનગી પોર્ટ નંબરની નહીં, પ્રોટોકોલની આસપાસ બનાવો

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

પછી ખાતરી કરો કે માર્ગ પરનું કયું ઉત્પાદન ટ્રાફિક ખરેખર ફિલ્ટર કરે છે. દસ્તાવેજીકૃત IPv4 એજ વ્યાપ IPv6 નીતિ સ્થાપિત કરતું નથી, અને પ્રદાતાનો આંતરિક ટ્રાફિક કદાચ એ જ ફિલ્ટરમાંથી ક્યારેય પસાર થાય નહીં.

કોઈપણ સ્રોત પોર્ટ 53 ને મંજૂરી આપવી કેમ ઉકેલ નથી

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

જો રિઝોલ્વર તમે નિયંત્રિત કરો તે સેવા હોય, તો તેના સરનામાં સુધી મર્યાદિત કરવું પૂરતું છે. જો તે જાહેર રિઝોલ્વર હોય, તો તમે મંજૂર કરેલા સરનામાં સુધી મર્યાદિત કરો અને નિયમની ટિપ્પણીમાં તેનો ઉલ્લેખ કરો.

યોગ્ય સીમા પર, યોગ્ય દિશામાં ચકાસો

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

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