DNS නැවත යොමු කිරීමෙන් පසු dnsmasq විමසුම් VPN එකෙන් පිටවන්නේ ඇයි

LAN සේවාදායකයා තම VPN වෙත නිවැරදිව ළඟා වුවත් ඔහුගේ DNS විමසුම් වැරදි ඉහළ සබැඳියේ දිස් වේ. මෙය සාමාන්‍ය අර්ථයෙන් කාන්දුවක් නොවේ; රවුටරය විමසුම ඉදිරියට යැවීම නතර කර තමන්ම එයට පිළිතුරු දෙන විට සිදු වන දේ මෙයයි. අතුරු ඇල්ලීම ගමනාන්තය දේශීය සොකට් එකකට නැවත ලියයි, පසුව විසඳුම්කරු තමාගේම මූලාශ්‍ර ලිපිනය සහ තමාගේම මාර්ගගත කිරීමේ තීරණය සහිත දෙවන, සම්බන්ධයක් නැති සංවාදයක් විවෘත කරයි. සේවාදායක ප්‍රවාහයට යොදන ලද ලකුණු පළමු සංවාදය විස්තර කරන අතර දෙවැන්න ගැන කිසිවක් නොකියයි.

ලකුණ විමසුම සමඟ ගමන් නොකරයි

තැපැල් ලකුණු conntrack සටහනේ සහ පියාසර කරන තැපැලෙහි ජීවත් වේ. REDIRECT නියමයක් එම පියාසරය අවසන් කරයි: භාරය දේශීය සොකට් එකකට භාර දෙනු ලැබේ, සහ මුල් සටහන තම කටයුත්ත කර අවසන්. ඉන්පසු රවුටරයෙන් පිටවන දේ විසඳුම්කරු ක්‍රියාවලිය විසින් නිර්මාණය කළ නව සොකට් එකක් වන අතර එහි මූලාශ්‍රය රවුටරයේම ලිපිනයයි.

එබැවින් LAN සේවාදායකයාගේ ලිපිනය මත යතුරු ලියන ලද ප්‍රතිපත්ති මාර්ගය කිසිදා ඉහළ ප්‍රවාහ විමසුමට නොගැළපේ. නව සොකට් එක සේවාදායකයාට නොව dnsmasq ට අයත් වන අතර කර්නලය මාර්ගය රවුටරයේම රථවාහනය සඳහා ඇගයයි. මූලාශ්‍ර නීති, අතුරුමුහුණත් නීති සහ ලකුණු නීති සියල්ලම වෙනත් tuple එකක් දකිති. ලකුණ පැතිරෙන බව උපකල්පනය කිරීම මෙම සැකසුමේ වඩාත් පොදු වැරැද්ද වන අතර එය සේවාදායක පැත්තේ ග්‍රහණයක දී නොපෙනේ.

සංවාද දෙකම සැබවින්ම එක් නමක් සහ එක් වේලාවක් බෙදාගනී, ග්‍රහණයක් ඉක්මනින් බලන විට ඒවා එක් ප්‍රවාහයක් ලෙස පෙනීමට හේතුව එයයි.

කොහේදී ඉදිරියට යැවීම දේශීය විසඳුමක් බවට පත් වන්නේ

53 වරාය නැවත යොමු වේද, වෙනත් සත්කාරකයකට පරිවර්තනය වේද, නැතහොත් එලෙසම තබා ඇත්ද යන්න සොයා ගැනීමෙන් ආරම්භ කරන්න, මන්ද අවස්ථා තුන වෙනස් ලෙස හැසිරේ. දේශීය වරායකට නැවත යොමු කිරීම ඉදිරියට යැවීම අවසන් කරයි, නමුත් වෙනත් යන්ත්‍රයකට පරිවර්තනය තැපැල චලනයේ තබා සේවාදායකයාගේ tuple අර්ථවත් කර තබයි.

ප්‍රොටෝකෝල දෙකම බලන්න. 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 වරායේ නීති DNS HTTPS හෝ TLS හරහා කතා කරන යෙදුම් ගැන කිසිවක් නොකියයි. එම විමසුම් කිසිදා නැවත යොමු කිරීමට ළඟා නොවේ, එබැවින් 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 ද නැතහොත් වාසනාවන්ත පමණද යන්නයි.