Google Cloud နည်းပညာပံ့ပိုးမှုမှ ပျောက်ဆုံးနေသော DNS ပက်ကတ်များအကြောင်း သတင်းတစ်ပုဒ်

Google Blog Editor မှ Google Cloud Technical Solutions (TSE) အင်ဂျင်နီယာများသည် သင့်အကူအညီတောင်းဆိုမှုများကို မည်သို့ကိုင်တွယ်သည်ကို သင် တွေးဖူးပါသလား။ TSE နည်းပညာပံ့ပိုးကူညီမှုအင်ဂျင်နီယာများသည် အသုံးပြုသူ-အစီရင်ခံထားသော ပြဿနာများ၏ရင်းမြစ်များကို ဖော်ထုတ်ရန်နှင့် ပြုပြင်ရန်အတွက် တာဝန်ရှိပါသည်။ ဤပြဿနာများထဲမှ အချို့သည် ရိုးရှင်းသော်လည်း တစ်ခါတစ်ရံတွင် အင်ဂျင်နီယာများစွာ၏ အာရုံစူးစိုက်မှု လိုအပ်သော လက်မှတ်တစ်စောင်ကို တခါတရံ သင်တွေ့ခဲ့ရသည်။ ဤဆောင်းပါးတွင်၊ TSE ဝန်ထမ်းတစ်ဦးသည် သူ၏လတ်တလောအလေ့အကျင့်မှ အလွန်ခက်ခဲသောပြဿနာတစ်ခုအကြောင်း ကျွန်ုပ်တို့ကို ပြောပြလိမ့်မည်- DNS packet များ ပျောက်ဆုံးနေသည့် ကိစ္စ. ဤဇာတ်လမ်းတွင်၊ အင်ဂျင်နီယာများသည် အခြေအနေကို ဖြေရှင်းရန် စီမံခန့်ခွဲပုံနှင့် အမှားကိုပြင်စဉ်တွင် သင်ယူခဲ့သည့်အရာအသစ်များကို ကျွန်ုပ်တို့ မြင်တွေ့ရမည်ဖြစ်သည်။ ဤဇာတ်လမ်းသည် သင့်အား နက်ရှိုင်းစွာတွယ်ကပ်နေသော ချို့ယွင်းချက်တစ်ခုအကြောင်း အသိပညာပေးရုံသာမက Google Cloud တွင် ပံ့ပိုးမှုလက်မှတ်တစ်ခုတင်သွင်းခြင်းဆိုင်ရာ လုပ်ငန်းစဉ်များကိုပါ ထိုးထွင်းသိမြင်စေမည်ဟု မျှော်လင့်ပါသည်။

ပြဿနာဖြေရှင်းခြင်းသည် သိပ္ပံပညာနှင့် အနုပညာတစ်ရပ်ဖြစ်သည်။ ၎င်းသည် စနစ်၏ စံမဟုတ်သော အပြုအမူအတွက် အကြောင်းပြချက်နှင့် ပတ်သက်သော အယူအဆတစ်ခုကို တည်ဆောက်ခြင်းဖြင့် စတင်သည်၊ ထို့နောက် ၎င်းအား ကြံ့ခိုင်မှုအတွက် စမ်းသပ်သည်။ သို့သော်၊ ကျွန်ုပ်တို့သည် အယူအဆတစ်ခုကို မရေးဆွဲမီ၊ ကျွန်ုပ်တို့သည် ပြဿနာကို ရှင်းလင်းပြတ်သားစွာ သတ်မှတ်ပြီး တိကျစွာ ပုံဖော်ရပါမည်။ မေးခွန်းက မရေရာတဲ့အသံဖြစ်နေရင် အရာအားလုံးကို သေချာခွဲခြမ်းစိတ်ဖြာရပါလိမ့်မယ်။ ဤသည်မှာ ပြဿနာဖြေရှင်းခြင်း၏ "အနုပညာ" ဖြစ်သည်။

Google Cloud အောက်တွင်၊ Google Cloud သည် ၎င်း၏အသုံးပြုသူများ၏ကိုယ်ရေးကိုယ်တာလုံခြုံမှုကို အာမခံချက်ပေးရန် အကောင်းဆုံးကြိုးစားနေသောကြောင့် အဆိုပါလုပ်ငန်းစဉ်များသည် အဆပိုရှုပ်ထွေးလာပါသည်။ ထို့အတွက်ကြောင့် TSE အင်ဂျင်နီယာများသည် သင့်စနစ်များကို တည်းဖြတ်ရန် ဝင်ရောက်ခွင့်မရှိသလို၊ အသုံးပြုသူများကဲ့သို့ ကျယ်ပြန့်သော ဖွဲ့စည်းမှုပုံစံများကို ကြည့်ရှုနိုင်စွမ်းလည်း မရှိပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့၏ယူဆချက်မှန်သမျှကို စမ်းသပ်ရန်၊ ကျွန်ုပ်တို့ (အင်ဂျင်နီယာများ) သည် စနစ်ကို အမြန်မွမ်းမံပြင်ဆင်နိုင်မည်မဟုတ်ပေ။

အချို့သောအသုံးပြုသူများသည် ကားဝန်ဆောင်မှုရှိ စက်ပြင်များကဲ့သို့ အရာအားလုံးကို ပြုပြင်ပေးမည်ဟု ယုံကြည်ကြပြီး virtual machine ၏ id ကို ရိုးရိုးရှင်းရှင်း ပို့ပေးမည်ဟု ယုံကြည်ကြပြီး လက်တွေ့တွင် လုပ်ငန်းစဉ်သည် စကားဝိုင်းပုံစံဖြင့် လုပ်ဆောင်သည်- အချက်အလက်စုဆောင်းခြင်း၊ ဖွဲ့စည်းခြင်းနှင့် အတည်ပြုခြင်း (သို့မဟုတ် ငြင်းဆိုခြင်း) အယူအဆများ၊ အဆုံးတွင်၊ ဆုံးဖြတ်ချက်ပြဿနာများသည် သုံးစွဲသူနှင့် ဆက်သွယ်မှုအပေါ် အခြေခံသည်။

မေးခွန်းထုတ်စရာ ပြဿနာ

ဒီနေ့တော့ ဇာတ်လမ်းကောင်းလေးတစ်ပုဒ်ရှိပါတယ်။ အဆိုပြုထားသောကိစ္စ၏ အောင်မြင်စွာဖြေရှင်းခြင်းအတွက် အကြောင်းရင်းတစ်ခုမှာ ပြဿနာ၏ အလွန်အသေးစိတ်ပြီး တိကျသောဖော်ပြချက်ဖြစ်သည်။ အောက်တွင် ပထမလက်မှတ်မိတ္တူကို သင်တွေ့နိုင်သည် (လျှို့ဝှက်အချက်အလက်များကို ဖုံးကွယ်ရန်အတွက် တည်းဖြတ်ထားသည်)

ဤမက်ဆေ့ချ်တွင် ကျွန်ုပ်တို့အတွက် အသုံးဝင်သော အချက်အလက်များစွာ ပါဝင်သည်-

• သတ်မှတ်ထားသော VM ကို သတ်မှတ်ထားသည်။
• ပြဿနာကိုယ်တိုင်ကညွှန်ပြသည် - DNS အလုပ်မလုပ်ပါ။
• ပြဿနာက သူ့အလိုလိုပေါ်လာသည့်နေရာတွင် ညွှန်ပြသည် - VM နှင့် container
• ပြဿနာကို ဖော်ထုတ်ရန် အသုံးပြုသူ လုပ်ဆောင်ခဲ့သော အဆင့်များကို ဖော်ပြထားပါသည်။

တောင်းဆိုချက်အား "P1: အရေးပါသောသက်ရောက်မှု - ထုတ်လုပ်မှုတွင် အသုံးမပြုနိုင်သောဝန်ဆောင်မှု" အဖြစ် မှတ်ပုံတင်ထားပြီး၊ ဆိုလိုသည်မှာ "နေကိုလိုက်နာပါ" အစီအစဉ်အရ အခြေအနေကို 24/7 စဉ်ဆက်မပြတ် စောင့်ကြည့်လေ့လာနိုင်သည် (အကြောင်းပိုမိုဖတ်ရှုနိုင်ပါသည်။ အသုံးပြုသူတောင်းဆိုမှုများ၏ဦးစားပေး) နည်းပညာပံ့ပိုးကူညီမှုအဖွဲ့တစ်ခုမှ အခြားအချိန်ဇုန်တစ်ခုစီသို့ ပြောင်းရွှေ့ခြင်းဖြင့်၊ အမှန်တော့၊ ပြဿနာက ဇူးရစ်မှာရှိတဲ့ ကျွန်တော်တို့အဖွဲ့ကို ရောက်တဲ့အချိန်မှာ၊ အဲဒါက ကမ္ဘာကို လှည့်ပတ်နေပြီ။ ထိုအချိန်တွင်၊ အသုံးပြုသူသည် လျော့ပါးသက်သာရေးအစီအမံများကို လုပ်ဆောင်ခဲ့သော်လည်း မူလအကြောင်းအရင်းကို မဖော်ထုတ်ရသေးသောကြောင့် ထုတ်လုပ်မှုအခြေအနေအား ထပ်ခါတလဲလဲကြောက်ရွံ့နေခဲ့သည်။

လက်မှတ်သည် ဇူးရစ်မြို့သို့ ရောက်သောအခါတွင်၊ ကျွန်ုပ်တို့တွင် အောက်ဖော်ပြပါ အချက်အလက်များ ရှိနေပြီဖြစ်သည်။

• အကြောင်းအရာ /etc/hosts
• အကြောင်းအရာ /etc/resolv.conf
• ကောက်ချက် iptables-save
• အဖွဲ့ဖြင့် စုစည်းထားသည်။ ngrep pcap ဖိုင်

ဤဒေတာဖြင့်၊ ကျွန်ုပ်တို့သည် "စုံစမ်းစစ်ဆေးခြင်း" နှင့် ပြဿနာဖြေရှင်းခြင်းအဆင့်ကို စတင်ရန် အသင့်ဖြစ်နေပါပြီ။

ကျွန်ုပ်တို့၏ပထမခြေလှမ်းများ

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် မက်တာဒေတာဆာဗာ၏ မှတ်တမ်းများနှင့် အခြေအနေကို စစ်ဆေးပြီး ၎င်းသည် မှန်ကန်စွာ အလုပ်လုပ်ကြောင်း သေချာစေပါသည်။ မက်တာဒေတာဆာဗာသည် IP လိပ်စာ 169.254.169.254 ကို တုံ့ပြန်ပြီး အခြားအရာများထဲတွင် ဒိုမိန်းအမည်များကို ထိန်းချုပ်ရန် တာဝန်ရှိသည်။ Firewall သည် VM နှင့် မှန်ကန်စွာ အလုပ်လုပ်ကြောင်းနှင့် packets များကို ပိတ်ဆို့ထားခြင်း မရှိကြောင်း၊

၎င်းသည် ထူးဆန်းသောပြဿနာတစ်မျိုးဖြစ်သည်- nmap စစ်ဆေးမှုသည် UDP ပက်ကတ်များ ဆုံးရှုံးခြင်းနှင့်ပတ်သက်၍ ကျွန်ုပ်တို့၏အဓိကယူဆချက်အား ငြင်းဆိုထားသောကြောင့် ၎င်းတို့ကို စစ်ဆေးရန် နောက်ထပ်ရွေးချယ်စရာများနှင့် နည်းလမ်းများစွာကို ကျွန်ုပ်တို့ စိတ်ပိုင်းဆိုင်ရာတွင် ရှာဖွေတွေ့ရှိခဲ့သည်-

• ပက်ကေ့ချ်များကို ရွေးထုတ်ပါလား။ => iptables စည်းမျဉ်းများကိုစစ်ဆေးပါ။
• အရမ်းငယ်တယ်မဟုတ်လား သမဂ္ဂ? => အထွက်ကိုစစ်ဆေးပါ။ ip a show
• ပြဿနာက UDP packets သို့မဟုတ် TCP ကိုသာ သက်ရောက်မှုရှိပါသလား။ => မောင်းထွက်သွား dig +tcp
• တူးထုတ်ပေးသော ပက်ကေ့ခ်ျများကို ပြန်ပေးပါသလား။ => မောင်းထွက်သွား tcpdump
• libdn များ မှန်ကန်စွာ အလုပ်လုပ်ပါသလား။ => မောင်းထွက်သွား strace လမ်းကြောင်းနှစ်ခုလုံးတွင် packets များ၏ကူးစက်မှုကိုစစ်ဆေးရန်

ဤတွင် ကျွန်ုပ်တို့သည် ပြဿနာများကို တိုက်ရိုက်ဖြေရှင်းရန် အသုံးပြုသူကို ဖုန်းခေါ်ဆိုရန် ဆုံးဖြတ်လိုက်ပါသည်။

ဖုန်းခေါ်ဆိုမှုအတွင်း ကျွန်ုပ်တို့သည် အရာများစွာကို စစ်ဆေးနိုင်သည်-

• စစ်ဆေးမှုများစွာပြီးနောက် ကျွန်ုပ်တို့သည် iptables စည်းမျဉ်းများကို အကြောင်းပြချက်စာရင်းမှ ဖယ်ထုတ်ထားသည်။
• ကျွန်ုပ်တို့သည် network interfaces များနှင့် routing tables များကို စစ်ဆေးပြီး MTU မှန်ကန်ကြောင်း နှစ်ဆစစ်ဆေးပါ။
• အဲဒါကို ကျနော်တို့ ရှာဖွေတွေ့ရှိတယ်။ dig +tcp google.com (TCP) လုပ်သင့်သည် ၊ သို့သော်၊ dig google.com (UDP) အလုပ်မလုပ်ပါ။
• မောင်းထုတ်လိုက်ရသည်။ tcpdump အလုပ်လုပ်နေတုန်းပဲ။ digUDP ပက်ကေ့ခ်ျများကို ပြန်ပို့သည်ကို ကျွန်ုပ်တို့ တွေ့ရှိရသည်။
• ငါတို့မောင်းထွက်သွားတယ်။ strace dig google.com မည်ကဲ့သို့ မှန်ကန်စွာ တူးယူထားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ sendmsg() и recvms()သို့သော် ဒုတိယတစ်ခုသည် အချိန်ကုန်သွားသဖြင့် ပြတ်တောက်သွားသည်။

ကံမကောင်းစွာပဲ၊ ဆိုင်းငံ့မှုအဆုံးရောက်လာပြီး ပြဿနာကို နောက်အချိန်ဇုန်သို့ တိုးခိုင်းလိုက်ရသည်။ သို့သော် အဆိုပါတောင်းဆိုချက်သည် ကျွန်ုပ်တို့၏အဖွဲ့ကို စိတ်ဝင်စားစေခဲ့ပြီး လုပ်ဖော်ကိုင်ဖက်တစ်ဦးက ကြမ်းတမ်းသော Python module ကိုအသုံးပြု၍ ကနဦး DNS ပက်ကေ့ဂျ်ကို ဖန်တီးရန် အကြံပြုထားသည်။

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

ဤအပိုင်းအစသည် DNS ပက်ကတ်ကို ဖန်တီးပြီး တောင်းဆိုချက်ကို မက်တာဒေတာဆာဗာသို့ ပေးပို့သည်။

အသုံးပြုသူသည် ကုဒ်ကိုလုပ်ဆောင်သည်၊ DNS တုံ့ပြန်မှုကို ပြန်ပေးမည်ဖြစ်ပြီး၊ အပလီကေးရှင်းမှ ၎င်းကို လက်ခံရရှိကာ ကွန်ရက်အဆင့်တွင် ပြဿနာမရှိကြောင်း အတည်ပြုသည်။

အခြား "ကမ္ဘာလှည့်ခရီး" ပြီးနောက်၊ တောင်းဆိုချက်သည် ကျွန်ုပ်တို့၏အဖွဲ့ထံ ပြန်လည်ရောက်ရှိပြီး တောင်းဆိုချက်သည် တစ်နေရာမှ တစ်နေရာသို့ လှည့်ပတ်နေခြင်းကို ရပ်သွားပါက အသုံးပြုသူအတွက် ပိုမိုအဆင်ပြေမည်ဟု ထင်မြင်ပြီး ၎င်းကို ကျွန်ုပ်ကိုယ်တိုင် အပြည့်အဝလွှဲပြောင်းပေးပါသည်။

ဤအတောအတွင်း၊ အသုံးပြုသူသည် စနစ်ပုံ၏လျှပ်တစ်ပြက်ပုံတစ်ပုံကို ပေးဆောင်ရန် ကြင်နာစွာသဘောတူပါသည်။ ဤသည်မှာ သတင်းကောင်းဖြစ်သည်- စနစ်အား ကိုယ်တိုင်စမ်းသပ်နိုင်မှုသည် ပြဿနာဖြေရှင်းခြင်းကို ပိုမိုမြန်ဆန်စေသည်၊ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်သည် အသုံးပြုသူကို အမိန့်ပေးခိုင်းရန်၊ ရလဒ်များကို ပေးပို့ပြီး ၎င်းတို့ကို ခွဲခြမ်းစိတ်ဖြာရန် မလိုအပ်တော့သောကြောင့်၊ ကျွန်ုပ်သည် အရာအားလုံးကို ကိုယ်တိုင်လုပ်ဆောင်နိုင်ပါသည်။

ငါ့လုပ်ဖော်ကိုင်ဖက်တွေက ငါ့ကို နည်းနည်းလေးတောင် မနာလိုဖြစ်နေပြီ။ နေ့လယ်စာစားချိန်၌ ကျွန်ုပ်တို့သည် ပြောင်းလဲခြင်းအကြောင်း ဆွေးနွေးကြသော်လည်း အဘယ်အရာဖြစ်ပျက်နေသည်ကို မည်သူမျှ မသိကြပေ။ ကံကောင်းထောက်မစွာ၊ အသုံးပြုသူကိုယ်တိုင်က အကျိုးဆက်များကို လျော့ပါးသက်သာစေရန် အစီအမံများကို လုပ်ဆောင်ထားပြီးဖြစ်ပြီး အလျင်စလိုမဖြစ်သောကြောင့် ကျွန်ုပ်တို့တွင် ပြဿနာကို ခွဲခြမ်းစိပ်ဖြာရန် အချိန်ရှိသည်။ ကျွန်ုပ်တို့တွင် ပုံတစ်ပုံရှိသောကြောင့် ကျွန်ုပ်တို့စိတ်ပါဝင်စားသည့် မည်သည့်စမ်းသပ်မှုများကိုမဆို လုပ်ဆောင်နိုင်ပါသည်။ မိုက်တယ်!

နောက်သို့ ခြေတစ်လှမ်းဆုတ်သည်။

စနစ်အင်ဂျင်နီယာရာထူးများအတွက် ရေပန်းအစားဆုံး အင်တာဗျူးမေးခွန်းများထဲမှတစ်ခုမှာ- "သင် Ping လုပ်တဲ့အခါ ဘာဖြစ်သွားမလဲ။ www.google.com? ကိုယ်စားလှယ်လောင်းသည် shell မှ user space ၊ system kernel ၊ ထို့နောက် network သို့အရာအားလုံးကိုဖော်ပြရန်လိုအပ်သောကြောင့်မေးခွန်းသည်အလွန်ကောင်းသည်။ ပြုံးမိတယ် တခါတရံ အင်တာဗျူးမေးခွန်းတွေက လက်တွေ့ဘဝမှာ အသုံးဝင်ပါတယ်...

ဒီ HR မေးခွန်းကို လက်ရှိပြဿနာနဲ့ အသုံးချဖို့ ဆုံးဖြတ်လိုက်ပါတယ်။ အကြမ်းဖျင်းအားဖြင့်၊ သင် DNS အမည်တစ်ခုကို ဆုံးဖြတ်ရန် ကြိုးစားသောအခါတွင် အောက်ပါအတိုင်း ဖြစ်သွားသည်-

1. အပလီကေးရှင်းသည် libdns ကဲ့သို့သော စနစ်စာကြည့်တိုက်ကို ခေါ်သည်။
2. libdns သည် မည်သည့် DNS ဆာဗာကို ဆက်သွယ်သင့်သည် (ဤပုံတွင် 169.254.169.254၊ မက်တာဒေတာဆာဗာဖြစ်သည်)
3. libdns သည် UDP socket (SOKET_DGRAM) ဖန်တီးရန် စနစ်ခေါ်ဆိုမှုများကို အသုံးပြုပြီး လမ်းကြောင်းနှစ်ခုစလုံးတွင် DNS query တစ်ခုဖြင့် UDP ထုပ်ပိုးများကို ပေးပို့ပါ
4. sysctl interface မှတဆင့် သင်သည် kernel အဆင့်တွင် UDP stack ကို configure လုပ်နိုင်ပါသည်။
5. kernel သည် network interface မှတဆင့် network မှတဆင့် packet များကို ပို့လွှတ်ရန် hardware နှင့် အပြန်အလှန် တုံ့ပြန်ပါသည်။
6. hypervisor သည် packet ကို ဖမ်းပြီး ၎င်းနှင့် ထိတွေ့သောအခါ metadata ဆာဗာသို့ ပို့လွှတ်သည်။
7. ၎င်း၏ မှော်ပညာဖြင့် မက်တာဒေတာဆာဗာသည် DNS အမည်ကို ဆုံးဖြတ်ပြီး တူညီသောနည်းလမ်းကို အသုံးပြု၍ တုံ့ပြန်မှုကို ပြန်ပေးသည်။

ကျွန်ုပ်တို့ ထည့်သွင်းစဉ်းစားထားပြီးဖြစ်သည့် အယူအဆများကို ကျွန်ုပ်အား သတိပေးပါရစေ။

ယူဆချက်- ကျိုးပဲ့နေသော စာကြည့်တိုက်များ

• စမ်းသပ်မှု 1- စနစ်တွင် ခြေရာခံပြေးပါ၊ မှန်ကန်သော စနစ်ခေါ်ဆိုမှုများကို တူးပါဟု စစ်ဆေးပါ။
• ရလဒ်- စနစ်မှန်ကန်သောခေါ်ဆိုမှုများကို ခေါ်သည်။
• စမ်းသပ်မှု 2- srapy ကို အသုံးပြု၍ စနစ်စာကြည့်တိုက်များကို ကျော်ဖြတ်ကာ နာမည်များကို ဆုံးဖြတ်နိုင်မလား။
• ရလဒ်- ငါတို့လုပ်နိုင်တယ်။
• စမ်းသပ်မှု 3- libdns ပက်ကေ့ဂျ်နှင့် md5sum စာကြည့်တိုက်ဖိုင်များတွင် rpm –V ကိုဖွင့်ပါ။
• ရလဒ်- စာကြည့်တိုက်ကုဒ်သည် အလုပ်လုပ်သည့်လည်ပတ်မှုစနစ်ရှိ ကုဒ်များနှင့် လုံးဝတူညီပါသည်။
• စမ်းသပ်မှု 4- ဤအပြုအမူမပါဘဲ VM တွင် အသုံးပြုသူ၏ အမြစ်စနစ်ရုပ်ပုံကို တပ်ဆင်ပါ၊ chroot ကိုဖွင့်ပါ၊ DNS အလုပ်လုပ်ခြင်းရှိမရှိ ကြည့်ရှုပါ။
• ရလဒ်- DNS မှန်ကန်စွာ အလုပ်လုပ်ပါသည်။

စစ်ဆေးမှုများအပေါ်အခြေခံ၍ နိဂုံးချုပ် ပြဿနာက စာကြည့်တိုက်တွေမှာ မဟုတ်ပါဘူး။

ယူဆချက်- DNS ဆက်တင်များတွင် အမှားအယွင်းတစ်ခုရှိသည်။

• စမ်းသပ်မှု 1- tcpdump ကိုစစ်ဆေးပြီး တူးပြီးနောက် DNS packet များကို ပေးပို့ပြီး မှန်ကန်စွာ ပြန်ပို့ခြင်းရှိမရှိ စစ်ဆေးပါ။
• ရလဒ်- အထုပ်များကို မှန်ကန်စွာ ပို့လွှတ်ပါသည်။
• စမ်းသပ်မှု 2- ဆာဗာပေါ်တွင် နှစ်ချက်စစ်ဆေးပါ။ /etc/nsswitch.conf и /etc/resolv.conf
• ရလဒ်- အားလုံးမှန်ပါတယ်။

စစ်ဆေးမှုများအပေါ်အခြေခံ၍ နိဂုံးချုပ် ပြဿနာက DNS configuration နဲ့ မဟုတ်ပါဘူး။

ယူဆချက်- အူတိုင် ပျက်စီးသွားသည်။

• စမ်းသပ်ခြင်း- kernel အသစ်ကို ထည့်သွင်းပါ၊ လက်မှတ်စစ်ပါ၊ ပြန်လည်စတင်ပါ။
• ရလဒ်- အလားတူအပြုအမူ

စစ်ဆေးမှုများအပေါ်အခြေခံ၍ နိဂုံးချုပ် kernel မပျက်စီးပါ။

ယူဆချက်- အသုံးပြုသူကွန်ရက်၏ မမှန်ကန်သောအပြုအမူ (သို့မဟုတ် hypervisor ကွန်ရက်ကြားခံ)

• စမ်းသပ်မှု 1- သင်၏ firewall ဆက်တင်များကို စစ်ဆေးပါ။
• ရလဒ်- firewall သည် host နှင့် GCP နှစ်ခုလုံးတွင် DNS packet များကိုဖြတ်သန်းသည်။
• စမ်းသပ်မှု 2- အသွားအလာကို ကြားဖြတ်ပြီး ပို့လွှတ်မှုနှင့် DNS တောင်းဆိုမှုများ၏ မှန်ကန်မှုကို စောင့်ကြည့်ပါ။
• ရလဒ်- tcpdump သည် host သည် return packets ကို လက်ခံရရှိကြောင်း အတည်ပြုသည်။

စစ်ဆေးမှုများအပေါ်အခြေခံ၍ နိဂုံးချုပ် ပြဿနာက network ထဲမှာမဟုတ်ဘူး။

ယူဆချက်- မက်တာဒေတာဆာဗာ အလုပ်မလုပ်ပါ။

• စမ်းသပ်မှု 1- ကွဲလွဲချက်များရှိမရှိအတွက် မက်တာဒေတာဆာဗာမှတ်တမ်းများကို စစ်ဆေးပါ။
• ရလဒ်- မှတ်တမ်းများတွင် ကွဲလွဲချက်များမရှိပါ။
• စမ်းသပ်မှု 2- မက်တာဒေတာဆာဗာကို ကျော်ဖြတ်ပါ။ dig @8.8.8.8
• ရလဒ်- မက်တာဒေတာဆာဗာကို အသုံးမပြုဘဲ ပြတ်သားမှု ပျက်သွားသည်။

စစ်ဆေးမှုများအပေါ်အခြေခံ၍ နိဂုံးချုပ် ပြဿနာက မက်တာဒေတာဆာဗာနဲ့ မဟုတ်ပါဘူး။

အောက်ဆုံးလိုင်း: ကျွန်ုပ်တို့မှလွဲ၍ စနစ်ခွဲအားလုံးကို စမ်းသပ်ခဲ့သည်။ runtime ဆက်တင်များ။

Kernel Runtime ဆက်တင်များထဲသို့ ဝင်ရောက်ပါ။

kernel execution environment ကို configure လုပ်ရန်၊ command line options (grub) သို့မဟုတ် sysctl interface ကို သုံးနိုင်သည်။ ဝင်ကြည့်လိုက်တယ်။ /etc/sysctl.conf တွေးကြည့်ရုံနဲ့ စိတ်ကြိုက်ဆက်တင်များစွာကို ရှာဖွေတွေ့ရှိခဲ့တယ်။ တစ်စုံတစ်ခုကို ဖမ်းမိသွားသလို ခံစားရပြီး တောင်ဆက်တင်များနှင့်အတူ ကျန်ရှိသော ကွန်ရက်မဟုတ်သော သို့မဟုတ် tcp မဟုတ်သော ဆက်တင်များအားလုံးကို စွန့်ပစ်လိုက်သည် net.core. ထို့နောက် ကျွန်ုပ်သည် VM ရှိ လက်ခံသူခွင့်ပြုချက်များရှိရာသို့ သွားကာ ကျိုးနေသော VM ဖြင့် ဆက်တင်များကို တစ်ခုပြီးတစ်ခု စတင်အသုံးပြုကာ တရားခံကို ရှာမတွေ့မချင်း၊

net.core.rmem_default = 2147483647

ဤတွင်၊ ၎င်းသည် DNS-ဖောက်ဖျက်သည့်ဖွဲ့စည်းမှုတစ်ခုဖြစ်သည်။ လူသတ်လက်နက်ကို တွေ့ခဲ့တယ်။ ဒါပေမယ့် ဘာကြောင့် ဒီလိုဖြစ်နေတာလဲ။ စေ့ဆော်မှုတစ်ခု လိုအပ်နေသေးသည်။

အခြေခံ DNS ပက်ကက်ကြားခံ အရွယ်အစားကို တစ်ဆင့်ချင်း ပြင်ဆင်သတ်မှတ်ထားသည်။ net.core.rmem_default. ပုံမှန်တန်ဖိုးသည် 200KiB ဝန်းကျင်တွင်ရှိပြီး သင့်ဆာဗာသည် DNS ပက်ကေ့ခ်ျများစွာကို လက်ခံရရှိပါက၊ ကြားခံအရွယ်အစားကို တိုးမြှင့်လိုပေမည်။ အကယ်၍ ပက်ကက်အသစ်တစ်ခုရောက်လာသောအခါတွင် ကြားခံပြည့်နေပါက၊ ဥပမာ၊ အပလီကေးရှင်းသည် ၎င်းကိုလုံလောက်အောင်မလုပ်ဆောင်နိုင်သောကြောင့်၊ သင်သည် packet များစတင်ဆုံးရှုံးလိမ့်မည်။ DNS ပက်ကေ့ခ်ျများမှတဆင့် မက်ထရစ်များကို စုဆောင်းရန်အတွက် အပလီကေးရှင်းကို အသုံးပြုနေသောကြောင့် ကျွန်ုပ်တို့၏ဖောက်သည်သည် ဒေတာဆုံးရှုံးမှုကို ကြောက်သောကြောင့် ကြားခံအရွယ်အစားကို မှန်ကန်စွာ တိုးမြှင့်ခဲ့သည်။ သူသတ်မှတ်ထားသောတန်ဖိုးသည် အများဆုံးဖြစ်နိုင်သည်- 231-1 (231 ဟုသတ်မှတ်ပါက၊ kernel သည် "INVALID ARGUMENT" သို့ပြန်သွားလိမ့်မည်)။

nmap နှင့် scapy သည် အဘယ်ကြောင့် မှန်ကန်စွာ အလုပ်လုပ်သည်ကို ကျွန်ုပ် ရုတ်တရက် သဘောပေါက်လိုက်သည် ၊ ၎င်းတို့သည် အကြမ်းထည်များကို အသုံးပြုနေပါသည်။ Raw socket များသည် ပုံမှန် socket များနှင့် ကွဲပြားသည်- ၎င်းတို့သည် iptables များကို ကျော်ဖြတ်ကာ buffered မဟုတ်ပါ။

သို့သော် "ကြားခံအလွန်ကြီးသည်" သည်အဘယ်ကြောင့်ပြဿနာများဖြစ်စေသနည်း။ ရည်ရွယ်ထားသလို အလုပ်မဖြစ်ဘူးဆိုတာ ရှင်းပါတယ်။

ဤအချိန်တွင် ကျွန်ုပ်သည် kernels အများအပြားနှင့် ဖြန့်ဝေမှုများစွာတွင် ပြဿနာကို ပြန်လည်ဖန်တီးနိုင်ခဲ့ပါသည်။ 3.x kernel တွင် ပြဿနာပေါ်လာပြီး ယခု 5.x kernel တွင်လည်း ပေါ်လာပါသည်။

အမှန်တကယ်တော့ စတင်လိုက်ပါပြီ။

sysctl -w net.core.rmem_default=$((2**31-1))

DNS အလုပ်မလုပ်တော့ပါ။

ရိုးရှင်းသော binary ရှာဖွေမှု algorithm မှတဆင့် အလုပ်လုပ်သော တန်ဖိုးများကို စတင်ရှာဖွေခဲ့ပြီး စနစ်သည် 2147481343 နှင့် အလုပ်လုပ်ကြောင်း တွေ့ရှိခဲ့သော်လည်း ဤနံပါတ်သည် ကျွန်ုပ်အတွက် အဓိပ္ပါယ်မဲ့သော ဂဏန်းများဖြစ်သည်။ ဖောက်သည်အား ဤနံပါတ်ကို စမ်းကြည့်ရန် ကျွန်ုပ်အကြံပြုခဲ့ပြီး၊ စနစ်သည် google.com နှင့် အလုပ်လုပ်ကြောင်း ပြန်ပြောသော်လည်း အခြားဒိုမိန်းများနှင့် မှားယွင်းနေသေးသောကြောင့် ကျွန်ုပ်၏ စုံစမ်းစစ်ဆေးမှုကို ဆက်လက်လုပ်ဆောင်ခဲ့ပါသည်။

တပ်ဆင်ပြီးပါပြီ။ dropwatchအစောပိုင်းတွင် အသုံးပြုသင့်သည့် ကိရိယာတစ်ခု- ၎င်းသည် kernel တွင် ပက်ကတ်တစ်ခု ပြီးဆုံးသည့်နေရာကို အတိအကျပြသသည်။ တရားခံက လုပ်ဆောင်ချက် udp_queue_rcv_skb. ကျွန်ုပ်သည် kernel ရင်းမြစ်များကို ဒေါင်းလုဒ်လုပ်ပြီး အနည်းငယ်ထပ်ထည့်ပါသည်။ လုပ်ဆောင်ချက်များကို printk ပက်ကေ့ချ် အတိအကျ ဘယ်မှာ အဆုံးသတ်သည်ကို ခြေရာခံရန်။ အခြေအနေမှန်ကို အမြန်တွေ့ခဲ့တယ်။ if၊ အချိန်အတော်ကြာအောင် ငေးကြည့်နေမိသည် ၊ အကြောင်းမှာ၊ အရာအားလုံးသည် နောက်ဆုံးတွင် တစ်ပုံတစ်ပုံအဖြစ်သို့ ရောက်ရှိသွားသောကြောင့်ဖြစ်သည်- 231-1၊ အဓိပ္ပါယ်မဲ့နံပါတ်၊ အလုပ်မလုပ်သောဒိုမိန်း... ၎င်းသည် ကုဒ်အပိုင်းအစတစ်ခုဖြစ်သည်။ __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

ကျေးဇူးပြု. သတိပြုပါ:

• rmem int အမျိုးအစားဖြစ်သည်။
• size အမျိုးအစား u16 (လက်မှတ်မထိုးထားသော ဆယ့်ခြောက်ဘစ် int) ဖြစ်ပြီး ပက်ကတ်အရွယ်အစားကို သိမ်းဆည်းထားသည်။
• sk->sk_rcybuf int သည် အမျိုးအစားဖြစ်ပြီး အဓိပ္ပါယ်သတ်မှတ်ချက်အရ အတွင်းရှိတန်ဖိုးနှင့်ညီမျှသော buffer အရွယ်အစားကို သိမ်းဆည်းထားသည်။ net.core.rmem_default

ရသောအခါ sk_rcvbuf 231 သို့ချဉ်းကပ်သည်၊ ပက်ကတ်အရွယ်အစားကို နိဂုံးချုပ်ခြင်းဖြင့် ရလဒ်ထွက်ပေါ်နိုင်သည်။ ကိန်းပြည့်လျှံသည်။. ၎င်းသည် int တစ်ခုဖြစ်သောကြောင့်၊ ၎င်း၏တန်ဖိုးသည် အနုတ်လက္ခဏာဖြစ်လာသည်၊ ထို့ကြောင့် ၎င်းသည် false ဖြစ်သင့်သောအခါ အခြေအနေသည် အမှန်ဖြစ်လာသည် (ဤအကြောင်းပိုမိုဖတ်ရှုနိုင်သည် link ကို).

အမှားအယွင်းကို အသေးအဖွဲနည်းဖြင့် ပြင်နိုင်သည်- ကာစ်လုပ်ပါ။ unsigned int. ကျွန်တော် ပြုပြင်မှုကို အသုံးချပြီး စနစ်ကို ပြန်လည်စတင်လိုက်သည်နှင့် DNS ပြန်အလုပ်လုပ်ပါသည်။

အောင်ပွဲအရသာ

ကျွန်ုပ်တွေ့ရှိချက်များကို ဖောက်သည်ထံ ပေးပို့ပြီး ပေးပို့ခဲ့ပါသည်။ LKML kernel patch ။ ကျွန်တော် ကျေနပ်ပါတယ်- ပဟေဠိအပိုင်းတိုင်းဟာ လိုက်ဖက်ညီပါတယ်၊ ကျွန်တော်တို့ သတိပြုမိတဲ့အရာကို ဘာကြောင့် အတိအကျ ရှင်းပြနိုင်တယ်၊ အရေးအကြီးဆုံးကတော့၊ ကျွန်တော်တို့ အဖွဲ့လိုက်လုပ်ဆောင်မှုကြောင့် ပြဿနာရဲ့ အဖြေကို ရှာဖွေနိုင်ခဲ့ပါတယ်။

အမှုသည် ရှားရှားပါးပါး ဖြစ်သွားသည်ကို အသိအမှတ်ပြုထိုက်ပြီး ကံကောင်းစွာပင် သုံးစွဲသူများထံမှ ထိုကဲ့သို့ ရှုပ်ထွေးသော တောင်းဆိုမှုများကို ကျွန်ုပ်တို့ လက်ခံရရှိခဲပါသည်။

source: www.habr.com