Server-এর network হাতিয়ার — ip, ss, dig, curl আর সমস্যা খোঁজা

১ · “Site চলছে না” — অনুমান নয়, স্তর ধরে খোঁজা

রাত এগারোটা। একটি কাল্পনিক অনলাইন বাজার অ্যাপের দলের group-এ বার্তা এলো: “Site চলছে না!” কেউ বলছেন server restart দিন, কেউ বলছেন firewall বন্ধ করে দেখি। দুটোই অনুমান। অনুমানে কাজ হলেও আপনি জানবেন না কী হয়েছিল, আর পরের সপ্তাহে একই ঘটনা ফিরবে।

এই পাঁচটি জায়গা হলো নিচের পাঁচটি স্তর। নেটওয়ার্কের তত্ত্ব, মানে packet আর protocol কীভাবে কাজ করে, তা Computer Networks কোর্সের বিষয়। সেখানে Linux-এ নেটওয়ার্ক দেখা আর সমস্যা খোঁজা পর্ব দুটি গভীরে যায়। এখানে আমরা দেখব একজন server চালকের কাজ: কোন স্তরে কোন হাতিয়ার ধরবেন, আর তার আউটপুট কীভাবে পড়বেন।

২ · নিজের server-কে চিনুন — ip addr আর ip route

SSH দিয়ে server-এ ঢুকে (পর্ব ১২) প্রথম প্রশ্ন: এই যন্ত্রের ঠিকানা কী, আর বাইরে যাওয়ার পথ কোনটি? একটি server-এর এক বা একাধিক network interface থাকে, মানে যে “দরজা” দিয়ে সে নেটওয়ার্কে যুক্ত। প্রতিটি interface-এর নিজের ঠিকানা থাকে।

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ ip -br addr
lo      UNKNOWN  127.0.0.1/8 ::1/128
eth0    UP       10.0.1.25/24

$ ip route
default via 10.0.1.1 dev eth0 proto dhcp src 10.0.1.25 metric 100
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.25

$ ip route get 203.0.113.50
203.0.113.50 via 10.0.1.1 dev eth0 src 10.0.1.25 uid 1000
    cache

• lo হলো loopback interface: server নিজের সাথে কথা বলার পথ। ঠিকানা 127.0.0.1. এর packet যন্ত্রের বাইরে যায় না।
• eth0 UP মানে interface চালু। নাম ens5 বা অন্য কিছুও হতে পারে। DOWN দেখলে সমস্যা একদম নিচের স্তরে।
• default via 10.0.1.1 হলো routing table-এর default gateway লাইন: যে ঠিকানার জন্য নির্দিষ্ট পথ নেই, সেগুলো সব এখানে যায়। এই লাইন না থাকলে server বাইরের কারও সাথে কথা বলতে পারবে না।
• ip route get বলে দেয় একটি নির্দিষ্ট ঠিকানায় যেতে kernel এখন কোন পথ বাছবে। Routing table নিজে হাতে পড়ার চেয়ে এটি দ্রুত আর ভুল কম।

৩ · কে শুনছে — ss -tlnp আর 127.0.0.1 বনাম 0.0.0.0

একটি server-এ অনেক প্রোগ্রাম একসাথে চলে। বাইরের অনুরোধ কার কাছে যাবে, তা ঠিক হয় port নম্বর দিয়ে: ঠিকানা যদি ভবন হয়, port হলো ফ্ল্যাট নম্বর। একটি প্রোগ্রাম নির্দিষ্ট ঠিকানা আর port-এ অপেক্ষা করলে তাকে বলে “listen করছে”। সেই সংযোগের প্রান্তটির নাম socket. ss দেখায় কে কোথায় listen করছে।

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ sudo ss -tlnp
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=812,fd=6))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=640,fd=4))
LISTEN 0      244        127.0.0.1:5432      0.0.0.0:*    users:(("postgres",pid=901,fd=6))

চারটি অক্ষর মনে রাখুন: -t TCP, -l শুধু listen করা socket, -n নামের বদলে সংখ্যা, -p কোন process. অন্য user-এর process দেখতে sudo লাগে। পড়ার নিয়ম:

• Local Address:Port সবচেয়ে গুরুত্বপূর্ণ ঘর। এখানেই লেখা কে কোন দরজায় আছে।
• Process বলে কোন প্রোগ্রাম, তার pid কত। users:(("nginx",pid=812,fd=6)) মানে nginx, process নম্বর 812.
• Recv-Q আর Send-Q: LISTEN লাইনে Recv-Q হলো অপেক্ষারত সংযোগের সংখ্যা, আর Send-Q তার সীমা। Recv-Q সীমার কাছে গেলে অ্যাপ সংযোগ নিতে পারছে না, যদিও সে “চলছে”।

Bind ঠিকানাই ঠিক করে কে ঢুকতে পারবে

একটি প্রোগ্রাম কোন ঠিকানায় listen করবে, সেটিই তার bind address. এই ছোট্ট সেটিংটিই সবচেয়ে বেশি ভোগায়। সেই ডাক্তারের কথা ভাবুন: 127.0.0.1 মানে তিনি শুধু নিজের বাড়ির লোক দেখেন। 0.0.0.0 মানে সব দরজা খোলা, যে দরজা দিয়েই আসুন দেখবেন। একে wildcard address বলে।

এবার নিজে চালিয়ে দেখুন। নিচের script হাতে লেখা একটি নমুনা তালিকা পড়ে। এটি কোনো আসল কমান্ড চালায় না। সব interface-এ listen করা service খুঁজে বের করে, আর যেগুলো অনুমোদিত তালিকায় নেই সেগুলোকে আলাদা করে দেখায়।

set -euo pipefail
# Sample text typed by hand; nothing here reads the machine this runs on.
ALLOWED="22 80 443"     # ports that are meant to be public on this server
awk -v allowed="$ALLOWED" '
BEGIN { n = split(allowed, p, " "); for (i = 1; i <= n; i++) ok[p[i]] = 1 }
$1 == "LISTEN" {
    c = split($4, parts, ":"); port = parts[c]
    addr = substr($4, 1, length($4) - length(port) - 1)
    match($6, /"[^"]+"/); proc = substr($6, RSTART + 1, RLENGTH - 2)
    if (addr == "127.0.0.1" || addr == "[::1]") { kind = "local"; note = "ok, loopback only" }
    else if (addr == "0.0.0.0" || addr == "[::]" || addr == "*") {
        kind = "ALL"
        note = (port in ok) ? "ok, meant to be public" : "REVIEW: not on the allow list"
        if (!(port in ok)) bad++
    } else { kind = "one-ip"; note = "bound to one address" }
    printf "%-6s %-7s %-14s %s\n", port, kind, proc, note
}
END { printf "services to review: %d\n", bad + 0 }
' <<'EOF'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511    0.0.0.0:80         0.0.0.0:*         users:(("nginx",pid=812,fd=6))
LISTEN 0      511    0.0.0.0:443        0.0.0.0:*         users:(("nginx",pid=812,fd=7))
LISTEN 0      128    [::]:22            [::]:*            users:(("sshd",pid=640,fd=4))
LISTEN 0      244    127.0.0.1:5432     0.0.0.0:*         users:(("postgres",pid=901,fd=6))
LISTEN 0      511    0.0.0.0:6379       0.0.0.0:*         users:(("redis-server",pid=955,fd=6))
LISTEN 0      4096   *:9100             *:*               users:(("node_exporter",pid=702,fd=3))
LISTEN 0      128    10.0.1.25:8080     0.0.0.0:*         users:(("api",pid=1204,fd=9))
EOF

80     ALL     nginx          ok, meant to be public
443    ALL     nginx          ok, meant to be public
22     ALL     sshd           ok, meant to be public
5432   local   postgres       ok, loopback only
6379   ALL     redis-server   REVIEW: not on the allow list
9100   ALL     node_exporter  REVIEW: not on the allow list
8080   one-ip  api            bound to one address
services to review: 2

৪ · নাম আর পথ — dig, ping, traceroute আর mtr

dig: নামটি কোন ঠিকানায় যায়

DNS হলো ইন্টারনেটের ঠিকানা-বই: নাম দিলে IP দেয়। আপনার server যাকে জিজ্ঞেস করে, সে হলো resolver. DNS-এর তত্ত্ব Computer Networks কোর্সে আছে; cloud-এর DNS সেবা পর্ব ২৯-এ। এখানে আমরা শুধু আউটপুট পড়ব।

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ dig example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.     287  IN  A  203.0.113.10

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

ঠিকানার পাশের 287 হলো TTL: resolver আরও এত সেকেন্ড পুরোনো উত্তর মনে রাখবে। তাই DNS বদলানোর পরও কিছুক্ষণ পুরোনো ঠিকানা আসতে পারে। অন্য resolver-কে সরাসরি জিজ্ঞেস করে তুলনা করতে dig @1.1.1.1 example.com লিখুন। আর একটি সূক্ষ্ম কথা: dig সরাসরি DNS-কে জিজ্ঞেস করে, /etc/hosts ফাইল দেখে না। অ্যাপ সাধারণত সেই ফাইলও দেখে। অ্যাপ যা পাচ্ছে তা জানতে getent hosts example.com চালান।

ping: ওপারে কেউ সাড়া দিচ্ছে কি

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ ping -c 4 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=38.2 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=54 time=38.6 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=54 time=39.1 ms
64 bytes from 203.0.113.10: icmp_seq=4 ttl=54 time=37.9 ms

--- 203.0.113.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 37.9/38.4/39.1/0.4 ms

ping পাঠায় ICMP বার্তা, আর time হলো যাওয়া-আসার সময় (RTT). packet loss বলে কত ভাগ হারাল। সাবধান: ping না চলা মানেই server বন্ধ নয়। অনেক cloud firewall ডিফল্টে ICMP আটকায়। ping সফল হলে পথ খোলা বোঝা যায়, কিন্তু ব্যর্থ হলে কিছুই প্রমাণ হয় না।

traceroute আর mtr: পথের কোন মোড়ে আটকাচ্ছে

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ mtr -rwc 20 203.0.113.10
HOST: web-1           Loss%   Snt   Last    Avg   Best   Wrst  StDev
  1.|-- 10.0.1.1       0.0%    20    0.4    0.5    0.3    0.9    0.1
  2.|-- ???           100.0%   20    0.0    0.0    0.0    0.0    0.0
  3.|-- 198.51.100.1  30.0%    20   12.1   12.4   11.8   14.0    0.5
  4.|-- 203.0.113.10   0.0%    20   38.3   38.5   37.9   39.4    0.3

traceroute পথের প্রতিটি router-এর তালিকা দেয়, আর mtr একই কাজ বারবার করে প্রতিটি মোড়ের ক্ষতি আর সময় মাপে। এই আউটপুট পড়ার আসল নিয়ম: শেষ লাইন দেখুন। ওপরে হপ ৩-এ 30% ক্ষতি দেখাচ্ছে, অথচ হপ ৪-এ 0%. তাহলে আসল ক্ষতি নেই; router 3 শুধু নিজের সম্পর্কে উত্তর দিতে কৃপণ। ক্ষতি যদি একটি হপ থেকে শুরু হয়ে শেষ পর্যন্ত চলে, তবেই সেটি আসল। ??? বা * * * মানে সেই router উত্তর দেয়নি, পথ ভাঙা নয়। Port-ভিত্তিক সমস্যায় sudo traceroute -T -p 443 example.com TCP ব্যবহার করে, যা firewall-এ HTTPS-এর মতো আচরণ পায়।

৫ · দরজায় কড়া নাড়া — nc আর ছয় রকম ব্যর্থতা

nc (netcat) কোনো protocol জানে না। সে শুধু একটি port-এ TCP সংযোগ করে দেখে। Three-way handshake সফল হলেই “দরজা খোলা”। TCP সংযোগের তত্ত্ব Computer Networks কোর্সে আছে।

# উদাহরণ · নমুনা আউটপুট, OpenBSD netcat; version-ভেদে আলাদা হতে পারে
$ nc -vz -w 3 203.0.113.10 443
Connection to 203.0.113.10 443 port [tcp/https] succeeded!

$ nc -vz -w 3 203.0.113.10 8080
nc: connect to 203.0.113.10 port 8080 (tcp) failed: Connection refused

$ nc -vz -w 3 203.0.113.10 5432
nc: connect to 203.0.113.10 port 5432 (tcp) timed out: Operation now in progress

এই পর্বের সবচেয়ে দামি টেবিল এটি। ভুলের ধরন দেখেই বোঝা যায় কোন স্তরে তাকাবেন:

সময়ও একটি সূত্র। Refused আসে প্রায় এক RTT-তেই। Timeout-এ Linux ডিফল্ট সেটিংয়ে (tcp_syn_retries=6) SYN পাঠাতে থাকে 1, 2, 4, 8, 16, 32 আর 64 সেকেন্ড বিরতিতে, মোট প্রায় 127 সেকেন্ড; তবে অ্যাপ বা curl-এর নিজের সীমা আগেই থামাতে পারে। একটি ব্যতিক্রম মনে রাখুন: কোনো firewall REJECT নিয়মে থাকলে সে নিজেই উত্তর দেয়, ফলে firewall থেকেও refused আসতে পারে। Nginx-এর log এই দুটিকে পরিষ্কার আলাদা করে (HTTP-র status code দেখুন, আর nginx-এর পুরো গল্প পর্ব ১৪-এ):

# উদাহরণ · নমুনা error.log, version-ভেদে আলাদা হতে পারে
connect() failed (111: Connection refused) while connecting to upstream   → 502
upstream timed out (110: Connection timed out) while reading response header from upstream   → 504

এখানে upstream মানে reverse proxy-র পেছনের অ্যাপ। এবার সব মিলিয়ে একটি পুরো তদন্ত দেখি। ধরুন কাল্পনিক বাজার অ্যাপের API চলে api.example.com:8080-এ। ল্যাপটপ থেকে এলো Connection refused. “পরে” চেপে এগোন।

৬ · curl -v আর সময়ের হিসাব — ধীর কোন ধাপ

curl একটি পুরো অনুরোধ করে, তাই এক কমান্ডেই সব স্তর পরীক্ষা হয়। -v দিলে প্রতিটি ধাপ বলে দেয়। প্রথম চিহ্নটি দেখে পড়ুন: * মানে curl-এর নিজের খবর, > মানে যা পাঠাল, < মানে যা পেল।

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ curl -v -o /dev/null https://example.com/
* Host example.com:443 was resolved.
* IPv4: 203.0.113.10
*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  expire date: Dec 28 23:59:59 2026 GMT
> GET / HTTP/2
> Host: example.com
< HTTP/2 200
< content-type: text/html

কোন লাইন পর্যন্ত এসে থেমেছে, সেটিই আপনার স্তর। curl-এর exit code-ও স্তর বলে: 6 নাম মেলেনি, 7 সংযোগ হয়নি, 28 সময় শেষ, 35 TLS handshake ব্যর্থ, 60 certificate যাচাই ব্যর্থ। একটি দরকারি কৌশল হলো DNS এড়িয়ে নির্দিষ্ট একটি server পরীক্ষা করা:

# Send the request to one chosen server, keep the real host name for TLS and HTTP
curl -sv -o /dev/null --resolve example.com:443:203.0.113.20 https://example.com/

কোন ধাপে সময় গেল

ব্যবহারকারী বলছেন “পাতা ধীর”। “ধীর” একটি অনুভূতি, মাপ নয়। curl-এর -w (write-out) অপশন প্রতিটি ধাপের ঘড়ি দেখায়:

curl -sS -o /dev/null -w \
  'dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/report

এবার একসাথে পাঁচটি অনুরোধ বিশ্লেষণ করি। লাইনগুলো হাতে লেখা নমুনা; script বিয়োগ করে সবচেয়ে ধীর ধাপটি খুঁজে দেয়।

set -euo pipefail
# Sample lines typed by hand. Every time is cumulative, counted from the start.
awk '
function ms(x) { return int(x * 1000 + 0.5) }
{
    for (i = 2; i <= NF; i++) { split($i, kv, "="); t[kv[1]] = kv[2] }
    ph["dns"]  = ms(t["dns"])
    ph["tcp"]  = ms(t["conn"]) - ms(t["dns"])
    ph["tls"]  = ms(t["tls"]) - ms(t["conn"])
    ph["wait"] = ms(t["ttfb"]) - ms(t["tls"])
    ph["recv"] = ms(t["total"]) - ms(t["ttfb"])
    slow = "dns"
    split("tcp tls wait recv", names, " ")
    for (i = 1; i <= 4; i++) if (ph[names[i]] > ph[slow]) slow = names[i]
    printf "%-8s dns=%-5d tcp=%-5d tls=%-3d wait=%-5d recv=%-5d slow=%s (%d%%)\n", \
        $1, ph["dns"], ph["tcp"], ph["tls"], ph["wait"], ph["recv"], slow, \
        100 * ph[slow] / ms(t["total"])
}' <<'EOF'
/health dns=0.004 conn=0.044 tls=0.121 ttfb=0.162 total=0.165
/report dns=0.012 conn=0.052 tls=0.131 ttfb=1.948 total=1.985
/login  dns=5.014 conn=5.054 tls=5.133 ttfb=5.190 total=5.194
/search dns=0.006 conn=3.047 tls=3.126 ttfb=3.171 total=3.176
/export dns=0.005 conn=0.045 tls=0.124 ttfb=0.180 total=6.180
EOF

/health  dns=4     tcp=40    tls=77  wait=41    recv=3     slow=tls (46%)
/report  dns=12    tcp=40    tls=79  wait=1817  recv=37    slow=wait (91%)
/login   dns=5014  tcp=40    tls=79  wait=57    recv=4     slow=dns (96%)
/search  dns=6     tcp=3041  tls=79  wait=45    recv=5     slow=tcp (95%)
/export  dns=5     tcp=40    tls=79  wait=56    recv=6000  slow=recv (97%)

৭ · TLS আর certificate — openssl s_client

HTTPS-এর সংযোগে TLS দুটি কাজ করে: লেখা গোপন রাখে, আর server-এর পরিচয় প্রমাণ করে। পরিচয়ের কাগজটির নাম certificate: কোন নামের জন্য, কে দিয়েছে, কতদিন বৈধ। জাতীয় পরিচয়পত্রের মতো, তবে মেয়াদ অনেক ছোট। Handshake-এর তত্ত্ব Computer Networks কোর্সে আছে। curl বলে “ব্যর্থ”; openssl s_client দেখায় server আসলে কী দেখাচ্ছে।

# What the server really presents: subject, issuer and dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

এখানে -servername হলো SNI: একই ঠিকানায় অনেক site থাকলে client জানায় কোন নামটি চায়। ভুল নাম দিলে অন্য certificate আসতে পারে। পুরো আউটপুটের Verify return code লাইনটিও পড়ুন: 0 (ok) মানে যাচাই সফল, 10 মেয়াদ শেষ, 21 সাধারণত certificate chain-এর মাঝের অংশ server পাঠায়নি। শেষেরটি ঠকায়, কারণ browser অনেক সময় নিজে মাঝের অংশ জোগাড় করে নেয়, অথচ curl বা অন্য অ্যাপ ব্যর্থ হয়।

এবার সবচেয়ে পরিচিত ঘটনাটি দেখি। ধরে নিই আজ ৩০ অক্টোবর ২০২৬। Monitoring alert জানাল, shop.example.com-এ HTTPS ভাঙা।

$ curl -sS https://shop.example.com/
curl: (60) SSL certificate problem:
certificate has expired

$ openssl s_client -connect shop.example.com:443 \
    -servername shop.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
notBefore=Jul 30 00:00:00 2026 GMT
notAfter=Oct 28 23:59:59 2026 GMT

$ ... | openssl x509 -noout -subject -ext subjectAltName
subject=CN=shop.example.com
X509v3 Subject Alternative Name:
    DNS:shop.example.com

$ cd /etc/ssl/shop
$ sudo openssl x509 -in fullchain.pem -noout -enddate
notAfter=Dec 28 23:59:59 2026 GMT
↑ ফাইলটি নতুন, কিন্তু server দেখাচ্ছে পুরোনোটি

$ sudo nginx -t
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl reload nginx

$ ... | openssl x509 -noout -enddate -checkend 2592000
notAfter=Dec 28 23:59:59 2026 GMT
Certificate will not expire

৮ · Packet চোখে দেখা আর firewall — tcpdump, ufw, nftables

সব কমান্ড ব্যর্থ হলে একটি প্রশ্নই বাকি থাকে: packet কি আদৌ আমার server-এ পৌঁছাচ্ছে? tcpdump এর সরাসরি উত্তর দেয়। একে বলে packet capture.

# উদাহরণ · নিজের server-এ, নমুনা আউটপুট; version-ভেদে আলাদা হতে পারে
$ sudo tcpdump -i eth0 -nn -c 2 'tcp port 8080'
10:15:01.120418 IP 198.51.100.7.51514 > 10.0.1.25.8080: Flags [S], seq 1001, win 64240, length 0
10:15:01.120466 IP 10.0.1.25.8080 > 198.51.100.7.51514: Flags [R.], seq 0, ack 1002, win 0, length 0

গন্তব্যে 10.0.1.25 দেখছেন, কারণ cloud public ঠিকানা অনুবাদ করে দিয়েছে। পড়ার নিয়ম হলো Flags ঘর: [S] সংযোগের অনুরোধ (SYN), [S.] তার উত্তর, [.] ACK, [P.] ডেটা, [R.] প্রত্যাখ্যান। তিনটি দৃশ্য মনে রাখুন:

দ্বিতীয় সারির কারণ একটি সূক্ষ্ম তথ্য: ingress পথে tcpdump সাধারণত লোকাল firewall-এর আগে packet দেখে। তাই “SYN দেখা গেল” মানে “অ্যাপে পৌঁছাল” নয়।

Firewall: দুই বেড়া

একটি cloud VM-এর সামনে সাধারণত দুটি বেড়া থাকে। বাইরেরটি হলো security group: এটি cloud-এর network-এ থাকে, VM-এর ভেতর থেকে দেখা যায় না (পর্ব ২৭)। ভেতরেরটি হলো Linux kernel-এর firewall, যা চালানো হয় nftables বা তার ওপরের সহজ মোড়ক ufw দিয়ে। বিস্তারিত Firewall আর VPN পর্বে।

# উদাহরণ · নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে
$ sudo ufw status verbose
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    203.0.113.0/24
443/tcp                    ALLOW IN    Anywhere

$ sudo nft list ruleset
table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        iif "lo" accept
        tcp dport { 22, 443 } accept
    }
}

দুই ধরনের প্রত্যাখ্যানের পার্থক্য এখানে স্পষ্ট। policy drop বা DROP নিয়মে packet চুপচাপ ফেলা হয়, ফলে অন্য প্রান্তে timeout. REJECT নিয়মে firewall ফিরতি বার্তা পাঠায়, ফলে দ্রুত ব্যর্থতা।

৯ · সব মিলিয়ে সিদ্ধান্তের গাছ

এতক্ষণের সব নিয়ম একটি সিদ্ধান্তের গাছে আনা যায়, যাকে দলের runbook-এও রাখতে পারেন। নিচের সিমুলেটরে প্রতিটি কেসে লক্ষণ দেওয়া আছে। গাছ প্রশ্ন ধরে এগোয়, আর শেষে পরের কমান্ড আর সম্ভাব্য কারণ বলে। নিজের কেস যোগ করে আবার চালান, যেমন { dns: "ok", connect: "ok", tls: "ok", http: 502 }.

const leaf = (cmd, cause) => ({ cmd, cause });
const tree = { q: "dns",
  nxdomain: leaf("dig example.com NS +short", "record missing, or wrong zone/name"),
  servfail: leaf("dig +trace example.com", "broken delegation or name server down"),
  ok: { q: "connect",
    refused: { q: "listening",
      no: leaf("systemctl status app; journalctl -u app -n 50", "process not running"),
      loopback: leaf("ss -tlnp; check the app bind setting", "app bound to 127.0.0.1 only"),
      all: leaf("nft list ruleset; ufw status verbose", "firewall REJECT rule or wrong host") },
    timeout: { q: "synSeen",
      no: leaf("check security group, route table, public IP", "dropped before the server"),
      yes: leaf("nft list ruleset; ip route", "local firewall DROP or broken reply path") },
    ok: { q: "tls",
      expired: leaf("openssl x509 -noout -enddate", "expired, or old certificate still served"),
      mismatch: leaf("openssl x509 -noout -ext subjectAltName", "wrong certificate for this name"),
      ok: { q: "http",
        502: leaf("tail nginx error.log; ss -tlnp", "upstream refused or sent a bad reply"),
        504: leaf("tail nginx error.log; check app and DB", "upstream too slow: read timeout"),
        200: { q: "slowPhase",
          dns: leaf("resolvectl status", "slow or failing resolver"),
          wait: leaf("app logs, DB slow query log", "server work: app, DB, dependency") } } } } };
function diagnose(s) {
  let node = tree; const path = [];
  while (node.q) { path.push(node.q + "=" + s[node.q]); node = node[s[node.q]]; }
  return { path: path.join(" > "), ...node };
}
for (const s of [
  { dns: "ok", connect: "refused", listening: "loopback" },
  { dns: "ok", connect: "timeout", synSeen: "no" },
  { dns: "ok", connect: "ok", tls: "expired" },
  { dns: "ok", connect: "ok", tls: "ok", http: 504 },
  { dns: "ok", connect: "ok", tls: "ok", http: 200, slowPhase: "wait" },
]) {
  const r = diagnose(s); console.log(r.path + "\n  next : " + r.cmd + "\n  cause: " + r.cause);
}

dns=ok > connect=refused > listening=loopback
  next : ss -tlnp; check the app bind setting
  cause: app bound to 127.0.0.1 only
dns=ok > connect=timeout > synSeen=no
  next : check security group, route table, public IP
  cause: dropped before the server
dns=ok > connect=ok > tls=expired
  next : openssl x509 -noout -enddate
  cause: expired, or old certificate still served
dns=ok > connect=ok > tls=ok > http=504
  next : tail nginx error.log; check app and DB
  cause: upstream too slow: read timeout
dns=ok > connect=ok > tls=ok > http=200 > slowPhase=wait
  next : app logs, DB slow query log
  cause: server work: app, DB, dependency

১০ · AI-এর যুগে network সমস্যা খোঁজা

AI আউটপুট পড়তে খুব ভালো সাহায্য করে। কিন্তু সে আপনার server দেখতে পায় না, আর তাড়াহুড়োর মধ্যে “কাজ চালানোর” পরামর্শ দিতে ভালোবাসে। Network-এর ক্ষেত্রে সেই পরামর্শ প্রায়ই নিরাপত্তা ভেঙে দেয়।

AI-এর দেওয়া সমাধান হাতে পেলে

• প্রতিটি কমান্ড কী বদলায় বুঝেছি, আর শুধু-পড়ার কমান্ড আগে চালিয়েছি
• Flag আর অপশন man পাতা বা official docs-এ মিলিয়েছি
• Firewall বদলানোর আগে একটি SSH সংযোগ খোলা রেখেছি, আর ফেরার পথ ভেবেছি
• কোনো port সব জায়গা থেকে খুলিনি; 0.0.0.0/0 থাকলে কারণ লিখে রেখেছি
• প্রথমে পরীক্ষার পরিবেশে চালিয়েছি, আর ধ্বংসাত্মক কমান্ডে বিশেষ সতর্ক থেকেছি
• Prompt-এ কোনো secret বা ব্যবহারকারীর ডেটা দিইনি
• সমাধানের পরে বাইরে থেকে যাচাই করেছি, আর আসল কারণ লিখে রেখেছি