পরিস্থিতিভিত্তিক ইন্টারভিউ — “google.com লিখে Enter চাপলে” আর সমস্যা খোঁজা

উত্তর: ঠিকানা-বার (omnibox) কিছু নিয়ম দেখে: ফাঁকা জায়গা নেই, বিন্দু আছে, শেষ অংশটি পরিচিত TLD — তাহলে সম্ভবত host name; নইলে search engine-এ খোঁজ। নিয়ম ব্রাউজারভেদে আলাদা। Scheme না লিখলে ব্রাউজার আগে HSTS-এর তালিকা দেখে; সেখানে থাকলে HTTPS. না থাকলে আধুনিক ব্রাউজারগুলো এখন সাধারণত আগে HTTPS চেষ্টা করে, ব্যর্থ হলে HTTP-তে ফেরে — কিন্তু এই আচরণ ব্রাউজার আর সংস্করণভেদে আলাদা, তাই ইন্টারভিউতে “অনেক আধুনিক ব্রাউজার” বলুন। পুরোনো আচরণে প্রথম অনুরোধ যেত http://-তে, আর সার্ভার 301 দিয়ে HTTPS-এ পাঠাত — এক বাড়তি round trip আর নিরাপত্তার ফাঁক।

উত্তর: সাধারণ DNS UDP-তে, এনক্রিপশন বা স্বাক্ষর ছাড়া — তাই পথের কেউ ভুল ঠিকানা দিতে পারে, বা resolver-এর cache-এ ভুল তথ্য ঢোকানোর চেষ্টা (cache poisoning) হতে পারে (পর্ব ৩৫, ৫০)। প্রতিরক্ষা কয়েক স্তরে: resolver random query ID আর random উৎস port ব্যবহার করে অনুমান কঠিন করে; DNSSEC উত্তরের স্বাক্ষর যাচাই করতে দেয় (যদি ডোমেইন স্বাক্ষর করে আর resolver যাচাই করে); DNS-over-HTTPS বা DNS-over-TLS ল্যাপটপ থেকে resolver পর্যন্ত পথ এনক্রিপ্ট করে। আর সবচেয়ে গুরুত্বপূর্ণ কথা: ভুল ঠিকানা পেলেও TLS বাঁচায় — আক্রমণকারীর সার্ভারের কাছে www.example.com-এর বৈধ certificate নেই, তাই ব্রাউজার সতর্কবার্তা দেখাবে। এজন্যই HSTS আর TLS মিলে DNS-এর দুর্বলতার অনেকটা ঢেকে দেয়।

উত্তর: তিনটি বড় পরিবর্তন। (১) ARP-এর বদলে NDP — neighbor solicitation যায় multicast-এ, broadcast-এ নয় (পর্ব ২১)। (২) সাধারণত NAT নেই: ল্যাপটপের global ঠিকানা (SLAAC বা DHCPv6 থেকে) সরাসরি ইন্টারনেটে যায়, আর router-এর stateful firewall আগের মতো অনাহূত inbound আটকায়। (৩) DNS-এ AAAA record; দুটো ঠিকানা থাকলে Happy Eyeballs (RFC 8305) সামান্য আগে IPv6 চেষ্টা করে, দেরি হলে IPv4-ও শুরু করে। এ ছাড়া IPv6-এ router পথে fragment করে না, তাই Path MTU Discovery আর ICMPv6 “Packet Too Big” বার্তা চলতে দেওয়া আরও জরুরি — এটি কেস ২ আর ৩-এর সাথে যুক্ত।

উত্তর: দুটি প্রচলিত পথ। (১) Alt-Svc header: প্রথম ভিজিট চলে TCP-র ওপর HTTP/2-তে; উত্তরে alt-svc: h3=":443" থাকলে ব্রাউজার মনে রাখে, আর পরের অনুরোধ বা পরের ভিজিটে QUIC চেষ্টা করে। (২) DNS-এর HTTPS record (RFC 9460): DNS-এর উত্তরেই alpn="h3" জানানো যায়, তাই প্রথম সংযোগই QUIC হতে পারে। QUIC UDP-তে চলে, আর কিছু নেটওয়ার্ক UDP 443 আটকায়; তাই ব্রাউজার সাধারণত TCP-র সাথে একটি দৌড় রাখে বা ব্যর্থ হলে TCP-তে ফেরে। তাই উত্তর: “প্রথম ভিজিটে সাধারণত না, যদি না HTTPS record থাকে; আর সবসময় TCP-তে ফেরার পথ থাকে।” (পর্ব ৩৩, ৩৭)

উত্তর: আগে ভাগ করে মাপুন — অনুমান নয়। curl -w দিয়ে নেটওয়ার্কের অংশ: time_namelookup (DNS), time_connect (TCP), time_appconnect (TLS), time_starttransfer (প্রথম বাইট), time_total. ব্রাউজারের DevTools-এর Network আর Performance ট্যাবে প্রতিটি অনুরোধের waterfall. যদি HTML-এর প্রথম বাইট ৩৫০ ms-এ আসে, তাহলে বাকি সময় নেটওয়ার্কের নয় — বড় JS, render-আটকানো CSS, তৃতীয় পক্ষের script বা অনেক ছোট ছোট অনুরোধ। যদি time_starttransfer নিজেই ২.৫ সেকেন্ড হয়, তাহলে origin ধীর বা cache miss. যদি DNS-ই ১ সেকেন্ড, তাহলে resolver-এর সমস্যা (প্রথম চেষ্টা হারিয়ে timeout-এর পর দ্বিতীয় চেষ্টা প্রায়ই ঠিক ১ বা ৫ সেকেন্ডের মতো গোল সংখ্যার দেরি দেখায়)। Loss থাকলে retransmission দেখুন — ss -ti-তে retrans. পর্ব ৫৬-এর নিয়মটি মনে রাখুন: মাপুন, ভাগ করুন, সবচেয়ে বড় অংশটি আগে ঠিক করুন।

যে প্রশ্ন করবেন: শুধু এই নাম, নাকি সব নাম (বাইরের সাইটও)? সবার ক্ষেত্রে, নাকি এক VLAN বা Wi-Fi-তে? রাতে কোনো পরিবর্তন — DNS record, resolver, firewall? Error বার্তাটি ঠিক কী — NXDOMAIN নাকি timeout?

অনুমান (সম্ভাবনার ক্রমে): (ক) DHCP-তে দেওয়া resolver চলছে না বা উত্তর জোগাড় করতে পারছে না; (খ) record মুছে গেছে বা বদলেছে, আর negative caching চলছে; (গ) কোনো যন্ত্রে /etc/hosts-এ পুরোনো লাইন; (ঘ) split-horizon DNS-এ ভেতরের view ভুল।

$ curl -sI --resolve intranet.example.com:443:10.0.5.20 https://intranet.example.com/ | head -1
HTTP/1.1 200 OK                          # সার্ভার, TCP, TLS ঠিক — সমস্যা নামে
$ getent hosts intranet.example.com      # (কিছুই আসে না)
$ resolvectl status | grep 'DNS Servers'
       DNS Servers: 10.0.0.53
$ dig @10.0.0.53 intranet.example.com +short
;; communications error to 10.0.0.53#53: timed out
$ dig @10.0.0.54 intranet.example.com +short
10.0.5.20                                 # দ্বিতীয় resolver ঠিক উত্তর দেয়

যুক্তি: --resolve দিয়ে নাম-খোঁজা বাদ রেখে একই নামে HTTPS চালানো গেল — অর্থাৎ নেটওয়ার্ক, সার্ভার আর certificate ঠিক। getent খালি, প্রথম resolver timeout, দ্বিতীয়টি ঠিক। NXDOMAIN নয়, timeout — তাই record নয়, resolver-এর সমস্যা।

মূল কারণ: রাতের রক্ষণাবেক্ষণে 10.0.0.53-এর DNS সার্ভিস আর চালু হয়নি, আর DHCP সবাইকে শুধু এই একটি resolver দিচ্ছিল। সমাধান: সার্ভিস চালু করা; DHCP option 6-এ দুটি resolver দেওয়া। প্রতিরোধ: প্রতিটি resolver-এর ওপর একটি synthetic check (প্রতি মিনিটে একটি পরিচিত নাম খোঁজা আর alert), রক্ষণাবেক্ষণের পরে যাচাইয়ের তালিকা। মনে রাখুন: IP দিয়ে HTTPS খুললে certificate-এর নাম মেলে না — তাই ইন্টারভিউতে --resolve বা Host header-এর কৌশলটি বলুন।

যে প্রশ্ন করবেন: একটি অপারেটরে, নাকি সব মোবাইল নেটওয়ার্কে? ব্রাউজারে সাইট খোলে কি? সব অনুরোধ ব্যর্থ, নাকি শুধু বড় অনুরোধ? DNS-এ ঠিক কোন record যোগ হয়েছে?

অনুমান: (ক) ওই অপারেটরের নেটওয়ার্ক IPv6-only বা IPv6-প্রধান (NAT64/DNS64, 464XLAT), আর নতুন AAAA record যে IPv6 ঠিকানা দেখায় সেখানে সার্ভিস পৌঁছানো যায় না; (খ) মোবাইল পথে MTU ছোট (কেস ৩-এর মতো); (গ) উল্টো দিকের সমস্যা — ব্যবহারকারী CGNAT-এর পেছনে থেকে বাসার কোনো সার্ভারে port forward দিয়ে ঢুকতে চাইছেন।

$ dig +short AAAA api.example.com
2001:db8:10::20                           # গত সপ্তাহে যোগ হওয়া record
$ curl -4 -sS -m 5 -o /dev/null -w '%{http_code}\n' https://api.example.com/health
200
$ curl -6 -sS -m 5 -o /dev/null -w '%{http_code}\n' https://api.example.com/health
curl: (28) Connection timed out after 5001 milliseconds
000

যুক্তি: IPv6 পথে timeout, IPv4-এ ঠিক। Wi-Fi-তে অ্যাপটি IPv4 পায় বা Happy Eyeballs IPv4-এ ফিরে যায়। কিন্তু IPv6-only মোবাইল নেটওয়ার্কে IPv4-এ পৌঁছানোর একমাত্র উপায় DNS64-এর বানানো ঠিকানা — আর আসল AAAA থাকলে DNS64 আর বানায় না। ফলে ফোনের কাছে একটিমাত্র পথ, আর সেটি ভাঙা।

মূল কারণ: AAAA প্রকাশ করা হয়েছে, কিন্তু cloud-এর security group-এ port 443 খোলা ছিল শুধু 0.0.0.0/0-এর জন্য, ::/0-এর জন্য নয়। সমাধান: IPv6-এর নিয়ম যোগ করা (বা IPv6 পুরো তৈরি না হওয়া পর্যন্ত AAAA সরানো)। প্রতিরোধ: বাইরে থেকে IPv4 আর IPv6 দুই পথেই আলাদা monitoring; “AAAA যোগ করা = IPv6-এর পূর্ণ প্রস্তুতি” — এই নিয়ম পরিবর্তনের তালিকায়। CGNAT-এর দিক: যদি ব্যবহারকারীর router-এর WAN ঠিকানা 100.64.0.0/10-এর ভেতরে হয় (RFC 6598-এর shared address space), তাহলে তিনি ISP-র NAT-এর পেছনে — বাইরে থেকে port forward দিয়ে তাঁর যন্ত্রে ঢোকা যাবে না; তখন IPv6, ISP-র public IP সেবা বা একটি বাইরের relay লাগে।

যে প্রশ্ন করবেন: VPN বা কোনো tunnel কি নতুন? ISP কি PPPoE ব্যবহার করে? Firewall-এ ICMP-র নিয়ম কী? সমস্যা কি শুধু tunnel-এর ভেতরের traffic-এ?

অনুমান: “ছোট চলে, বড় আটকায়” মানেই প্রথম সন্দেহ MTU: tunnel-এর header জায়গা খায়, তাই পথের MTU ১৫০০-এর কম; TCP পুরো ১৪৬০ বাইটের segment পাঠায় DF bit দিয়ে; router ফেলে দিয়ে ICMP “Fragmentation Needed” পাঠায়; কিন্তু কোনো firewall সেই ICMP আটকায় — প্রেরক কখনো জানে না। এটিই PMTUD black hole. বিকল্প: loss বা ধীর link — কিন্তু তাতে বড়-ছোট এমন পরিষ্কার ভাগ হয় না।

$ ping -c 2 -M do -s 1472 10.20.0.15      # 1472 + 8 ICMP + 20 IP = 1500
2 packets transmitted, 0 received, 100% packet loss    # কোনো "Frag needed" বার্তাও নেই
$ ping -c 2 -M do -s 1412 10.20.0.15      # 1412 + 28 = 1440
2 packets transmitted, 2 received, 0% packet loss
$ tracepath -n 10.20.0.15
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.10.0.1                         1.1ms
 2:  no reply
$ sudo tcpdump -ni eth0 'host 10.20.0.15 and tcp'
10:02:11.104 IP 10.10.0.50.51800 > 10.20.0.15.443: Flags [.], seq 1:1449, ack 1, length 1448
10:02:11.320 IP 10.10.0.50.51800 > 10.20.0.15.443: Flags [.], seq 1:1449, ack 1, length 1448   # retransmission
10:02:11.760 IP 10.10.0.50.51800 > 10.20.0.15.443: Flags [.], seq 1:1449, ack 1, length 1448   # আবার

যুক্তি: ১৫০০ বাইটের packet নিঃশব্দে হারায়, ১৪৪০ পৌঁছায় — পথের MTU ১৪৪০-এর আশপাশে, আর ICMP-র সতর্কবার্তা ফিরছে না। Capture-এ একই পূর্ণ segment বারবার retransmit হচ্ছে, timeout দ্বিগুণ হচ্ছে (পর্ব ৩০-এর exponential backoff). length 1448 কারণ TCP timestamps option ১২ বাইট নেয় (১৪৬০ − ১২)।

মূল কারণ: নতুন tunnel-এর MTU ১৪৪০, আর পথের একটি firewall সব ICMP আটকায়। সমাধান: tunnel-এর router-এ MSS clamping — SYN-এর MSS কমিয়ে ১৪০০ করা (Linux-এ nftables-এ tcp flags syn tcp option maxseg size set rt mtu), আর firewall-এ ICMP type 3 code 4 (IPv6-এ ICMPv6 Packet Too Big) চলতে দেওয়া। প্রতিরোধ: “ICMP পুরো বন্ধ” নীতি বাতিল; প্রতিটি tunnel চালুর সময় ping -M do দিয়ে MTU যাচাই। নিচের হিসাবে সাধারণ encapsulation-এর পর কত MTU আর MSS থাকে, তা দেখুন।

যে প্রশ্ন করবেন: 502-গুলো কি সব সার্ভারে সমান? Deploy-এর সময় বাড়ে? LB-র log-এ backend-এর দিকের কারণ কী লেখা (connection reset, timeout)? LB-র idle timeout কত, আর অ্যাপ সার্ভারের keep-alive timeout কত?

অনুমান: (ক) keep-alive timeout-এর অমিল — backend আগে idle সংযোগ বন্ধ করে, আর ঠিক সেই মুহূর্তে LB সেটিতে নতুন অনুরোধ পাঠায়; (খ) deploy-এর সময় connection draining ছাড়া সার্ভার বন্ধ; (গ) health check সুস্থ বলে, অথচ অ্যাপের কোনো worker আটকে; (ঘ) backend crash বা OOM — কিন্তু তাহলে সার্ভারের log বা metric-এ ছাপ থাকত।

# LB log (উদাহরণ): 502-এর লাইনগুলোতে backend সময় শূন্য, কারণ "upstream reset"
2026-10-20T02:14:07Z GET /api/cart 502 backend=10.0.1.21:8080 backend_time=0.000 reason=upstream_reset
# অ্যাপ সার্ভারে capture — LB 10.0.0.5, সার্ভার 10.0.1.21
02:14:07.000100 IP 10.0.1.21.8080 > 10.0.0.5.40112: Flags [F.]  # সার্ভার idle সংযোগ বন্ধ করছে
02:14:07.000350 IP 10.0.0.5.40112 > 10.0.1.21.8080: Flags [P.], length 412  # LB ঠিক তখনই অনুরোধ পাঠাল
02:14:07.000420 IP 10.0.1.21.8080 > 10.0.0.5.40112: Flags [R]   # বন্ধ socket — RST
# config: LB idle timeout = 60 s ; app server keep-alive timeout = 5 s

যুক্তি: backend সময় শূন্য আর সার্ভারের log-এ অনুরোধ নেই — অনুরোধ অ্যাপে পৌঁছায়ইনি। Capture-এ FIN আর অনুরোধ প্রায় একই মুহূর্তে উল্টো দিকে চলেছে — একটি দৌড় (race). রাতে হার বেশি, কারণ তখন সংযোগগুলো বেশিক্ষণ অলস থাকে আর ৫ সেকেন্ডের সীমা পেরোয়। নিচের stepper-এ দৌড়টি ধাপে ধাপে দেখুন।

মূল কারণ: সার্ভারের keep-alive timeout (৫ সেকেন্ড — কিছু runtime-এ, যেমন Node.js-এর HTTP সার্ভারে, এটিই ডিফল্ট) LB-র idle timeout (৬০ সেকেন্ড)-এর চেয়ে ছোট। সমাধান: backend-এর timeout LB-র চেয়ে বড় রাখা (যেমন ৬৫ সেকেন্ড), যাতে সবসময় LB আগে বন্ধ করে; idempotent অনুরোধে LB-র একবার retry; deploy-এ draining. প্রতিরোধ: দুই পাশের timeout একসাথে লিখে রাখা নিয়ম, 5xx-এর হারে alert, আর LB আর backend-এর 502-কে আলাদা metric-এ দেখা।

যে প্রশ্ন করবেন: timeout নাকি “connection refused”? সব জায়গা থেকে, নাকি এক নেটওয়ার্ক থেকে? VM-এর সামনে কোন কোন firewall স্তর আছে — cloud-এর security group, subnet-এর ACL, VM-এর নিজের nftables বা firewalld?

অনুমান: timeout মানে কেউ SYN নিঃশব্দে ফেলছে। (ক) security group-এ শুধু ২২ খোলা; (খ) VM-এর host firewall; (গ) nginx শুধু 127.0.0.1-এ শুনছে — কিন্তু তাহলে বাইরে থেকে timeout নয়, সাধারণত refused (RST) আসত।

$ nc -vz -w 5 203.0.113.30 22
Connection to 203.0.113.30 22 port [tcp/ssh] succeeded!
$ nc -vz -w 5 203.0.113.30 443
nc: connect to 203.0.113.30 port 443 (tcp) timed out: Operation now in progress
# VM-এর ভেতরে:
$ ss -ltn 'sport = :443'
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
LISTEN  0       511           0.0.0.0:443        0.0.0.0:*
$ sudo tcpdump -ni eth0 -c 5 'tcp port 443'
(বাইরে থেকে চেষ্টার সময়েও কোনো packet আসে না)

যুক্তি: nginx সব ঠিকানায় শুনছে, তাই (গ) বাদ। VM-এর interface-এ SYN আসছেই না — তাই host firewall-ও নয় (সে দেখত, তারপর ফেলত; tcpdump host firewall-এর আগেই packet দেখে)। বাকি থাকে VM-এর বাইরের স্তর: security group বা ACL.

মূল কারণ: security group-এ inbound নিয়ম শুধু TCP 22. সমাধান: TCP 443 (আর HTTP থেকে redirect চাইলে 80) 0.0.0.0/0 ও ::/0-এর জন্য খোলা; SSH-কে উল্টো দিকে সংকীর্ণ করা — শুধু অফিসের ঠিকানা বা VPN থেকে। প্রতিরোধ: firewall-এর নিয়ম কোডে (infrastructure as code) আর review-তে; চালুর পরে বাইরে থেকে স্বয়ংক্রিয় port-যাচাই — শুধু নিজের সিস্টেমে। “সব খুলে দিই” কখনো সমাধান নয়।

যে প্রশ্ন করবেন: ধীর মানে কোন অংশ — DNS, connect, প্রথম বাইট, নাকি পুরো download? ব্যবহারকারীরা কোন DNS resolver ব্যবহার করেন — ISP-র নাকি দূরের public resolver? দুদিন আগে CDN, DNS বা ISP-র দিকে কিছু বদলেছে?

অনুমান: (ক) ওই ISP থেকে CDN পর্যন্ত পথ বদলেছে — স্থানীয় peering বা IXP-র link বন্ধ, traffic এখন বিদেশের transit ঘুরে আসে; (খ) CDN ভুল edge বেছে দিচ্ছে, কারণ resolver-এর অবস্থান দেখে mapping হয় (ECS না থাকলে); (গ) ISP-র কোনো link-এ congestion — তখন peak সময়ে বেশি খারাপ।

# আক্রান্ত ISP-র একজন ব্যবহারকারীর অনুমতিতে, তাঁর যন্ত্র থেকে:
$ curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  ttfb %{time_starttransfer}\n' https://www.example.com/
dns 0.012  connect 0.191  ttfb 0.402          # অন্য ISP-তে connect ≈ 0.025
$ dig +short www.example.com
192.0.2.80                                     # সঠিক anycast ঠিকানা
$ mtr -rwzc 30 192.0.2.80
  1. AS???   192.168.1.1        0.0%   1.2 ms
  2. AS64500 198.51.100.1       0.0%   4.8 ms
  3. AS64500 198.51.100.66      0.0%   6.1 ms
  4. AS64510 203.0.113.9        0.0%  88.4 ms   # বিদেশের transit-এ চলে গেছে
  5. AS64510 203.0.113.41       0.0% 176.0 ms
  6. AS64496 192.0.2.80         0.0% 189.7 ms

যুক্তি: DNS দ্রুত আর ঠিকানা সঠিক — তাই (খ) এখানে নয়। connect নিজেই ১৯১ ms, অর্থাৎ RTT বড় — দূরত্বের সমস্যা, সার্ভারের নয়। mtr দেখাচ্ছে ISP (AS64500) থেকে সরাসরি CDN-এর নেটওয়ার্কে না গিয়ে একটি transit (AS64510)-এ যাচ্ছে, যেখানে RTT হঠাৎ ৮৮ ms-এ লাফায় — সাধারণত সমুদ্রের নিচের cable পেরোনোর চিহ্ন। Loss নেই, তাই congestion-এর চেয়ে পথের পরিবর্তন বেশি সম্ভাব্য। (ASN-গুলো documentation-এর জন্য সংরক্ষিত।)

মূল কারণ: ISP আর CDN-এর মধ্যে স্থানীয় peering session বন্ধ হয়ে গিয়েছিল, BGP বিকল্প পথ বেছেছে — বিদেশ ঘুরে। সমাধান: প্রমাণসহ (সময়, mtr, ASN, ঠিকানা) ISP আর CDN দুই পক্ষকেই জানানো; CDN সাময়িকভাবে ওই ISP-কে অন্য edge-এ পাঠাতে পারে। প্রতিরোধ: ISP আর শহর ধরে real-user metric-এ alert; একাধিক IXP-তে peering; দেশের ভেতরের traffic দেশের ভেতরে রাখতে স্থানীয় IXP-তে উপস্থিতি (বাংলাদেশে যেমন BDIX). মনে রাখুন: ইন্টারনেটের পথ আপনার নিয়ন্ত্রণে নয় — আপনার কাজ প্রমাণ জোগাড় করে সঠিক মানুষের কাছে পৌঁছানো।

যে প্রশ্ন করবেন: error-এর হুবহু বার্তা কী? কোন যন্ত্র, কোন OS-এর কোন সংস্করণ? সার্ভারে certificate ফাইল কীভাবে বসানো হয়েছে — শুধু leaf, নাকি full chain? আক্রান্ত যন্ত্রের ঘড়ি ঠিক আছে?

অনুমান: তিনটি আলাদা সমস্যা একসাথে দেখা দিতে পারে — (ক) সার্ভার intermediate certificate পাঠাচ্ছে না; ডেস্কটপ ব্রাউজার cache-এ রাখা intermediate বা AIA fetching দিয়ে শিকল নিজে পূর্ণ করে, অ্যাপ আর curl করে না; (খ) পুরোনো যন্ত্রের trust store-এ নতুন root নেই, বা পুরোনো root-এর মেয়াদ শেষ; (গ) ল্যাপটপের ঘড়ি পেছনে — নতুন certificate তার চোখে “এখনো শুরুই হয়নি”।

$ openssl s_client -connect shop.example.com:443 -servername shop.example.com -showcerts </dev/null 2>/dev/null | grep -E 's:|i:|Verify'
 0 s:CN = shop.example.com
   i:CN = Example Issuing CA R2
Verify return code: 21 (unable to verify the first certificate)
# শুধু depth 0 — intermediate নেই। ঠিক করার পরে:
 0 s:CN = shop.example.com
   i:CN = Example Issuing CA R2
 1 s:CN = Example Issuing CA R2
   i:CN = Example Root CA X1
Verify return code: 0 (ok)
# ঘড়ির সমস্যার ল্যাপটপে:
$ date -u ; timedatectl | grep synchronized
Mon Jan  5 09:12:44 UTC 2026
System clock synchronized: no

মূল কারণ ও সমাধান: (ক) সার্ভারে leaf-এর বদলে full chain বসানো (nginx-এ ssl_certificate-এ fullchain ফাইল); (খ) পুরোনো যন্ত্রে OS আপডেট, বা সেই যন্ত্রগুলোর জন্য আলাদা chain-এর বিকল্প — ২০২১ সালের সেপ্টেম্বরে Let’s Encrypt-এর certificate যে পুরোনো root দিয়ে cross-sign করা ছিল (IdenTrust-এর DST Root CA X3), তার মেয়াদ শেষ হলে অনেক পুরোনো যন্ত্রে ঠিক এমন ঘটেছিল; (গ) ঘড়ি — NTP চালু করা। প্রতিরোধ: deploy-এর পরে “পরিষ্কার” পরিবেশ থেকে (openssl s_client, ব্রাউজার নয়) chain যাচাই; মেয়াদ শেষের আগে alert; স্বয়ংক্রিয় নবায়ন। ইন্টারভিউতে মূল কথা: “ব্রাউজারে চলে” প্রমাণ নয় — ব্রাউজার অনেক ভুল নিজে ঢেকে দেয়।

যে প্রশ্ন করবেন: নাম খোঁজা ব্যর্থ, নাকি সংযোগ? কোন নাম ব্যবহার হচ্ছে — শুধু api, নাকি পূর্ণ নাম? Cluster-এ NetworkPolicy আছে কি, আর কোন CNI? নতুন pod-এর label কী?

অনুমান (স্তর ধরে): (ক) DNS — অন্য namespace-এর service-কে শুধু api নামে ডাকলে নিজের namespace-এ খোঁজে, পাওয়া যায় না; (খ) service-এর selector কোনো pod-এ মেলে না, তাই endpoint খালি; (গ) NetworkPolicy নতুন pod-কে অনুমতি দেয় না; (ঘ) pod-এর ভেতরের অ্যাপের ভুল port.

$ kubectl -n shop exec deploy/web -- getent hosts api.payments.svc.cluster.local
10.96.41.7      api.payments.svc.cluster.local          # DNS ঠিক
$ kubectl -n payments get endpointslices -l kubernetes.io/service-name=api
NAME        ADDRESSTYPE   PORTS   ENDPOINTS                 AGE
api-7xk2p   IPv4          8080    10.244.1.12,10.244.2.9    41d    # endpoint আছে
$ kubectl -n payments get networkpolicy
NAME                 POD-SELECTOR   AGE
default-deny-ingress <none>          30d
allow-from-checkout  app=api        30d
$ kubectl -n payments get networkpolicy allow-from-checkout -o jsonpath='{.spec.ingress[0].from}'
[{"namespaceSelector":{"matchLabels":{"kubernetes.io/metadata.name":"shop"}},"podSelector":{"matchLabels":{"app":"checkout"}}}]
$ kubectl -n shop get pod -l app=web --show-labels | tail -1
web-5d9c7b-q2xlm   1/1   Running   0   2h   app=web,pod-template-hash=5d9c7b

যুক্তি: নাম মেলে, endpoint আছে — তাই DNS আর service নয়। payments-এ default-deny নীতি, আর ব্যতিক্রম শুধু shop namespace-এর app=checkout label-ধারী pod-এর জন্য। নতুন pod-এর label app=web — নীতি তাকে চেনে না, তাই তার SYN নিঃশব্দে পড়ে যায়: timeout, refused নয়।

মূল কারণ: NetworkPolicy-তে নতুন client যোগ হয়নি। সমাধান: একটি label যেমন payments-client=true দিয়ে নীতি লেখা, আর দরকারি pod-এ সেই label দেওয়া — প্রতিটি নতুন অ্যাপে নীতি বদলানোর চেয়ে পরিষ্কার। প্রতিরোধ: নীতিগুলো কোডে আর review-তে; CI-তে “কে কাকে ডাকতে পারে” পরীক্ষা; দলের মধ্যে নিয়ম জানানো। বাড়তি ফাঁদ: pod-এর resolv.conf-এ ndots:5 ডিফল্ট, তাই বাইরের নাম খুঁজতে অনেক বাড়তি DNS query হয় — ধীর DNS-এর কেসে এটি মনে রাখুন।

যে প্রশ্ন করবেন: সমস্যা কি upload-এর সাথে মেলে? Wi-Fi-তে নাকি তারেও? কলের দুই দিকেই, নাকি এক দিকে? Router-এ কোন queue ব্যবস্থা?

অনুমান: (ক) bufferbloat — upload link ভরে গেলে router বা modem-এর বড় buffer-এ packet জমে, সব packet-এর delay বাড়ে, VoIP-এর jitter buffer আর সামলাতে পারে না; (খ) Wi-Fi-তে airtime-এর ভিড়; (গ) ISP-র দিকে congestion.

# অলস অবস্থায়:
$ ping -c 20 -q 198.51.100.1
rtt min/avg/max/mdev = 7.9/8.4/9.6/0.4 ms
# একজন সহকর্মী বড় backup চালু করার পরে (upload পূর্ণ):
$ ping -c 20 -q 198.51.100.1
rtt min/avg/max/mdev = 312.6/447.1/583.0/71.8 ms
$ tc -s qdisc show dev wan0
qdisc pfifo_fast 0: root refcnt 2 bands 3
 Sent 81234567 bytes 70211 pkt (dropped 12, overlimits 0 requeues 3)
 backlog 0b 0p requeues 3                      # জমা হচ্ছে modem-এ, router-এ নয়

যুক্তি: loss প্রায় নেই, কিন্তু চাপে RTT ৮ থেকে ৪৪৭ ms — buffer ভরে থাকার ক্লাসিক চিহ্ন (queueing delay, পর্ব ০৫)। Router-এর নিজের queue খালি, কারণ সে link-এর চেয়ে দ্রুত পাঠিয়ে দেয় — জমে modem-এ, যেখানে আমাদের নিয়ন্ত্রণ নেই।

মূল কারণ: upload-এর ভিড়ে modem-এর বড় buffer. সমাধান: router-এ SQM — upload-কে link-এর চেয়ে সামান্য কম হারে (প্রায় ৮৫–৯৫%) shape করে queue নিজের কাছে আনা, আর সেখানে fq_codel বা CAKE-এর মতো ন্যায্য ও ছোট-queue ব্যবস্থা; LAN-এ voice-এ DSCP EF চিহ্ন আর Wi-Fi-তে WMM; backup-কে রাতে বা হার-সীমায়। প্রতিরোধ: “লোডের সময়ের latency” মাপা নিয়মিত; capacity পরিকল্পনা। সতর্কতা: DSCP চিহ্ন সাধারণত আপনার নিজের নেটওয়ার্কের ভেতরে কাজ করে; ISP সাধারণত তা মানে না।

যে প্রশ্ন করবেন: Camera-র switch port কি VLAN 30-এর access port? Trunk-এ VLAN 30 অনুমোদিত? VLAN-গুলোর মধ্যে routing কে করে — L3 switch না router? DHCP সার্ভারে নতুন scope বানানো হয়েছে?

অনুমান: DHCP DISCOVER একটি broadcast — router পেরোয় না (পর্ব ১৮)। তাই অন্য subnet-এর সার্ভারের জন্য VLAN 30-এর gateway-তে DHCP relay লাগে। সম্ভাব্য কারণ: (ক) relay (Cisco-ধাঁচে ip helper-address) নেই; (খ) সার্ভারে 10.0.30.0/24-এর scope নেই; (গ) trunk-এ VLAN 30 নেই; (ঘ) মাঝের firewall UDP 67 আটকায়।

# L3 switch-এ (উদাহরণ, Cisco IOS-ধাঁচ):
switch# show running-config interface Vlan30
interface Vlan30
 ip address 10.0.30.1 255.255.255.0          ! helper-address নেই
switch# show interfaces trunk | include 30
Gi1/0/48    1,10,20,30                        ! trunk-এ VLAN 30 আছে
# DHCP সার্ভারে capture — কিছুই আসে না:
$ sudo tcpdump -ni eth0 -c 5 'udp port 67'
(নীরব)

যুক্তি: trunk ঠিক, কিন্তু VLAN 30-এর gateway-তে relay নেই — তাই broadcast VLAN 30-এর ভেতরেই মরে যায়, সার্ভারে কিছু পৌঁছায় না।

মূল কারণ: relay কনফিগার করা হয়নি। সমাধান: interface Vlan30-এ ip helper-address 10.0.0.10 (অন্য vendor-এ নাম আলাদা); relay প্যাকেটে giaddr = 10.0.30.1 বসায়, আর সার্ভার সেটি দেখেই সঠিক scope বাছে — তাই সার্ভারে 10.0.30.0/24-এর scope (gateway 10.0.30.1-সহ) লাগবে, আর পথে UDP 67 চলতে দিতে হবে। প্রতিরোধ: “নতুন VLAN-এর চেকলিস্ট”: VLAN, trunk, SVI, relay, scope, firewall-এর নিয়ম, DHCP snooping-এর trusted port. Camera-র VLAN-কে বাকি নেটওয়ার্ক থেকে ACL দিয়ে আলাদা রাখুন (পর্ব ৫৭)।

যে প্রশ্ন করবেন: সংযোগ কে বন্ধ করে — client না সার্ভার? HTTP client-এ keep-alive বা connection pool চালু? গন্তব্য একটিই ঠিকানা আর port?

অনুমান: যে পক্ষ আগে বন্ধ করে, TIME-WAIT তার কাছে থাকে (পর্ব ২৯)। Linux-এ TIME-WAIT ৬০ সেকেন্ড। একটি নির্দিষ্ট (উৎস IP, গন্তব্য IP, গন্তব্য port)-এর জন্য ভিন্ন সংযোগ মানে ভিন্ন উৎস port — আর ডিফল্ট ephemeral port-এর পরিসর সীমিত। তাই সন্দেহ: port exhaustion.

$ ss -s | grep -i timewait
TCP:   28771 (estab 312, closed 28301, orphaned 0, timewait 28233)
$ ss -Htan state time-wait dst 203.0.113.10 | wc -l
28221
$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768	60999

যুক্তি: প্রায় সব port TIME-WAIT-এ, আর গন্তব্য একটিই। নিচের হিসাব দেখায় কেন এটি অনিবার্য ছিল।

মূল কারণ: প্রতি অনুরোধে নতুন সংযোগ, আর client নিজেই বন্ধ করে। সমাধান (পছন্দের ক্রমে): (১) সংযোগ পুনর্ব্যবহার — HTTP keep-alive আর connection pool, বা HTTP/2-এ এক সংযোগে বহু অনুরোধ; (২) দরকার হলে port-এর পরিসর বাড়ানো; (৩) একাধিক গন্তব্য ঠিকানা বা উৎস ঠিকানা; (৪) Linux-এ net.ipv4.tcp_tw_reuse — শুধু বাইরে যাওয়া সংযোগে আর TCP timestamps চালু থাকলে নিরাপদে TIME-WAIT-এর port আবার নেয়। পুরোনো tcp_tw_recycle NAT-এর পেছনের client-দের ভাঙত, আর Linux 4.12-এ সরিয়ে ফেলা হয়েছে — AI বা পুরোনো ব্লগ এটি বললে বিশ্বাস করবেন না। প্রতিরোধ: TIME-WAIT আর ব্যবহৃত port-এর সংখ্যায় metric আর alert; load test-এ প্রকৃত হারে নতুন সংযোগ মাপা। মনে রাখুন, TIME-WAIT কোনো বাগ নয় — দেরিতে আসা পুরোনো segment থেকে নতুন সংযোগকে বাঁচায়।

আগে প্রশ্ন: কোন কোন অ্যাপ — ভেতরের ERP, ইমেইল, VoIP, ভিডিও কল? কতটা প্রাপ্যতা দরকার — ইন্টারনেট বন্ধ হলে কাজ থামবে কি? অতিথি Wi-Fi, CCTV, প্রিন্টার আছে? বাজেট আর স্থানীয় IT কর্মী আছে কি?

ঠিকানা আর ভাগ: প্রধান অফিসের পরিকল্পনার সাথে না মেলে এমন একটি ব্লক, যেমন 10.20.0.0/16 শাখার জন্য সংরক্ষণ, আর VLAN-এ ভাগ: কর্মী 10.20.10.0/24, VoIP 10.20.20.0/24, CCTV 10.20.30.0/24, অতিথি 10.20.40.0/24 (শুধু ইন্টারনেট), management 10.20.99.0/24. একটি /24-এ ২৫৪টি host — ৬০ জনের দ্বিগুণ বৃদ্ধিতেও যথেষ্ট (পর্ব ১৭)। DHCP স্থানীয়ভাবে, বা প্রধান অফিস থেকে relay দিয়ে — কেস ১০ মনে রাখুন।

পথ আর redundancy: দুটি ভিন্ন ISP (আলাদা পথে আসা fibre হলে ভালো); প্রধান অফিসের সাথে দুটির ওপর দিয়েই site-to-site VPN (IPsec বা WireGuard, পর্ব ৪৯), বা SD-WAN — যা link-এর মান দেখে traffic সরায়। Tunnel-এর MTU আর MSS clamping (কেস ৩)। ইন্টারনেট সরাসরি শাখা থেকে (local breakout), শুধু ভেতরের traffic tunnel-এ।

LAN: একটি বা দুটি access switch (PoE — ফোন, AP, camera-র জন্য), uplink-এ trunk; ছোট অফিসে এক core যথেষ্ট, তবে STP চালু রাখা (পর্ব ১২)। Wi-Fi: কয়েকটি AP, WPA3-Enterprise কর্মীদের জন্য, অতিথির জন্য আলাদা SSID আর VLAN (পর্ব ১৪)।

নিরাপত্তা: শাখার firewall-এ zone: অতিথি → শুধু ইন্টারনেট; CCTV → শুধু recorder; কর্মী → ভেতরের অ্যাপ; management শুধু admin-দের থেকে। DHCP snooping আর port security (পর্ব ৫০)।

VoIP আর QoS: voice VLAN, DSCP EF, আর WAN-এ SQM (কেস ৯)।

পরিচালনা: কেন্দ্রীয় log, SNMP বা telemetry, config-এর backup আর version control, দূর থেকে out-of-band প্রবেশ (যেমন 4G modem-এর মাধ্যমে)।

Trade-off বলুন: দুই ISP খরচ বাড়ায়, কিন্তু একটি বন্ধ হলে পুরো শাখা অচল হওয়ার খরচ বেশি; SD-WAN সহজ পরিচালনা দেয়, কিন্তু vendor-নির্ভরতা বাড়ায়।

আগে প্রশ্ন আর সংখ্যা: কত ব্যবহারকারী, কোন অঞ্চলে? প্রতি সেকেন্ডে কত অনুরোধ, peak কত? Static বনাম dynamic অনুপাত? ৯৯.৯% মানে বছরে প্রায় ৮.৮ ঘণ্টা বন্ধ থাকা যায়; ৯৯.৯৯% মানে প্রায় ৫৩ মিনিট — প্রতিটি “নয়” খরচ অনেক বাড়ায়।

স্তরে স্তরে single point of failure সরানো:

• DNS: দুটি ভিন্ন DNS সরবরাহকারী বা anycast DNS; সঠিক TTL — failover-এ দ্রুত বদলানোর জন্য কম, কিন্তু খুব কম নয় (পর্ব ৩৫)।
• Edge: CDN — static কনটেন্ট, TLS termination, DDoS-এর প্রথম ঢাল (পর্ব ৩৮, ৫০)।
• অঞ্চল আর zone: অন্তত দুটি availability zone-এ সার্ভার; বড় লক্ষ্য হলে দুটি region আর GSLB বা anycast দিয়ে বণ্টন (পর্ব ৫২, ৫৪)।
• Load balancer: নিজেই redundant — managed LB, বা দুটি LB আর VRRP-এর মতো ভাসমান ঠিকানা; health check যা আসল নির্ভরতা (database) মেপে বলে “সুস্থ”, কিন্তু এতটা কঠোর নয় যে database-এর এক মুহূর্তের ধীরতায় সব সার্ভার একসাথে বাদ পড়ে (পর্ব ৫২)।
• Data center-এর ভেতরে: leaf-spine আর ECMP — একটি link বা switch গেলে traffic বাকিগুলোতে ভাগ হয়; সার্ভারে দুটি NIC দুটি switch-এ।
• সংযোগের আচরণ: keep-alive timeout-এর ক্রম (কেস ৪), connection draining, client-এ retry — exponential backoff আর jitter-সহ, যাতে একসাথে সবাই আবার চেষ্টা করে ঝড় না তোলে।
• নিরাপত্তা: শুধু LB public; সার্ভার private subnet-এ; security group-এ ন্যূনতম port (কেস ৫); বাইরে যাওয়া traffic NAT gateway দিয়ে।

পর্যবেক্ষণ: বাইরে থেকে synthetic check বহু অঞ্চল থেকে, IPv4 আর IPv6 দুটোতেই (কেস ২); 5xx-এর হার আর p99 latency-তে alert; failover নিয়মিত অনুশীলন — যে failover কখনো পরীক্ষা হয়নি, সেটি কাজ করবে বলে ধরে নেওয়া যায় না।

Trade-off: বহু-region সক্রিয়-সক্রিয় নকশা ডেটার সামঞ্জস্য কঠিন করে (DBMS · distributed database); সক্রিয়-নিষ্ক্রিয় সহজ, কিন্তু failover-এ কয়েক মিনিট যায়। খরচ, জটিলতা আর লক্ষ্যের মধ্যে আপনি কোথায় দাঁড়ালেন — সেটি স্পষ্ট বলুন।