Troubleshooting — Layer အလိုက် စစ်ဆေးနည်း

နားလည်ထားရမယ့် အချက်

Network debugging အများစုဟာ ပထမဆုံးအဆင့်မှာတင် လမ်းလွဲသွားတယ် — တစ်စုံတစ်ယောက်က theory တစ်ခု ချက်ချင်း ချမှတ်ပြီး အဲဒီ theory တစ်ခုတည်းကိုသာ စမ်းသပ်တဲ့အခါမှာ။ Layered model က ဒါထက် ပိုကောင်းတဲ့ အရာတစ်ခု ပေးတယ် — အစီအစဉ်တစ်ခု။ Layer တိုင်းက သူ့အောက်က layer အပေါ် မှီခိုနေတာမို့ အောက်ဆုံးမှာ ကျရှုံးမှုတစ်ခု ရှိနေရင် အပေါ်က test အားလုံးဟာ အဓိပ္ပာယ်မဲ့သွားတယ်။ Link, ပြီးရင် IP address, ပြီးရင် routing, ပြီးရင် DNS, ပြီးရင် transport, ပြီးရင် application — ပြီးတော့ ပထမဆုံး ကျရှုံးတဲ့နေရာမှာ ရပ်လိုက်ပါ၊ အဲဒါကို မပြင်မချင်း အပေါ်က အရာအားလုံးဟာ ဆူညံသံသာ ဖြစ်တယ်။

ဒီစည်းကမ်းက အရေးကြီးရတဲ့ အကြောင်းရင်းက classic tool တွေဟာ သူတို့ရဲ့ ဂုဏ်သတင်းထက် အများကြီး နည်းတဲ့ အရာကိုသာ သက်သေပြလို့ပါ။ Ping က IP packet တစ်ခု host ဆီ ရောက်ပြီး ICMP echo reply ပြန်လာတယ်ဆိုတာကို သက်သေပြတယ်။ Layer 3 reachability ကို သက်သေပြပြီး တခြားဘာမှ မပြဘူး။ Web process ပျက်နေတဲ့ server တစ်ခုဟာ ping ကို လှလှပပ ပြန်ဖြေနေမယ်။ ICMP ကို drop လုပ်တဲ့ firewall ရှိတဲ့ server တစ်ခုကတော့ ping မရဘဲ traffic ကို ပျော်ပျော်ကြီး serve လုပ်နေမယ်။ Ping ဆိုတာ network path အကြောင်း ပြောတဲ့ ဖော်ပြချက်တစ်ခုသာ ဖြစ်ပြီး service အကြောင်း ဘယ်တော့မှ မဟုတ်ဘူး။

Traceroute ကတော့ ပိုပြီး နက်နဲတယ်။ သူက path ကို ရှာဖွေတာ မဟုတ်ဘူး — TTL ကို တမင် သေးသေးလေး ထားပြီး packet တွေ ပို့လိုက်ကာ TTL ကို သုညအထိ လျှော့ချလိုက်တဲ့ router တွေဆီက ICMP time-exceeded reply တွေကို စုဆောင်းတာ ဖြစ်တယ်။ အဲဒီ reply တွေဟာ router ကိုယ်တိုင် ရွေးထားတဲ့ source address ကနေ လာပြီး၊ သူတို့ကိုယ်ပိုင် return path ကို သွားပြီး၊ rate-limit လုပ်ထားလေ့ရှိတဲ့ နှေးကွေးတဲ့ control-plane process တစ်ခုက ထုတ်ပေးတာ ဖြစ်တယ်။ ဒါကြောင့် latency မြင့်နေတဲ့ ဒါမှမဟုတ် ကြယ်ပွင့် ပြနေတဲ့ hop တစ်ခုဟာ congestion မဟုတ်ဘဲ router တစ်ခုက ICMP ကို ဦးစားပေး လျှော့ချထားတာ ဖြစ်နေတာ များတယ်။ ပြီးတော့ equal-cost path တွေပေါ် load balancing လုပ်နေရင် ဆက်တိုက် probe တွေဟာ လုံးဝ ကွဲပြားတဲ့ လမ်းကြောင်းတွေ သွားနေနိုင်တယ် — သင် print ထုတ်လိုက်တဲ့ 'path' ဟာ တစ်ခုတည်းသော path အဖြစ် ဘယ်တုန်းကမှ မတည်ရှိခဲ့ဖူးဘူး ဖြစ်နိုင်တယ်။

DNS ကလည်း အလားတူ ထောင်ချောက်ပဲ — lookup အောင်မြင်တာက name resolve ဖြစ်တယ်ဆိုတာကိုသာ သက်သေပြတယ်။ ပြန်ရလာတဲ့ address ဆီ ရောက်နိုင်၊ မရောက်နိုင်၊ ဒါမှမဟုတ် အဲဒီမှာ တစ်စုံတစ်ခု နားထောင်နေရဲ့လား ဆိုတာနဲ့ ပတ်သက်ပြီး ဘာမှ မပြောဘူး။ Tool တစ်ခုစီက မေးခွန်း တစ်ခုတည်းကိုသာ ဖြေတယ်။ ဘယ်မေးခွန်းလဲဆိုတာ သိထားပါ။

BOTTOM-UP TROUBLESHOOTING DECISION TREE
---------------------------------------
      [ "the site is down" ]
               |
               v
   +-------------------------+
   | 1. link up, have an IP? |--- no --> cable, Wi-Fi, DHCP
   +-------------------------+
               | yes
               v
   +-------------------------+
   | 2. gateway reachable?   |--- no --> wrong mask/gw, ARP
   +-------------------------+
               | yes
               v
   +-------------------------+
   | 3. off-net IP pingable? |--- no --> routing, upstream
   +-------------------------+
               | yes
               v
   +-------------------------+
   | 4. name resolves?       |--- no --> DNS only, NOT the host
   +-------------------------+
               | yes
               v
   +-------------------------+  refused -> nothing is listening
   | 5. port connects?       |  timeout -> a firewall is dropping
   +-------------------------+
               | yes
               v
   +-------------------------+
   | 6. app answers cleanly? |--- no --> logs, TLS, vhost config
   +-------------------------+
               | yes
               v
     not this path -- look at the client


WHAT EACH TOOL ACTUALLY PROVES

  ping    an IP packet made the round trip.  NOT that a
          service is up, and NOT that a port is open.
  trace   a list of ICMP TTL-expiry replies. NOT the path,
          and its timings are control-plane, not forwarding.
  DNS     the name resolved.  NOT that the answer is reachable.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

သင် အမြဲတမ်း ရရှိမယ့် အဖြစ်များဆုံး report ကို ယူကြည့်ရအောင် — 'site က down နေတယ်' ။ Application log ကို အရင် ဖွင့်ချင်တဲ့ စိတ်ကို ထိန်းပါ။

စက္ကန့်ပိုင်းသာ ကုန်တဲ့ မေးခွန်းနှစ်ခုနဲ့ အောက်ခြေကနေ စပါ။ Machine မှာ တကယ့် IP နဲ့ gateway ရှိရဲ့လား? Gateway ဆီ ရောက်နိုင်ရဲ့လား? မရှိဘူးဆိုရင် ကျန်တဲ့ဟာ ဘာမှ စမ်းစရာ မလိုတော့ဘူး — link ဒါမှမဟုတ် DHCP ပြဿနာ ဖြစ်ပြီး application က မသက်ဆိုင်တော့ဘူး။

နောက်တစ်ခု၊ name resolution နဲ့ reachability ကို ခွဲထုတ်ပါ — browser ထဲမှာ ဒီနှစ်ခုဟာ တစ်ထပ်တည်း တူတဲ့ ပုံစံနဲ့ ကျရှုံးလို့ပါ။ Name ကို resolve လုပ်ပြီး address ကို မှတ်ထားပါ။ ပြီးရင် အဲဒီ address ကို တိုက်ရိုက် စမ်းပါ။ Name ကျရှုံးပြီး address အလုပ်လုပ်ရင် DNS ဖြစ်တယ်။ နှစ်ခုလုံး ကျရှုံးရင် routing ဒါမှမဟုတ် filtering ဖြစ်တယ်။ ဒီ ခွဲထုတ်မှု တစ်ခုတည်းက ဖြစ်နိုင်ခြေရှိတဲ့ အကြောင်းရင်း တစ်ဝက်ကို test တစ်ခုတည်းနဲ့ ဖယ်ရှားပေးတယ်။

ပြီးရင် transport ဆီ ရွှေ့ပါ။ သတ်မှတ်ထားတဲ့ port ကို ဆက်သွယ်ကြည့်ခြင်းဟာ 'host တက်နေတယ်' နဲ့ 'service တက်နေတယ်' ကို ခွဲခြားပေးတဲ့ test ဖြစ်တယ် — ping က မလုပ်ပေးနိုင်တဲ့ ခွဲခြားမှုပါ။ Connection refused ဆိုတာ တစ်စုံတစ်ခုက ဖြေပြီး ငြင်းလိုက်တာမို့ host အသက်ရှင်နေပြီး process က နားမထောင်နေတာ ဖြစ်တယ်။ Timeout ဆိုတာ ဘာမှ လုံးဝ မဖြေတာမို့ firewall တစ်ခုက reject မလုပ်ဘဲ တိတ်တဆိတ် drop လုပ်နေတာကို ညွှန်းတယ်။ Refused နဲ့ timed out ကြားက အဲဒီ ကွာခြားချက်ဟာ networking မှာ အချက်အလက် အပေးနိုင်ဆုံး signal တွေထဲက တစ်ခုဖြစ်ပြီး အခမဲ့ ရနိုင်တယ်။

Port ဖွင့်နေမှသာ application log, TLS, virtual host configuration တွေကို ဖတ်ပါ။ အောက်က decision tree က ဒီအစီအစဉ်အတိုင်း အတိအကျ ရေးထားပြီး၊ သူ့ output ထဲက ဒုတိယ case ဟာ classic တစ်ခု ဖြစ်တယ် — ping ရတယ်၊ resolve ရတယ်၊ ဒါပေမယ့် လုံးဝ ပျက်နေတယ်။

• အောက်ကနေအပေါ်ဆီ debug လုပ်ပြီး ပထမဆုံး ကျရှုံးတဲ့ layer မှာ ရပ်ပါ
• Ping က L3 reachability ကိုသာ သက်သေပြတယ်၊ service တက်နေတာ မဟုတ်
• Connection refused နဲ့ timed out က မတူညီတဲ့ အဓိပ္ပာယ် ရှိတယ်

အတူတူ စမ်းရေးကြည့်မယ်

# A layer-by-layer triage tree. Each check is a fact you have already
# established, NOT a guess. The point is to stop at the FIRST layer that
# fails, because everything above it is meaningless until that is fixed.

CHECKS = [
    ("link_up", "L1/L2 link", "Interface is down. Check cable, Wi-Fi association, driver."),
    ("has_ip", "L3 address", "No usable IP. Check DHCP, or a 169.254.x.x self-assignment."),
    ("gateway_reachable", "L3 local", "Cannot reach the gateway. Wrong mask/gateway, or ARP failing."),
    ("internet_ip_reachable", "L3 routing", "Off-net IPs unreachable. Routing or the upstream is broken."),
    ("dns_resolves", "DNS", "Names do not resolve. Wrong resolver, or the zone is broken."),
    ("port_open", "L4 transport", "Port refuses. The service is down, or a firewall filtered it."),
    ("app_responds", "L7 application", "TCP connects, app errors. Check logs, TLS, and vhost config."),
]


def triage(name, symptoms):
    print("case: " + name)
    for key, layer, advice in CHECKS:
        ok = symptoms[key]
        mark = "PASS" if ok else "FAIL"
        print("  [" + mark + "] " + layer)
        if not ok:
            print("  -> stop here: " + advice)
            return layer
    print("  -> every layer passes; the fault is not on this path.")
    return None


# Symptom sets are hardcoded so this stays deterministic. In real life
# each field is the result of one command you actually ran.
CASES = [
    ("web page will not load", {
        "link_up": True, "has_ip": True, "gateway_reachable": True,
        "internet_ip_reachable": True, "dns_resolves": False,
        "port_open": False, "app_responds": False,
    }),
    ("ping works, site still down", {
        "link_up": True, "has_ip": True, "gateway_reachable": True,
        "internet_ip_reachable": True, "dns_resolves": True,
        "port_open": False, "app_responds": False,
    }),
    ("laptop has no network at all", {
        "link_up": True, "has_ip": False, "gateway_reachable": False,
        "internet_ip_reachable": False, "dns_resolves": False,
        "port_open": False, "app_responds": False,
    }),
    ("everything connects, 502 in browser", {
        "link_up": True, "has_ip": True, "gateway_reachable": True,
        "internet_ip_reachable": True, "dns_resolves": True,
        "port_open": True, "app_responds": False,
    }),
]

for name, symptoms in CASES:
    triage(name, symptoms)
    print("")

# The classic trap, stated plainly.
print("note: ping succeeding proves L3 only.")
print("case 2 above pings fine and is still completely broken.")

case: web page will not load
  [PASS] L1/L2 link
  [PASS] L3 address
  [PASS] L3 local
  [PASS] L3 routing
  [FAIL] DNS
  -> stop here: Names do not resolve. Wrong resolver, or the zone is broken.

case: ping works, site still down
  [PASS] L1/L2 link
  [PASS] L3 address
  [PASS] L3 local
  [PASS] L3 routing
  [PASS] DNS
  [FAIL] L4 transport
  -> stop here: Port refuses. The service is down, or a firewall filtered it.

case: laptop has no network at all
  [PASS] L1/L2 link
  [FAIL] L3 address
  -> stop here: No usable IP. Check DHCP, or a 169.254.x.x self-assignment.

case: everything connects, 502 in browser
  [PASS] L1/L2 link
  [PASS] L3 address
  [PASS] L3 local
  [PASS] L3 routing
  [PASS] DNS
  [PASS] L4 transport
  [FAIL] L7 application
  -> stop here: TCP connects, app errors. Check logs, TLS, and vhost config.

note: ping succeeding proves L3 only.
case 2 above pings fine and is still completely broken.

RFC 792 - Internet Control Message Protocol — Computer Networking