DNS રીડાયરેક્ટ પછી dnsmasq ક્વેરીઓ VPNની બહાર કેમ નીકળી જાય છે

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

માર્ક ક્વેરી સાથે મુસાફરી કરતું નથી

પેકેટ માર્ક conntrack એન્ટ્રી પર અને ઉડતા પેકેટ પર રહે છે. એક REDIRECT નિયમ તે ઉડાન સમાપ્ત કરે છે: પેલોડ સ્થાનિક સોકેટને સોંપાય છે અને મૂળ એન્ટ્રીએ તેનું કામ કરી લીધું છે. પછી રાઉટરમાંથી જે નીકળે છે તે રિઝોલ્વર પ્રક્રિયા દ્વારા બનાવેલું નવું સોકેટ છે, જેનો સ્રોત રાઉટરનું પોતાનું સરનામું છે.

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

બંને વાતચીતો ખરેખર એક નામ અને એક સમય વહેંચે છે, અને એ જ કારણે કેપ્ચર ઝડપથી જોતી વખતે તે એક જ ફ્લો જેવી લાગે છે.

ક્યાં ફોરવર્ડિંગ સ્થાનિક રિઝોલ્યુશન બની જાય છે

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

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

રિઝોલ્વરને તેની પોતાની ઇગ્રેસ પોલિસી આપો

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

server=/corp.example/10.30.0.53@tun_work
log-queries

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

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

શેર કરેલી કેશ શું સાચવી શકતી નથી

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

કેશ કરેલો જવાબ પણ નવા માર્ગ વિશે પુરાવો નથી. જવાબ મેમરીમાંથી આવી શકે છે જ્યારે અપસ્ટ્રીમ રૂટ તૂટેલો રહે છે.

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

બીજી વાતચીત ચકાસો, પ્રથમ નહીં

તમે નિયંત્રિત કરો તેવા એક નામ સાથે પરીક્ષણ કરો અને બંને બાજુ જુઓ. ક્લાયન્ટ-સાઇડ કેપ્ચર સાબિત કરે છે કે ક્વેરીએ LAN છોડી દીધું; ફક્ત રાઉટર બાજુ જ સાબિત કરે છે કે તે પછી ક્યાં ગયું.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

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