Firewall আর VPN — nftables, IPsec আর WireGuard

১ · Firewall কী দেখে সিদ্ধান্ত নেয়

একটি অফিস ভবনের গেটে দারোয়ান বসে আছেন। তাঁর হাতে একটি খাতা: “হিসাব বিভাগের লোক ঢুকবেন”, “বাইরের মানুষ শুধু রিসেপশন পর্যন্ত”, “রাত ১০টার পর কেউ নয়”। কেউ এলে তিনি দেখেন — কে, কোথা থেকে, কার কাছে যাবেন — তারপর খাতা মিলিয়ে ঢুকতে দেন বা ফেরত পাঠান। নেটওয়ার্কে এই দারোয়ানের নাম firewall, আর তাঁর খাতা হলো নিয়মের তালিকা (ruleset).

পর্ব ৪৬-এ (নেটওয়ার্ক নিরাপত্তার ভিত্তি) নিরাপত্তার স্তর, zone আর “যা স্পষ্টভাবে অনুমোদিত নয়, তা নিষিদ্ধ” নীতির কথা এসেছে। এই পর্বে দেখব সেই নীতি যন্ত্রে কীভাবে বসে। একটি firewall প্রতিটি packet নিয়ে সাধারণত চার ধরনের তথ্য দেখে:

সিদ্ধান্তও মূলত তিন রকম: accept (যেতে দেওয়া), drop (নীরবে ফেলে দেওয়া — প্রেরক timeout পর্যন্ত অপেক্ষা করে), আর reject (ফেলে দিয়ে প্রেরককে TCP RST বা ICMP “unreachable” দিয়ে জানানো)। নিজের নেটওয়ার্কের ভেতরে reject ভুল তাড়াতাড়ি ধরায়; ইন্টারনেটমুখী দিকে অনেকে drop পছন্দ করেন — একমাত্র “সঠিক” উত্তর নেই।

২ · Stateless packet filter আর ACL — উপর থেকে নিচে, প্রথম মিলেই থামা

সবচেয়ে পুরোনো আর সরল firewall হলো stateless packet filter: প্রতিটি packet-কে আলাদাভাবে দেখে, আগের কোনো packet মনে রাখে না। Router আর switch-এ এর নিয়মের তালিকাকে বলে ACL (access control list). ACL পড়ার তিনটি সোনালি নিয়ম প্রায় সব vendor-এ এক:

1. উপর থেকে নিচে: নিয়মগুলো লেখা ক্রমেই পরীক্ষা হয়।
2. প্রথম মিলেই থামা (first match): যে নিয়ম প্রথম মেলে তার সিদ্ধান্তই চূড়ান্ত; নিচের নিয়ম আর দেখা হয় না।
3. শেষে অদৃশ্য “সব বাতিল”: কোনো নিয়মই না মিললে packet বাতিল — একে বলে implicit deny. তালিকায় এটি লেখা থাকে না, কিন্তু থাকে।

একটি পরীক্ষা-ধরনের ACL — হাতে মেলানো

একটি router-এর একটি interface-এ ঢোকা ট্রাফিকের জন্য এই পাঁচটি নিয়ম। সার্ভারগুলো 10.1.1.0/24-এ: ওয়েব সার্ভার 10.1.1.10, DNS সার্ভার 10.1.1.53.

এবার একটি packet ধরি: TCP, উৎস 192.168.20.7, গন্তব্য 10.1.1.10:443. নিয়ম ৪ দেখে মনে হয় “192.168.20.x-এর সবকিছু বাতিল” — কিন্তু ক্রম মেনে দেখুন কী হয়।

এবার পুরো পরীক্ষাটি একটি ছোট simulator-এ — সাতটি packet, প্রতিটির জন্য কোন নিয়ম মিলল আর কী সিদ্ধান্ত। খাতায় আগে নিজে উত্তর লিখে তারপর চালিয়ে দেখুন।

// Stateless ACL: rules checked top-down, first match wins, implicit deny at the end.
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const inPfx = (addr, pfx) => {                       // "any" or "a.b.c.d/len"
  if (pfx === "any") return true;
  const [net, len] = pfx.split("/"), size = 2 ** (32 - Number(len));
  return Math.floor(ip(addr) / size) === Math.floor(ip(net) / size);
};
const ACL = [   // [action, proto, source, destination, dst port]
  ["deny",   "tcp", "192.168.10.0/24", "10.1.1.0/24",  23],
  ["permit", "tcp", "192.168.10.0/24", "10.1.1.10/32", 80],
  ["permit", "tcp", "192.168.0.0/16",  "any",          443],
  ["deny",   "ip",  "192.168.20.0/24", "10.1.1.0/24",  null],
  ["permit", "udp", "any",             "10.1.1.53/32", 53],
];
function check(proto, src, dst, dport) {
  for (let i = 0; i < ACL.length; i++) {
    const [act, p, s, d, port] = ACL[i];
    if ((p === "ip" || p === proto) && inPfx(src, s) && inPfx(dst, d) &&
        (port === null || port === dport))
      return `rule ${i + 1} -> ${act.toUpperCase()}`;
  }
  return "no match -> DENY (implicit deny)";
}
const packets = [
  ["a", "tcp", "192.168.10.5", "10.1.1.10", 80],  ["b", "tcp", "192.168.10.5", "10.1.1.10", 23],
  ["c", "tcp", "192.168.20.7", "10.1.1.10", 443], ["d", "tcp", "192.168.20.7", "10.1.1.10", 80],
  ["e", "udp", "172.16.5.5",   "10.1.1.53", 53],  ["f", "udp", "172.16.5.5",   "10.1.1.10", 161],
  ["g", "icmp", "192.168.10.5", "10.1.1.10", null],
];
for (const [id, proto, src, dst, dport] of packets)
  console.log(`${id}) ${proto.padEnd(4)} ${src.padEnd(13)} -> ${(dst + (dport ? ":" + dport : "")).padEnd(13)} ${check(proto, src, dst, dport)}`);

a) tcp  192.168.10.5  -> 10.1.1.10:80  rule 2 -> PERMIT
b) tcp  192.168.10.5  -> 10.1.1.10:23  rule 1 -> DENY
c) tcp  192.168.20.7  -> 10.1.1.10:443 rule 3 -> PERMIT
d) tcp  192.168.20.7  -> 10.1.1.10:80  rule 4 -> DENY
e) udp  172.16.5.5    -> 10.1.1.53:53  rule 5 -> PERMIT
f) udp  172.16.5.5    -> 10.1.1.10:161 no match -> DENY (implicit deny)
g) icmp 192.168.10.5  -> 10.1.1.10     no match -> DENY (implicit deny)

Router-এ একই ACL — wildcard mask-সহ

Cisco-ধরনের router-এ একই নিয়ম লেখা হয় subnet mask-এর বদলে wildcard mask দিয়ে (mask-এর bit উল্টে: /24 → 0.0.0.255) — হিসাবটি পর্ব ১৭-এ (Subnetting) দেখেছেন। অন্য vendor-এর ভাষা আলাদা, নীতি একই।

ip access-list extended EDGE-IN
 10 deny   tcp 192.168.10.0 0.0.0.255 10.1.1.0 0.0.0.255 eq 23
 20 permit tcp 192.168.10.0 0.0.0.255 host 10.1.1.10 eq 80
 30 permit tcp 192.168.0.0 0.0.255.255 any eq 443
 40 deny   ip  192.168.20.0 0.0.0.255 10.1.1.0 0.0.0.255
 50 permit udp any host 10.1.1.53 eq 53
!
interface GigabitEthernet0/1
 ip access-group EDGE-IN in

শেষ লাইনটি বলে: ACL-টি এই interface-এ ঢোকা (in) ট্রাফিকে প্রযোজ্য। ক্রমিক নম্বর (১০, ২০ …) ফাঁক রেখে দেওয়া হয়, যাতে পরে মাঝে নতুন নিয়ম (যেমন ২৫) বসানো যায়।

Stateless-এর বড় দুর্বলতা: ফিরতি ট্রাফিক

ভেতরের একটি ল্যাপটপ বাইরে HTTPS অনুরোধ পাঠাল। উত্তর আসবে উৎস port 443 থেকে, ল্যাপটপের কোনো ephemeral port-এ (যেমন 51000). Stateless ACL জানে না এটি কোনো অনুরোধের উত্তর, তাই লিখতে হয় “উৎস port 443, গন্তব্য port 1024–65535 — permit” — আর তখন যে কেউ উৎস port 443 বসিয়ে ভেতরের যেকোনো উঁচু port-এ packet পাঠাতে পারে। পুরোনো router-এর “established” শব্দ TCP-র ACK bit দেখে কিছুটা সামলাত, কিন্তু ACK bit-ও জাল করা যায়, আর UDP-তে তেমন কিছুই নেই। সমাধান পরের অংশে।

৩ · Stateful firewall — conntrack-এর চারটি অবস্থা

Stateful firewall প্রতিটি কথোপকথনের একটি সারি মনে রাখে — পর্ব ১৯-এ (NAT) দেখা Linux-এর conntrack table-এর মতোই। নতুন packet এলে আগে খোঁজে: “এটি কি কোনো চেনা কথোপকথনের অংশ?” Linux-এর conntrack প্রতিটি packet-কে এই অবস্থাগুলোর একটিতে ফেলে:

এ থেকেই আধুনিক firewall-এর মানক নকশা: “ESTABLISHED আর RELATED-কে অনুমতি, INVALID বাতিল, তারপর নির্দিষ্ট কয়েকটি সেবার জন্য NEW-কে অনুমতি, বাকি সব বাতিল।” ফিরতি ট্রাফিকের জন্য কোনো ফুটো রাখতে হয় না — উত্তর ঢোকে শুধু অনুরোধ আগে বেরিয়ে থাকলে। আর একটি সংযোগে হাজার packet হলেও NEW মাত্র একটি, তাই প্রথম নিয়মেই বেশিরভাগ packet মিলে যায় — দ্রুত, আর তালিকা ছোট।

UDP আর ICMP-র “সংযোগ”

UDP-র কোনো handshake নেই, তবু conntrack একটি “ছদ্ম-সংযোগ” বানায়: একটি datagram বেরোলে 5-tuple মনে রাখে, উল্টো দিকের datagram এলে ESTABLISHED. শেষ কখন, তা বোঝার উপায় নেই, তাই কিছুক্ষণ নীরব থাকলে সারি মুছে যায় (timeout) — এজন্যই UDP অ্যাপের keepalive লাগে (পর্ব ২৮). ICMP Echo-তে identifier দিয়ে request আর reply জোড়া হয়। আর ICMP error বার্তার ভেতরে মূল packet-এর header উদ্ধৃত থাকে (পর্ব ২০), তাই conntrack সেটি পড়ে বলতে পারে এটি কোন সংযোগের সাথে RELATED.

নিচের simulator একটি host (10.0.0.5) — বাইরে যাওয়া সব নতুন সংযোগ চলবে, ভেতরে নতুন সংযোগ শুধু TCP 443-এ। Timeout শেখার সুবিধার জন্য ছোট: UDP ৩০ সেকেন্ড।

// Stateful firewall for host 10.0.0.5: a small conntrack table decides each packet.
const TIMEOUT = { tcp: 3600, udp: 30 };             // idle seconds (teaching values)
const ct = new Map();                                // key = flow as the initiator sent it
const key = (p, s, sp, d, dp) => `${p} ${s}:${sp} > ${d}:${dp}`;
const allowNewIn = (p, dp) => p === "tcp" && dp === 443;   // the only inbound service
function pkt(t, dir, p, s, sp, d, dp, about) {
  for (const [k, e] of ct) if (t - e.last > TIMEOUT[e.p]) {
    ct.delete(k); console.log(`t=${t}  (entry "${k}" expired)`); }
  let state, ok;
  if (p === "icmp-error") {                          // error about an existing flow?
    state = ct.has(about) ? "RELATED" : "INVALID"; ok = state === "RELATED";
  } else {
    const fwd = ct.get(key(p, s, sp, d, dp)), rev = ct.get(key(p, d, dp, s, sp));
    const e = fwd || rev;
    if (e) { if (rev) e.seen = true; e.last = t; state = e.seen ? "ESTABLISHED" : "NEW"; ok = true; }
    else {
      state = "NEW"; ok = dir === "out" || allowNewIn(p, dp);
      if (ok) ct.set(key(p, s, sp, d, dp), { p, last: t, seen: false });
    }
  }
  const what = p === "icmp-error" ? `icmp error re: ${about}` : `${p} ${s}:${sp} -> ${d}:${dp}`;
  console.log(`t=${t}  ${dir.padEnd(3)} ${what.padEnd(44)} ${state.padEnd(11)} ${ok ? "ACCEPT" : "DROP"}`);
}
pkt(0, "out", "tcp", "10.0.0.5", 51000, "198.51.100.20", 443);
pkt(1, "in",  "tcp", "198.51.100.20", 443, "10.0.0.5", 51000);
pkt(2, "in",  "tcp", "203.0.113.9", 40000, "10.0.0.5", 22);
pkt(3, "in",  "tcp", "203.0.113.9", 40001, "10.0.0.5", 443);
pkt(4, "out", "udp", "10.0.0.5", 53000, "198.51.100.53", 53);
pkt(5, "in",  "udp", "198.51.100.53", 53, "10.0.0.5", 53000);
pkt(6, "in",  "icmp-error", "192.0.2.1", 0, "10.0.0.5", 0, "tcp 10.0.0.5:51000 > 198.51.100.20:443");
pkt(7, "in",  "icmp-error", "192.0.2.1", 0, "10.0.0.5", 0, "tcp 10.0.0.5:52000 > 198.51.100.99:443");
pkt(70, "in", "udp", "198.51.100.53", 53, "10.0.0.5", 53000);
console.log(`entries left: ${ct.size}`);

t=0  out tcp 10.0.0.5:51000 -> 198.51.100.20:443      NEW         ACCEPT
t=1  in  tcp 198.51.100.20:443 -> 10.0.0.5:51000      ESTABLISHED ACCEPT
t=2  in  tcp 203.0.113.9:40000 -> 10.0.0.5:22         NEW         DROP
t=3  in  tcp 203.0.113.9:40001 -> 10.0.0.5:443        NEW         ACCEPT
t=4  out udp 10.0.0.5:53000 -> 198.51.100.53:53       NEW         ACCEPT
t=5  in  udp 198.51.100.53:53 -> 10.0.0.5:53000       ESTABLISHED ACCEPT
t=6  in  icmp error re: tcp 10.0.0.5:51000 > 198.51.100.20:443 RELATED     ACCEPT
t=7  in  icmp error re: tcp 10.0.0.5:52000 > 198.51.100.99:443 INVALID     DROP
t=70  (entry "udp 10.0.0.5:53000 > 198.51.100.53:53" expired)
t=70  in  udp 198.51.100.53:53 -> 10.0.0.5:53000       NEW         DROP
entries left: 2

৪ · Proxy, NGFW আর firewall কোথায় বসে — DMZ, ভেতরের ভাগ আর বাইরে যাওয়ার নিয়ম

Layer 4-এর ওপরে: proxy, NGFW আর WAF

Packet filter শুধু header দেখে। কিন্তু port 443-এ যা যাচ্ছে তা ব্যাংকের ওয়েবসাইট, নাকি ম্যালওয়্যারের নিয়ন্ত্রণ-সার্ভার? এর উত্তর পেতে firewall-কে আরও ওপরের স্তরে উঠতে হয়:

• Application-layer gateway বা proxy firewall: client সরাসরি সার্ভারে যায় না, proxy-র সাথে কথা বলে; proxy নিজে আলাদা সংযোগ খুলে protocol বুঝে যাচাই করে (যেমন শুধু অনুমোদিত HTTP পদ্ধতি)। দুই সংযোগের মাঝে থাকায় নিয়ন্ত্রণ বেশি, কিন্তু ধীর আর প্রতিটি protocol-এর জন্য আলাদা কোড লাগে।
• Next-generation firewall (NGFW): বাজারের একটি নাম, সংজ্ঞা vendor-ভেদে আলাদা — সাধারণত stateful filtering-এর সাথে অ্যাপ চেনা, ব্যবহারকারী-ভিত্তিক নিয়ম আর আক্রমণ-চিহ্ন খোঁজা (IPS, পর্ব ৫০). কেউ কেউ এনক্রিপ্টেড ট্রাফিক দেখতে TLS ভেঙে আবার এনক্রিপ্ট করে (TLS inspection), যা গোপনীয়তা আর বিশ্বাসের গুরুতর প্রশ্ন তোলে (পর্ব ৪৮).
• WAF (web application firewall): ওয়েব অ্যাপের সামনে বসে SQL injection-এর মতো ক্ষতিকর HTTP অনুরোধ খোঁজে — নিরাপদ কোডের বিকল্প নয়, বাড়তি একটি স্তর।

Host firewall আর network firewall

Host firewall চলে প্রতিটি যন্ত্রের নিজের OS-এ (Linux-এ nftables, Windows-এ Defender Firewall) — শুধু সেই যন্ত্রকে রক্ষা করে। Network firewall বসে নেটওয়ার্কের সীমানায় — অনেক যন্ত্রকে একসাথে রক্ষা করে, কিন্তু একই নেটওয়ার্কের দুই যন্ত্রের মাঝের ট্রাফিক দেখে না। ভালো নকশায় দুটিই থাকে (defense in depth, পর্ব ৪৬).

DMZ — দুই firewall-এর মাঝের উঠান

অফিসের ওয়েব আর মেইল সার্ভারে ইন্টারনেট থেকে পৌঁছাতে হবে; হিসাব বিভাগের কম্পিউটারে নয়। সবাই একই LAN-এ থাকলে ওয়েব সার্ভার দখল হওয়া মানে হিসাব বিভাগও হাতের নাগালে। সমাধান DMZ (demilitarized zone) বা screened subnet: বাইরে-মুখী সার্ভারগুলোর আলাদা নেটওয়ার্ক, দুই দিকে firewall দিয়ে ঘেরা।

  Internet
     │
 [ বাইরের firewall ]   ইন্টারনেট → DMZ: শুধু TCP 80/443 (ওয়েব), 25 (মেইল)
     │
 ────┴──── DMZ (203.0.113.0/28)  ওয়েব সার্ভার, মেইল সার্ভার, reverse proxy
     │
 [ ভেতরের firewall ]   DMZ → LAN: প্রায় কিছুই না (শুধু ওয়েব → DB 5432)
     │                LAN → DMZ: admin-দের SSH, ব্যবস্থাপনা
 ────┴──── ভেতরের LAN (10.20.0.0/16)  কর্মী, হিসাব, ডেটাবেস

নিয়মের মূল কথা: DMZ থেকে ভেতরে প্রায় কিছুই যাবে না, কারণ DMZ-কেই সবচেয়ে বেশি আক্রমণের মুখে ধরা হয়। ছোট প্রতিষ্ঠানে একটি firewall-এর তিনটি interface (WAN, DMZ, LAN) দিয়েও একই zone তৈরি হয় (“three-legged” নকশা).

ভেতরের ভাগ আর বাইরে যাওয়ার নিয়ম

সীমানার firewall পেরিয়ে কেউ ভেতরে ঢুকে পড়লে? পুরো অফিস এক সমতল নেটওয়ার্ক হলে সে পাশের সব যন্ত্রে ঘুরে বেড়ায় (lateral movement). তাই ভেতরেও ভাগ করা হয় — অতিথি Wi-Fi, কর্মী, সার্ভার, CCTV আলাদা VLAN-এ (পর্ব ১৩), মাঝে firewall-এর নিয়ম: একে বলে network segmentation; আরও সূক্ষ্ম, প্রতিটি workload-এর চারপাশে নিয়ম হলে microsegmentation.

অনেকে শুধু ঢোকার নিয়ম লেখেন, বাইরে যাওয়া সব খোলা রাখেন। কিন্তু egress filtering (বাইরে যাওয়া ট্রাফিকের নিয়ম) কয়েকটি কারণে জরুরি:

• ম্যালওয়্যারের ফোন-ব্যাক: আক্রান্ত যন্ত্র সাধারণত নিজেই বাইরের নিয়ন্ত্রণ-সার্ভারে সংযোগ খোলে — inbound নিয়ম তা থামায় না। সার্ভারগুলো যদি শুধু হালনাগাদের সার্ভার আর DNS resolver-এ যেতে পারে, ফোন-ব্যাক অনেক কঠিন হয়।
• ডেটা পাচার কমানো: ডেটাবেস সার্ভারের ইন্টারনেটে সরাসরি যাওয়ার কোনো কারণ নেই।
• অন্যের ক্ষতি না করা: নিজের নেটওয়ার্ক থেকে জাল উৎস-ঠিকানার packet যেন না বেরোয় — ISP পর্যায়ে এটাই BCP 38-এর ingress filtering (পর্ব ৫০, প্রচলিত আক্রমণ আর প্রতিরক্ষা). ভেতরের যন্ত্র থেকে বাইরে TCP 25 সাধারণত বন্ধ রাখা হয়, যাতে আক্রান্ত যন্ত্র spam ছড়াতে না পারে।

৫ · Linux-এ firewall — netfilter-এর hook আর nftables

Linux kernel-এর netfilter অংশ packet-এর যাত্রাপথে পাঁচটি জায়গায় “আংটা” রেখেছে — প্রতিটিকে বলে hook. নিয়মের তালিকা (chain) এই hook-গুলোতে ঝোলানো হয়, আর packet সেখানে পৌঁছালে নিয়মগুলো চলে।

 ঢোকা packet                                              বেরোনো packet
 ──► PREROUTING ──► [routing সিদ্ধান্ত] ──► FORWARD ──► POSTROUTING ──►
                          │                                ▲
                          ▼                                │
                        INPUT                            OUTPUT
                          │                                ▲
                          ▼                                │
                    local process (sshd, nginx) ───────────┘

• PREROUTING: ঢোকামাত্র, routing-এর আগে — conntrack-এর খোঁজ আর DNAT এখানে।
• INPUT: এই যন্ত্রেরই প্রোসেসের জন্য — সার্ভারের firewall.
• FORWARD: অন্য কোথাও যাবে, যন্ত্রটি শুধু router — নেটওয়ার্ক firewall.
• OUTPUT: এই যন্ত্রের প্রোসেস নিজে যা পাঠায় — egress filtering.
• POSTROUTING: বেরোনোর ঠিক আগে — SNAT আর masquerade (পর্ব ১৯).

একটি Linux router (LAN eth1: 192.168.1.0/24, WAN eth0: 203.0.113.5) ধরি। তার forward chain-এর নীতি drop, নিয়ম দুটি: (১) ct state established,related accept, (২) iifname "eth1" oifname "eth0" accept — LAN থেকে বাইরে নতুন সংযোগ চলবে। সাথে postrouting-এ masquerade. একটি ল্যাপটপের প্রথম packet আর তার উত্তর ধরে hook-গুলো দেখি।

nftables-এর গঠন: table, chain, rule, set

nftables-এ সবকিছু চারটি স্তরে সাজানো। Table একটি ধারক, সাথে একটি family: ip (IPv4), ip6, বা inet (দুটোই একসাথে — সার্ভারে প্রায় সবসময় এটাই সুবিধাজনক)। Chain-এর ভেতরে নিয়ম; base chain একটি hook-এ বসে, যেমন type filter hook input priority filter; policy drop; — অর্থাৎ ছাঁকার কাজ, INPUT hook-এ, অগ্রাধিকার filter (সংখ্যায় 0), আর কোনো নিয়ম না মিললে drop. Rule-এ শর্ত আর সিদ্ধান্ত। আর set ও map দিয়ে অনেক ঠিকানা বা port একটি নিয়মেই — হাজারটি ঠিকানা থাকলেও খোঁজা দ্রুত। counter প্রতিটি নিয়মে কতগুলো packet মিলল গোনে, log kernel log-এ লেখে।

নিচে একটি ছোট ওয়েব সার্ভারের পূর্ণ ruleset: loopback, চালু সংযোগ, শুধু ব্যবস্থাপনা নেটওয়ার্ক থেকে SSH, সবার জন্য HTTP/HTTPS, জরুরি ICMP, বাকি সব বাতিল। ডান পাশের নম্বর ধরে ব্যাখ্যা নিচে।

#!/usr/sbin/nft -f
# /etc/nftables.conf - a small web server (IPv4 + IPv6)
flush ruleset                                         # 1

table inet host_fw {                                  # 2
    set mgmt_v4 {                                     # 3
        type ipv4_addr
        flags interval
        elements = { 10.20.0.0/24 }
    }

    chain input {
        type filter hook input priority filter; policy drop;          # 4

        iif "lo" accept                                               # 5
        ct state vmap { established : accept, related : accept, invalid : drop }   # 6

        ip saddr @mgmt_v4 tcp dport 22 ct state new accept            # 7
        tcp dport { 80, 443 } ct state new counter accept             # 8

        icmp type echo-request limit rate 5/second accept             # 9
        icmp type { destination-unreachable, time-exceeded, parameter-problem } accept
        icmpv6 type { destination-unreachable, packet-too-big, time-exceeded,
                      parameter-problem, echo-request, nd-router-advert,
                      nd-neighbor-solicit, nd-neighbor-advert } accept  # 10

        limit rate 10/minute log prefix "nft-in-drop: "               # 11
        counter comment "reached policy drop"
    }

    chain forward {
        type filter hook forward priority filter; policy drop;        # 12
    }

    chain output {
        type filter hook output priority filter; policy accept;       # 13
    }
}

1. flush ruleset — আগের সব নিয়ম মুছে নতুন শুরু। পুরো ফাইল nft -f দিয়ে একবারে (atomic) বসে — হয় সব নিয়ম, নয় কিছুই না।
2. table inet host_fw — IPv4 আর IPv6 দুটোর জন্য একটি table. শুধু IPv4-এর নিয়ম লিখে IPv6 খোলা রেখে দেওয়া একটি প্রচলিত ভুল।
3. set mgmt_v4 — ব্যবস্থাপনা নেটওয়ার্কের একটি নামযুক্ত set (flags interval থাকায় পুরো prefix রাখা যায়); পরে নিয়ম না বদলে শুধু set-এ ঠিকানা যোগ করা যায়।
4. input chain, policy drop — যা স্পষ্টভাবে অনুমোদিত নয়, তা বাতিল (default deny).
5. iif "lo" accept — যন্ত্রের নিজের সাথে নিজের কথা (loopback); এটা বন্ধ করলে অনেক অ্যাপ অদ্ভুতভাবে ভাঙে।
6. ct state vmap { … } — একটি verdict map: অবস্থা দেখে একবারে সিদ্ধান্ত — ESTABLISHED আর RELATED accept, INVALID drop. অংশ ৩-এর মানক নকশার প্রথম লাইন।
7. SSH শুধু @mgmt_v4 থেকে — ইন্টারনেটের সবার সামনে SSH খোলা না রাখা সবচেয়ে কার্যকর অভ্যাসগুলোর একটি।
8. TCP 80 আর 443 — সবার জন্য; { 80, 443 } একটি anonymous set, counter দিয়ে কত নতুন সংযোগ এল গোনা যায়।
9. ICMPv4: ping সেকেন্ডে ৫টি পর্যন্ত, আর জরুরি error বার্তা। Destination-unreachable-এর ভেতরেই “Fragmentation Needed” — এটি বন্ধ করলে Path MTU Discovery ভাঙে (কোন ICMP রাখবেন, পর্ব ২০-এ)। চালু সংযোগের error এমনিতেই RELATED হয়ে ঢোকে; এই লাইন বাড়তি নিশ্চয়তা।
10. ICMPv6: IPv6-এ router fragment করে না, তাই packet-too-big ছাড়া PMTUD চলে না; আর neighbor solicitation/advertisement (NDP, ARP-এর বদলে) ছাড়া পাশের যন্ত্রের MAC-ই জানা যায় না। এগুলো বন্ধ করলে IPv6 কার্যত অচল।
11. log, সীমা দিয়ে — বাতিলের আগে মিনিটে সর্বোচ্চ ১০টি packet log-এ; সীমা না দিলে আক্রমণের সময় log-ই ডিস্ক ভরাতে পারে। শেষ counter গোনে কতগুলো packet নীতির drop-এ পৌঁছাল।
12. forward chain, drop — এটি সার্ভার, router নয়; কিছু পার করবে না।
13. output chain, accept — সরলতার জন্য বাইরে যাওয়া খোলা। কড়া নকশায় এখানেও drop দিয়ে শুধু DNS, হালনাগাদ আর দরকারি গন্তব্য খোলা হয় (অংশ ৪-এর egress filtering).

iptables, ufw আর firewalld

অনেক পুরোনো নির্দেশিকা আর স্ক্রিপ্ট এখনো iptables-এ লেখা। একই নীতি iptables-এ (IPv6-এর জন্য আলাদা ip6tables লাগে):

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp -s 10.20.0.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second -j ACCEPT
iptables -P INPUT DROP          # policy LAST - after the SSH rule exists

খেয়াল করুন নীতি (-P INPUT DROP) একদম শেষে — আগে বসালে চালু SSH সংযোগই কেটে যেত। আধুনিক অনেক distribution-এ iptables কমান্ডটি আসলে iptables-nft: পুরোনো ভাষা, কিন্তু নিয়ম বসে kernel-এর nftables কাঠামোয়; iptables -V সাধারণত “(nf_tables)” বা “(legacy)” দেখায়। দুই ধরনের নিয়ম মেশালে বিভ্রান্তি হয়, তাই একটি পথ বেছে নিন (নিজের distribution কোনটি ব্যবহার করে, যাচাই করে নিন); অনুবাদে iptables-translate সাহায্য করে।

প্রতিদিনের কাজে অনেকে সরাসরি nftables না লিখে একটি সহজ “সামনের মুখ” (front-end) ব্যবহার করেন, যা ভেতরে nftables বা iptables-এর নিয়ম বানায়: Ubuntu-তে ufw (sudo ufw default deny incoming, sudo ufw allow proto tcp from 10.20.0.0/24 to any port 22), আর Fedora/RHEL পরিবারে firewalld, যা zone ধারণায় চলে (sudo firewall-cmd --permanent --add-service=https, তারপর --reload). একটি যন্ত্রে একটির বেশি firewall ব্যবস্থাপক চালালে একে অপরের নিয়ম মুছে দিতে পারে।

Windows আর cloud

Windows-এ Defender Firewall প্রতিটি নেটওয়ার্ককে একটি profile-এ ফেলে (Domain, Private, Public) — কফিশপের Wi-Fi “Public” হলে নিয়ম সবচেয়ে কড়া।

PS> Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
PS> New-NetFirewallRule -DisplayName "Web HTTPS in" -Direction Inbound `
      -Protocol TCP -LocalPort 443 -Action Allow -Profile Domain,Private

Cloud-এ firewall আসে দুই রূপে (নিচের নাম AWS-এর; Azure, Google Cloud-এর ধারণা কাছাকাছি, নাম আর খুঁটিনাটি আলাদা)। Security group প্রতিটি VM বা network interface-এর সাথে যুক্ত, stateful — অনুমতি পাওয়া অনুরোধের উত্তর আপনাআপনি ফেরে, আর এতে শুধু allow নিয়ম লেখা যায়। Network ACL পুরো subnet-এ বসে, stateless — নম্বরযুক্ত নিয়ম ক্রমানুসারে, allow আর deny দুটোই, আর ফিরতি ট্রাফিকের জন্য ephemeral port-এর পরিসর আলাদা করে খুলতে হয় — অংশ ২-এর সমস্যাটি হুবহু। Cloud নেটওয়ার্কের বিস্তারিত পর্ব ৫৪-এ।

নিজের firewall নিরাপদে পরীক্ষা

নিয়ম বসানোর পর যাচাই করুন — শুধু নিজের যন্ত্র থেকে, নিজের যন্ত্রে। sudo nft list ruleset দেখায় এখন কী বসানো আছে, আর counter-এর সংখ্যা বলে কোন নিয়মে packet মিলছে। তারপর নিজের দ্বিতীয় একটি যন্ত্র (বা VM) থেকে অনুমোদিত সেবায় সংযোগ করে দেখুন, আর অননুমোদিত port-এ চেষ্টা করে দেখুন সত্যিই আটকায় কি না; log-এ nft-in-drop খুঁজুন। অন্যের নেটওয়ার্ক বা যন্ত্রে অনুমতি ছাড়া “পরীক্ষা” অনৈতিক, আর অনেক দেশে আইনত অপরাধ।

এই কোর্সের কোড যে container-এ চলে, সেখানে আমরা root নই। নিচের স্ক্রিপ্ট শুধু দেখে — কোন টুল আছে, আমরা কে, আর নিয়ম পড়ার চেষ্টা করলে kernel কী বলে। কিছু বদলানোর চেষ্টা করে না।

echo "== 1. who am I? =="
echo "  uid=$(id -u) user=$(id -un)"
[ "$(id -u)" -eq 0 ] && echo "  -> root" || echo "  -> not root"
cap=$(awk '/^CapEff/ {print $2}' /proc/self/status)
if (( (16#$cap >> 12) & 1 )); then echo "  CAP_NET_ADMIN: yes"; else echo "  CAP_NET_ADMIN: no (CapEff=$cap)"; fi
echo "== 2. firewall / VPN tools =="
for t in nft iptables ip6tables ufw firewall-cmd wg wg-quick; do
  command -v "$t" >/dev/null && echo "  $t: found" || echo "  $t: not found"
done
echo "== 3. read-only listing attempts (nothing is changed) =="
if command -v nft >/dev/null; then
  nft list ruleset >/dev/null 2>/tmp/nft.err && echo "  nft list ruleset: OK" \
    || echo "  nft list ruleset failed: $(head -c 120 /tmp/nft.err)"
else echo "  nft not installed - skipped"; fi
if command -v iptables >/dev/null; then
  iptables -S >/dev/null 2>/tmp/ipt.err && echo "  iptables -S: OK" \
    || echo "  iptables -S failed: $(head -c 120 /tmp/ipt.err)"
else echo "  iptables not installed - skipped"; fi
echo "== 4. what the kernel shows an ordinary user =="
for f in /proc/net/ip_tables_names /proc/net/nf_conntrack /proc/sys/net/netfilter/nf_conntrack_max; do
  if [ -r "$f" ]; then echo "  $f: readable, first line: $(head -n 1 "$f")"
  elif [ -e "$f" ]; then echo "  $f: $(cat "$f" 2>&1 >/dev/null | sed 's/^cat: [^:]*: //')"
  else echo "  $f: absent"; fi
done
[ -d /sys/module/wireguard ] && echo "  wireguard module: loaded" || echo "  wireguard module: not visible"

== 1. who am I? ==
  uid=999 user=wandbox
  -> not root
  CAP_NET_ADMIN: no (CapEff=0000000000000000)
== 2. firewall / VPN tools ==
  nft: not found
  iptables: not found
  ip6tables: not found
  ufw: not found
  firewall-cmd: not found
  wg: not found
  wg-quick: not found
== 3. read-only listing attempts (nothing is changed) ==
  nft not installed - skipped
  iptables not installed - skipped
== 4. what the kernel shows an ordinary user ==
  /proc/net/ip_tables_names: Permission denied
  /proc/net/nf_conntrack: absent
  /proc/sys/net/netfilter/nf_conntrack_max: readable, first line: 65536
  wireguard module: not visible

৬ · VPN-এর ভিত্তি — tunnel, overhead আর MTU-র হিসাব

রাজশাহী শাখার একটি কম্পিউটারকে ঢাকা অফিসের হিসাবের সার্ভারে যেতে হবে। মাঝে খোলা ইন্টারনেট। দুটি সমস্যা: ঢাকার সার্ভারের ঠিকানা private (10.20.0.15), ইন্টারনেটে route হয় না; আর পথে কেউ ডেটা পড়তে বা বদলাতে পারে। VPN (virtual private network) দুটোরই সমাধান — তিনটি কাজ একসাথে করে:

1. Tunnel: ভেতরের packet (উৎস 10.x, গন্তব্য 10.x) পুরোটাই একটি নতুন packet-এর payload হয়ে যায়, যার উৎস আর গন্তব্য দুই অফিসের public ঠিকানা।
2. এনক্রিপশন আর integrity: ভেতরের packet এনক্রিপ্ট হয়, আর প্রতিটি packet-এ একটি যাচাই-চিহ্ন থাকে — পথে বদলালে ধরা পড়ে। (AEAD-এর মতো ধারণা পর্ব ৪৭-এ, Cryptography-র ভিত্তি)
3. পরিচয় যাচাই: দুই প্রান্ত নিশ্চিত হয় অপর পাশে সত্যিই বৈধ peer — pre-shared key, certificate বা public key দিয়ে।

VPN মূলত দুই ধরনের: site-to-site — দুই অফিসের gateway-এর মাঝে স্থায়ী tunnel, ভেতরের কম্পিউটারগুলো কিছুই টের পায় না; আর remote access — কর্মীর ল্যাপটপ বাইরে থেকে অফিসের gateway-এ যুক্ত হয়। Tunnel-এর ভেতরের নেটওয়ার্ক overlay (10.x-এর জগৎ), আর যে আসল নেটওয়ার্কের ওপর দিয়ে বাক্সগুলো যায় তা underlay (ইন্টারনেট).

বাক্সের ওজন — overhead আর MTU

প্রতিটি tunnel নতুন header যোগ করে, অথচ underlay-এর লিংকের MTU সাধারণত 1500 বাইটই থাকে। তাই ভেতরের packet ছোট হতে হবে। WireGuard-এর হিসাব (IPv4 underlay):

WireGuard-এর data header-এ আছে type (১ বাইট), ৩ বাইট সংরক্ষিত, receiver index (৪ বাইট) আর একটি counter (৮ বাইট) — মোট ১৬; শেষে এনক্রিপশনের যাচাই-চিহ্ন (tag) ১৬ বাইট। বাইরের packet IPv6 হলে overhead ৮০ বাইট। এজন্যই wg-quick-এর মতো টুল সাধারণত ডিফল্ট MTU 1420 ধরে — দুই রকম underlay-এই নিরাপদ (আপনার টুলের ডিফল্ট আর PPPoE-র মতো ছোট underlay MTU থাকলে হিসাব আলাদা — যাচাই করে নিন)। ভেতরে TCP চললে MSS = 1420 − 20 (IPv4) − 20 (TCP) = 1380.

MTU ভুল হলে কী হয়? বড় packet tunnel-এ ঢুকতে পারে না; ICMP “Fragmentation Needed” ফেরত যাওয়ার কথা, কিন্তু পথে কোনো firewall ICMP আটকালে প্রেরক কিছুই জানে না — ছোট ওয়েবপেজ খোলে, বড় ফাইল আটকে যায়। এই PMTUD black hole-এর প্রচলিত ওষুধ MSS clamping: tunnel-এর gateway TCP-র SYN-এ MSS-এর মান কমিয়ে লিখে দেয়, যাতে দুই প্রান্ত শুরু থেকেই ছোট segment পাঠায়। nftables-এ এর একটি রূপ: tcp flags syn tcp option maxseg size set rt mtu (forward chain-এ) — route-এর MTU থেকে MSS বসায়।

৭ · IPsec — AH, ESP, SA আর IKEv2

IPsec IETF-এর মানসম্মত VPN কাঠামো, IP স্তরেই কাজ করে — তাই এর ওপরের যেকোনো protocol সুরক্ষা পায়। Router, firewall আর OS-এ প্রায় সর্বত্র সমর্থিত, তাই প্রতিষ্ঠানের site-to-site VPN-এ এখনো সবচেয়ে প্রচলিত। মূল নথি RFC 4301 (স্থাপত্য), RFC 4303 (ESP) আর RFC 7296 (IKEv2).

ESP tunnel mode-এর একটি packet (AES-GCM ধরে):

┌──────────┬────────────┬──────┬──────────────────────────┬─────────────┬──────┐
│ নতুন IP  │ ESP header │  IV  │  মূল IP header + ডেটা    │ ESP trailer │ ICV  │
│ 20 বাইট  │ SPI 4+seq 4│  8   │  (এনক্রিপ্টেড)            │ pad + 2     │  16  │
└──────────┴────────────┴──────┴──────────────────────────┴─────────────┴──────┘
             └──────────── integrity যাচাই ──────────────────────────────┘

NAT আর IPsec: ESP সরাসরি IP-র ওপর বসে, কোনো port নেই — তাই PAT জানে না কোন ভেতরের যন্ত্রকে উত্তর দেবে (পর্ব ১৯). সমাধান NAT-T (RFC 3948): IKEv2 দুই প্রান্তের মাঝে NAT আছে কি না টের পেলে ESP packet-কে UDP port 4500-এর datagram-এ মুড়ে পাঠায়, আর নিয়মিত keepalive দিয়ে NAT-এর সারি বাঁচিয়ে রাখে। দাম: আরও ৮ বাইট overhead. firewall-এ তাই IPsec gateway-এর জন্য খোলা থাকে UDP 500, UDP 4500, আর NAT না থাকলে IP protocol 50.

IPsec কেন জটিল: অনেক অ্যালগরিদমের মধ্যে আলোচনা, দুই প্রান্তে মিলতে হয় এমন অনেক বিকল্প (proposal, lifetime, কোন ট্রাফিক tunnel-এ যাবে তার “traffic selector”), আর vendor-ভেদে আলাদা ব্যাখ্যা — দুই vendor-এর gateway-এর মাঝে tunnel তুলতে প্রায়ই দীর্ঘ খোঁজাখুঁজি লাগে। যত বিকল্প, তত ভুল কনফিগারেশন আর পুরোনো দুর্বল অ্যালগরিদম চালু থেকে যাওয়ার সুযোগ। এই অভিজ্ঞতা থেকেই WireGuard-এর নকশা।

৮ · WireGuard — public key দিয়ে peer, AllowedIPs দিয়ে routing

WireGuard তৈরি করেন Jason A. Donenfeld; Linux kernel-এ এটি যুক্ত হয় ৫.৬ সংস্করণে (২০২০ সালের শুরুর দিকে). এখন Windows, macOS, Android, iOS আর BSD-তেও আছে। এর নকশা ইচ্ছা করেই সংকীর্ণ:

• বিকল্প নেই: একটি নির্দিষ্ট অ্যালগরিদম-গুচ্ছ (Curve25519, ChaCha20-Poly1305, BLAKE2s). দুর্বলতা পাওয়া গেলে পুরো protocol-এর নতুন সংস্করণ — আলোচনার জটিলতাই নেই।
• Peer মানে একটি public key: SSH-এর key-র মতো — কোনো ব্যবহারকারী-নাম বা certificate কর্তৃপক্ষ নেই। বৈধ key ছাড়া packet এলে WireGuard কোনো উত্তরই দেয় না।
• Handshake: Noise protocol framework-এর ওপর ভিত্তি করে ১-RTT-র একটি handshake; প্রতি কয়েক মিনিটে নতুন session key, তাই পুরোনো key চুরি হলেও আগের ট্রাফিক পড়া যায় না (forward secrecy, পর্ব ৪৭).
• শুধু UDP: TCP-র ওপর TCP চালানোর সমস্যা এড়াতে (নিচে OpenVPN দেখুন); প্রচলিত port 51820.
• ছোট কোড: kernel-এর অংশটি কয়েক হাজার লাইনের — বহু লক্ষ লাইনের প্রচলিত VPN-এর তুলনায় পর্যালোচনা করা অনেক সহজ।

Cryptokey routing — AllowedIPs-এর দুই কাজ

WireGuard-এর কেন্দ্রীয় ধারণা cryptokey routing: প্রতিটি peer-এর সাথে একটি AllowedIPs তালিকা। এই একটি তালিকা দুটি কাজ করে:

• বাইরে পাঠানোর সময় — routing table: গন্তব্য ঠিকানা কোন peer-এর AllowedIPs-এ পড়ে, তা longest prefix match-এ (পর্ব ২২) খুঁজে সেই peer-এর key দিয়ে এনক্রিপ্ট আর তার endpoint-এ পাঠানো। কোনো peer না মিললে packet বাতিল।
• ভেতরে নেওয়ার সময় — ACL: একটি packet decrypt আর যাচাই হওয়ার পর দেখা হয়, ভেতরের উৎস ঠিকানা কি সেই peer-এরই AllowedIPs-এ? না হলে বাতিল। ফলে ল্যাপটপের key দিয়ে কেউ শাখা অফিসের ঠিকানা সেজে packet পাঠাতে পারে না।

একটি অফিস gateway-এর তিনটি peer: ল্যাপটপ (10.8.0.2/32), শাখা অফিস (10.8.0.3/32 আর পুরো 192.168.50.0/24), আর একটি ল্যাব (192.168.50.128/25 — শাখার ব্লকের ওপরের অর্ধেক)। নিচের simulator দুই দিকের সিদ্ধান্ত দেখায়, সাথে একটি MTU ক্যালকুলেটর — অংশ ৬-এর হিসাব আর IPsec ESP tunnel mode (AES-GCM ধরে) পাশাপাশি।

// WireGuard cryptokey routing on the office gateway + tunnel MTU calculator.
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const peers = { laptop: ["10.8.0.2/32"], branch: ["10.8.0.3/32", "192.168.50.0/24"],
                lab: ["192.168.50.128/25"] };
function lookup(addr) {                              // longest-prefix match over AllowedIPs
  let best = null, bestLen = -1;
  for (const [name, list] of Object.entries(peers)) for (const pfx of list) {
    const [net, len] = pfx.split("/"), size = 2 ** (32 - len);
    if (Math.floor(ip(addr) / size) === Math.floor(ip(net) / size) && +len > bestLen)
      { best = name; bestLen = +len; }
  }
  return best;
}
console.log("-- outgoing: which peer gets the packet? --");
for (const dst of ["10.8.0.2", "192.168.50.20", "192.168.50.200", "10.8.0.9"])
  console.log(`dst ${dst.padEnd(15)} -> ${lookup(dst) ?? "no peer: dropped (no key for this address)"}`);
console.log("-- incoming: decrypted OK, is the inner source allowed for that peer? --");
for (const [from, src] of [["laptop", "10.8.0.2"], ["laptop", "192.168.50.20"],
                           ["branch", "192.168.50.20"], ["branch", "192.168.50.200"]])
  console.log(`from ${from.padEnd(6)} inner src ${src.padEnd(15)} ` +
    (lookup(src) === from ? "ACCEPT" : `DROP (belongs to ${lookup(src) ?? "nobody"})`));
console.log("-- largest inner packet that fits a 1500-byte link --");
const wg = outer => 1500 - outer - 8 - 32;           // UDP 8 + WG header 16 + tag 16
const esp = (outer, natt) => {                       // ESP tunnel, AES-GCM: SPI+seq 8, IV 8, ICV 16
  let p = 1500 - outer - (natt ? 8 : 0) - 8 - 8 - 2 - 16;  // 2 = pad length + next header
  while ((p + 2) % 4) p--;                           // ESP payload+trailer: multiple of 4
  return p;
};
console.log(`WireGuard over IPv4: ${wg(20)}   over IPv6: ${wg(40)}`);
console.log(`ESP tunnel over IPv4: ${esp(20, false)}   +NAT-T (UDP 4500): ${esp(20, true)}   over IPv6: ${esp(40, false)}`);
console.log(`TCP MSS inside WireGuard MTU 1420 (IPv4 inner): ${1420 - 20 - 20}`);

-- outgoing: which peer gets the packet? --
dst 10.8.0.2        -> laptop
dst 192.168.50.20   -> branch
dst 192.168.50.200  -> lab
dst 10.8.0.9        -> no peer: dropped (no key for this address)
-- incoming: decrypted OK, is the inner source allowed for that peer? --
from laptop inner src 10.8.0.2        ACCEPT
from laptop inner src 192.168.50.20   DROP (belongs to branch)
from branch inner src 192.168.50.20   ACCEPT
from branch inner src 192.168.50.200  DROP (belongs to lab)
-- largest inner packet that fits a 1500-byte link --
WireGuard over IPv4: 1440   over IPv6: 1420
ESP tunnel over IPv4: 1446   +NAT-T (UDP 4500): 1438   over IPv6: 1426
TCP MSS inside WireGuard MTU 1420 (IPv4 inner): 1380

দুই peer-এর একটি পূর্ণ কনফিগারেশন

রহিমার ল্যাপটপ বাসা থেকে অফিসের LAN (10.20.0.0/16)-এ যাবে। Tunnel-এর ভেতরের ঠিকানা 10.8.0.0/24. Key-গুলো এখানে স্পষ্ট নকল নাম — আসল key কখনো কোথাও প্রকাশ করবেন না।

# ===== office gateway: /etc/wireguard/wg0.conf =====
[Interface]
Address    = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <office-private-key>

# Rahima's laptop
[Peer]
PublicKey  = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

# ===== laptop: /etc/wireguard/wg0.conf =====
[Interface]
Address    = 10.8.0.2/32
PrivateKey = <laptop-private-key>
DNS        = 10.20.0.53

# the office; split tunnel: only office networks go into the tunnel
[Peer]
PublicKey  = <office-public-key>
Endpoint   = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16
PersistentKeepalive = 25

• Key বানানো: প্রতিটি যন্ত্রে umask 077; wg genkey | tee private.key | wg pubkey > public.key. Private key যন্ত্র ছাড়ে না; অপর প্রান্ত পায় শুধু public key.
• Gateway-এর AllowedIPs = 10.8.0.2/32 — এই peer থেকে শুধু এই একটি উৎস-ঠিকানা গ্রহণযোগ্য, আর এই ঠিকানার packet শুধু তার কাছেই যায়।
• ল্যাপটপের AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 — শুধু অফিসের নেটওয়ার্ক tunnel-এ, বাকি ইন্টারনেট বাসার পথে। Endpoint জানা থাকায় ল্যাপটপই যোগাযোগ শুরু করে; gateway ল্যাপটপের বর্তমান ঠিকানা শেখে প্রথম বৈধ packet থেকে, তাই Wi-Fi থেকে মোবাইল ডেটায় গেলেও tunnel টেকে (roaming).
• PersistentKeepalive = 25 — ল্যাপটপ NAT-এর পেছনে, তাই প্রতি ২৫ সেকেন্ডে একটি ছোট packet, যাতে NAT-এর সারি না মোছে (কারণটি পর্ব ২৮-এ দেখেছেন)।
• চালু আর যাচাই: sudo wg-quick up wg0, তারপর sudo wg show — প্রতিটি peer-এর শেষ handshake কখন আর কত বাইট আদান-প্রদান হলো দেখায়। Gateway-কে router হতে হবে: net.ipv4.ip_forward=1, আর forward chain-এ iifname "wg0" oifname "eth1" ip daddr 10.20.0.0/16 accept ধরনের নিয়ম; firewall-এ UDP 51820 খোলা।

এবার একটি packet ধরে পুরো যাত্রা। ল্যাপটপের বাসার ঠিকানা 192.168.0.105, বাসার router-এর public ঠিকানা 203.0.113.77; অফিস gateway 198.51.100.10:51820; গন্তব্য অফিসের সার্ভার 10.20.0.15:443.

OpenVPN আর TLS-ভিত্তিক VPN

OpenVPN (২০০১ সাল থেকে) TLS দিয়ে key বিনিময় আর certificate দিয়ে পরিচয় যাচাই করে; প্রচলিত port UDP 1194. বহু বছর এটিই ছিল খোলা উৎসের প্রধান remote-access VPN. এটি TCP-র ওপরেও চলে (যেমন TCP 443), যা কড়া firewall পেরোতে সুবিধাজনক — কিন্তু তখন ভেতরের আর বাইরের দুই TCP-ই হারানো packet আবার পাঠায়, আর ক্ষতিপূর্ণ লিংকে দুই স্তরের timer একে অপরকে বাড়িয়ে গতি ভেঙে দেয় — “TCP-over-TCP” সমস্যা। তাই সম্ভব হলে VPN চলে UDP-তে।

৯ · কোন পথে কোন ট্রাফিক — split tunnel, DNS leak, zero trust আর আইন

Split tunnel বনাম full tunnel

উপরের ল্যাপটপ শুধু অফিসের নেটওয়ার্ক tunnel-এ পাঠায় — split tunnel; সাধারণ ব্রাউজিং বাসার ইন্টারনেটেই যায়, অফিসের ব্যান্ডউইথ বাঁচে। Full tunnel (WireGuard-এ AllowedIPs = 0.0.0.0/0, ::/0) সব ট্রাফিক অফিস দিয়ে পাঠায় — সব ট্রাফিকে প্রতিষ্ঠানের নীতি চলে, অচেনা Wi-Fi-তেও সুরক্ষা থাকে, কিন্তু gateway-এর ওপর চাপ বাড়ে আর সেখানে masquerade-ও লাগে।

একটি সূক্ষ্ম ফাঁদ DNS leak: সব ট্রাফিক tunnel-এ গেলেও যন্ত্র যদি DNS প্রশ্ন ISP-র resolver-এ পাঠাতে থাকে, তবে কোন সাইটে যাওয়া হচ্ছে তা বাইরে দেখা যায়, আর অফিসের ভেতরের নামও মেলে না। প্রতিকার: tunnel-এর DNS সার্ভার বসানো (WireGuard-এ DNS =) আর OS সেটিই ব্যবহার করছে কি না যাচাই। Tunnel শুধু IPv4 নিলে IPv6 ট্রাফিকও পাশ দিয়ে বেরোতে পারে।

“VPN” শব্দের দুই অর্থ

বিজ্ঞাপনের “VPN অ্যাপ” আর অফিসের VPN প্রযুক্তিতে কাছাকাছি, উদ্দেশ্যে আলাদা। অফিসের VPN আপনাকে একটি নির্দিষ্ট নেটওয়ার্কে ঢোকায়; consumer VPN আপনার সব ট্রাফিক একটি বাণিজ্যিক প্রতিষ্ঠানের সার্ভার দিয়ে ইন্টারনেটে বের করে. তখন স্থানীয় নেটওয়ার্ক বা ISP গন্তব্য দেখে না, কিন্তু VPN প্রতিষ্ঠান সবই দেখতে পারে — বিশ্বাস সরে যায়, মুছে যায় না। এটি ম্যালওয়্যার, phishing বা দুর্বল পাসওয়ার্ড থেকেও রক্ষা করে না।

Zero trust — “ভেতরে ঢুকলেই বিশ্বাস” নীতির অবসান

প্রচলিত VPN দিয়ে ঢুকলে আপনি “ভেতরের” মানুষ, আর ভেতরের নেটওয়ার্কের অনেক কিছুতে পৌঁছাতে পারেন — আক্রান্ত ল্যাপটপ হলে আক্রমণকারীও তাই পায়। Zero trust network access (ZTNA, ধারণাটি পর্ব ৪৬-এ) এর বিকল্প: প্রতিটি অনুরোধে ব্যবহারকারী, যন্ত্রের অবস্থা আর নির্দিষ্ট অ্যাপ যাচাই করে শুধু সেই অ্যাপে প্রবেশাধিকার, পুরো নেটওয়ার্কে নয়। Google-এর BeyondCorp এর একটি পরিচিত উদাহরণ। বাস্তবে অনেক প্রতিষ্ঠান দুটি একসাথে চালায়।

১০ · AI-এর যুগে firewall আর VPN — নিয়ম চালানোর আগে যাচাই

“আমার সার্ভারের জন্য একটি firewall বানিয়ে দাও” — AI কয়েক সেকেন্ডে নিয়ম লিখে দেবে। কিন্তু firewall-এর ভুলের দাম দুই রকম: বেশি খোলা হলে আক্রমণের দরজা, বেশি বন্ধ হলে নিজেই তালাবন্ধ। চেনা ভুলগুলো:

AI-এর firewall বা VPN পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• নিয়মগুলো উপর থেকে নিচে কয়েকটি নমুনা packet দিয়ে হাতে মিলিয়েছি — অনুমোদিত আর নিষিদ্ধ দুই রকমই
• IPv6, loopback, established/related আর জরুরি ICMP বাদ পড়েনি তা দেখেছি
• nft -c দিয়ে যাচাই করে, ফেরত-টাইমার রেখে, আগে ল্যাব বা VM-এ বসিয়েছি
• VPN-এর MTU আর AllowedIPs নিজে হিসাব করেছি, DNS কোন পথে যাচ্ছে যাচাই করেছি
• শুধু নিজের বা অনুমতিপ্রাপ্ত যন্ত্রে পরীক্ষা করেছি; ফল দেখেছি nft list ruleset-এর counter, log আর wg show দিয়ে