રાઉટરનું પોતાનું DNS VPN ટનલને કેમ છોડી જાય છે?

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

પેકેટ કેપ્ચર ખરેખર કયા પ્રવાહનું છે

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

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

વ્યવહારુ ચકાસણી એ છે કે બંને બાજુઓ એકસાથે જોવી. રાઉટર પર રિઝોલ્વરનું સોકેટ સૂચિબદ્ધ કરો, તેને સ્થાનિક રીતે પૂછો અને WAN ઇન્ટરફેસ કેપ્ચર કરો:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

નીતિ-માર્ગ બીજી ક્વેરી કેમ કદી જોતો નથી

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

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

pfSense રિઝોલ્વર પોતાનો અપસ્ટ્રીમ માર્ગ ક્યાં નક્કી કરે છે

pfSense આ વિભાજનને દૃશ્યમાન બનાવે છે. ક્લાયન્ટ ટ્રાફિક નીતિ-માર્ગ દ્વારા VPN ગેટવેમાંથી પસાર થઈ શકે છે, જ્યારે ફાયરવોલનો પોતાનો ટ્રાફિક LAN નિયમોને બદલે રિઝોલ્વરના આઉટગોઇંગ સેટિંગને અનુસરે છે. વેબ ઇન્ટરફેસમાં તે સેટિંગ Services > DNS Resolver > Outgoing Network Interfaces હેઠળ છે, અને તેનું મૂલ્ય એ ઇન્ટરફેસોની યાદી છે જે રિઝોલ્વર અપસ્ટ્રીમ ક્વેરી માટે વાપરી શકે છે.

ત્યાં ટનલ ઇન્ટરફેસનું નામ આપવું, અને ફક્ત તે જ ઇન્ટરફેસ, એ છે જે રાઉટરની પોતાની લુકઅપને ટનલ અનુસરવા મજબૂર કરે છે. ડિફૉલ્ટ પર છોડી દેવાય તો રિઝોલ્વર રૂટિંગ કોષ્ટકમાંથી એગ્રેસ પસંદ કરે છે, જે ડ્યુઅલ-WAN અથવા VPN હોસ્ટ પર ઘણી વાર WAN હોય છે.

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

સેટિંગ પહેલાં નિષ્ફળતાનું વર્તન પસંદ કરો

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

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

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

બંને માર્ગ ચકાસો અને પરિણામો અલગ રાખો

બ્રાઉઝર-આધારિત DNS કસોટી એક સાંકડા પ્રશ્નનો જવાબ આપે છે: તે કસોટીની પરિસ્થિતિમાં તે બ્રાઉઝરે કયા રિઝોલ્વર વાપર્યા. તે નેટવર્કના ઉપકરણોની યાદી બનાવતી નથી અને રાઉટરે પોતાના માટે બનાવેલી ક્વેરી જોઈ શકતી નથી. તેના આઉટપુટને ઑડિટ નહીં, એક ડેટા-બિંદુ તરીકે લો.

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

પછી ટનલ નીચે ઉતારો અને બંને ક્વેરી પુનરાવર્તિત કરો. નકારેલા જવાબોનો અર્થ છે કે રિઝોલ્વર નિષ્ફળતા પર બંધ થાય છે; સફળ જવાબ ફૉલબૅક રિઝોલ્વર અને તેણે વાપરેલા માર્ગ તરફ નિર્દેશ કરે છે. તેની સરખામણી તમે લખેલી નોંધ અને એ જ મિનિટમાં WAN ઇન્ટરફેસ પર લેવાયેલા કેપ્ચર સાથે કરો.

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