NAT আর private ঠিকানা — এক public IP-তে পুরো অফিস

১ · ঠিকানা ফুরিয়ে গেল — তবু সবার ইন্টারনেট চলছে কীভাবে

আপনার বাসার Wi-Fi-তে হয়তো ছয়-সাতটি যন্ত্র যুক্ত — দুটি ফোন, একটি ল্যাপটপ, একটি স্মার্ট টিভি, হয়তো একটি CCTV ক্যামেরা। প্রতিটি যন্ত্রের একটি IP ঠিকানা আছে, যেমন 192.168.0.101. এবার পাশের বাসার কাউকে জিজ্ঞেস করুন — খুব সম্ভব তাঁর ল্যাপটপের ঠিকানাও 192.168.0.101. লাখ লাখ বাসায় একই ঠিকানা! তাহলে উত্তর কার কাছে যাবে? এই ধাঁধার উত্তরই এই পর্ব: NAT (Network Address Translation).

সমস্যাটা হিসাবে: ৩২ bit যথেষ্ট নয়

IPv4 ঠিকানা ৩২ bit-এর, তাই মোট ২^৩২ = ৪,২৯,৪৯,৬৭,২৯৬টি (প্রায় ৪৩০ কোটি) ঠিকানা। এর একটি বড় অংশ আবার multicast, loopback-এর মতো বিশেষ কাজে সংরক্ষিত। অথচ পৃথিবীতে মানুষই ৮০০ কোটির বেশি, আর প্রত্যেকের একাধিক যন্ত্র। নব্বইয়ের দশকের শুরুতেই বোঝা গিয়েছিল ঠিকানা ফুরোবে; তাই দুটি সমাধানের কাজ শুরু হলো — দীর্ঘমেয়াদে বড় ঠিকানার নতুন protocol (IPv6, পর্ব ২১), আর স্বল্পমেয়াদে ঠিকানা ভাগাভাগির কৌশল NAT. মজার ব্যাপার হলো, “স্বল্পমেয়াদি” কৌশলটিই তিন দশক ধরে ইন্টারনেট চালিয়ে যাচ্ছে।

Private ঠিকানা — মহল্লার ভেতরের বাড়ির নম্বর

RFC 1918 তিনটি ঠিকানার ব্লক আলাদা করে রেখেছে, যেগুলো কোনো প্রতিষ্ঠানকে বরাদ্দ দেওয়া হয় না। যে-কেউ নিজের নেটওয়ার্কের ভেতরে এগুলো ব্যবহার করতে পারেন, কারও অনুমতি লাগে না। শর্ত একটাই: এগুলো ইন্টারনেটে route হয় না। ISP-র router আর ইন্টারনেটের router-গুলো এই ঠিকানার packet গন্তব্য হিসেবে পেলে কোথায় পাঠাবে জানে না, আর ভালো ISP এমন উৎস-ঠিকানার packet নিজের সীমানাতেই ফেলে দেয়। এজন্য এগুলোকে বলে private ঠিকানা, আর যেগুলো সারা পৃথিবীতে অনন্য ও route হয়, সেগুলো public ঠিকানা.

খেয়াল করুন 172.16.0.0/12-এর সীমা: 172.16 থেকে 172.31 পর্যন্ত, অর্থাৎ 172.32.0.1 একটি public ঠিকানা! এটি পরীক্ষায় খুব প্রিয় একটি ফাঁদ। এই হিসাব (/১২ মানে প্রথম ১২ bit স্থির) পর্ব ১৬-১৭-এ ধাপে ধাপে করবেন।

২ · NAT router আসলে কী করে — যাওয়ার পথে, ফেরার পথে

একটি NAT router-এর দুটি দিক: ভেতরের (inside, LAN) দিকে private ঠিকানা, যেমন 192.168.1.1; বাইরের (outside, WAN) দিকে ISP-র দেওয়া public ঠিকানা, এই পর্বে ধরি 203.0.113.5. ভেতরের প্রতিটি যন্ত্রের default gateway এই router. NAT-এর কাজ তিনটি ধাপে বোঝা যায়:

Port কী, তা পর্ব ২৭-এ বিস্তারিত দেখবেন। আপাতত এটুকু যথেষ্ট: একটি host-এ একসাথে অনেক কথোপকথন চলে (ব্রাউজারের দশটি ট্যাব, ইমেইল, গেম); port নম্বর হলো সেই host-এর ভেতরে একটি নির্দিষ্ট কথোপকথনের নাম — ১৬ bit-এর একটি সংখ্যা, ০ থেকে ৬৫,৫৩৫. সার্ভারের port পরিচিত (HTTPS 443, DNS 53), ক্লায়েন্টের port OS বেছে দেয় (ephemeral port). একটি TCP বা UDP কথোপকথন তাই পাঁচটি জিনিসে চেনা যায়: protocol, উৎস IP, উৎস port, গন্তব্য IP, গন্তব্য port — একে বলে 5-tuple. NAT এই 5-tuple-এর উৎস অংশটুকু বদলায়।

এবার অফিসের একটি ল্যাপটপের অনুরোধ ধরে ধরে দেখি। অফিসে আরেকটি ল্যাপটপ (192.168.1.10) আগেই একই সার্ভারে উৎস port 50000 দিয়ে সংযোগ খুলেছে — তাই router-এর public port 50000 আর খালি নেই।

প্রাপক কী দেখে — একটি ছোট C পরীক্ষা

NAT ঠিক কোন তথ্যটি বদলায়, তা প্রাপকের দিক থেকে দেখা যায়। UDP সার্ভার recvfrom() দিয়ে packet পড়লে OS তাকে প্রেরকের IP আর port-ও দেয় — সার্ভার এটাকেই উত্তরের ঠিকানা হিসেবে ব্যবহার করে। নিচের প্রোগ্রাম একই কম্পিউটারের loopback-এ দুটি UDP socket খোলে: একটি 127.0.0.1:47000-এ শোনে, অন্যটি 127.0.0.1:47001 থেকে পাঠায়।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

static int udp_on(unsigned short port) {          /* UDP socket bound to 127.0.0.1:port */
    int s = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in a = {0};
    a.sin_family = AF_INET;
    a.sin_port = htons(port);
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    if (s < 0 || bind(s, (struct sockaddr *)&a, sizeof a) < 0) { perror("bind"); return -1; }
    return s;
}
int main(void) {
    int rx = udp_on(47000), tx = udp_on(47001);
    if (rx < 0 || tx < 0) return 1;
    struct sockaddr_in to = {0}, from;
    to.sin_family = AF_INET;
    to.sin_port = htons(47000);
    to.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    sendto(tx, "hello", 5, 0, (struct sockaddr *)&to, sizeof to);
    char buf[64];
    socklen_t len = sizeof from;
    ssize_t n = recvfrom(rx, buf, sizeof buf - 1, 0, (struct sockaddr *)&from, &len);
    if (n < 0) { perror("recvfrom"); return 1; }
    buf[n] = '\0';
    printf("receiver got \"%s\" (%zd bytes)\n", buf, n);
    printf("source as seen by receiver: %s:%u\n", inet_ntoa(from.sin_addr), ntohs(from.sin_port));
    printf("a NAT on the path would replace exactly this pair with its public IP:port\n");
    close(rx); close(tx);
    return 0;
}

receiver got "hello" (5 bytes)
source as seen by receiver: 127.0.0.1:47001
a NAT on the path would replace exactly this pair with its public IP:port

৩ · Static NAT, dynamic NAT আর PAT — তিন রকম খাতা

NAT-এর table কীভাবে সাজানো, তার ওপর তিনটি প্রধান ধরন:

Static NAT-এর table আগে থেকে লেখা, তাই বাইরে থেকেও সংযোগ শুরু করা যায়। Dynamic NAT-এ ঠিকানা pool থেকে ধার নেওয়া হয়, অব্যবহৃত থাকলে ফেরত যায়। দুটোতেই একটি public ঠিকানা একই সময়ে একটি যন্ত্রেরই — ঠিকানা বাঁচে না বললেই চলে। PAT (Port Address Translation, RFC 3022-এর ভাষায় NAPT) এখানে বড় লাফ: port যোগ করায় একটি public ঠিকানার পেছনে একসাথে শত শত যন্ত্র চলে। আজ সাধারণ কথায় “NAT” বললে প্রায় সবসময় PAT-ই বোঝানো হয়।

একটি PAT router চালিয়ে দেখা

নিচের simulator একটি ছোট PAT router: তিনটি ভেতরের যন্ত্র বাইরে সংযোগ খোলে (দুটি একই ভেতরের port 50000 ব্যবহার করে!), তারপর কয়েকটি packet বাইরে থেকে আসে — দুটি বৈধ উত্তর, দুটি অনুরোধ-ছাড়া packet, আর একটি দেরিতে আসা UDP উত্তর। Timeout-এর মান এখানে শেখার সুবিধার জন্য ছোট রাখা (TCP 300, UDP 30 সেকেন্ড); বাস্তবের মান অংশ ৫-এ।

// PAT (NAPT) simulator: many inside hosts share one public IP 203.0.113.5.
const PUB = "203.0.113.5", TIMEOUT = { tcp: 300, udp: 30 };  // seconds (example values)
const table = new Map();          // key "proto:publicPort" -> entry
function out(t, proto, src, sport, dst, dport) {
  let p = sport;                  // keep the inside port if it is free, else next free
  while (table.has(proto + ":" + p)) p++;
  table.set(proto + ":" + p, { src, sport, dst, dport, last: t });
  console.log(`t=${t} OUT ${proto} ${src}:${sport} -> ${dst}:${dport}  rewritten src = ${PUB}:${p}`);
}
function back(t, proto, src, sport, dport) {
  const e = table.get(proto + ":" + dport);
  if (e && t - e.last > TIMEOUT[proto]) { table.delete(proto + ":" + dport);
    console.log(`t=${t} entry ${proto}:${dport} idle ${t - e.last}s > ${TIMEOUT[proto]}s -> expired`); }
  const ok = table.get(proto + ":" + dport);
  if (!ok || ok.dst !== src || ok.dport !== sport)
    return console.log(`t=${t} IN  ${proto} ${src}:${sport} -> ${PUB}:${dport}  no matching entry -> DROP`);
  ok.last = t;
  console.log(`t=${t} IN  ${proto} ${src}:${sport} -> ${PUB}:${dport}  rewritten dst = ${ok.src}:${ok.sport}`);
}
function show() {
  console.log("  proto pub-port  inside              remote               last");
  for (const [k, e] of table) console.log("  " + k.split(":")[0].padEnd(6) + k.split(":")[1].padEnd(10) +
    (e.src + ":" + e.sport).padEnd(20) + (e.dst + ":" + e.dport).padEnd(21) + "t=" + e.last);
}
out(0, "tcp", "192.168.1.10", 50000, "198.51.100.20", 443);
out(1, "tcp", "192.168.1.11", 50000, "198.51.100.20", 443);   // same inside port!
out(2, "udp", "192.168.1.12", 41000, "198.51.100.53", 53);
show();
back(3, "tcp", "198.51.100.20", 443, 50000);
back(4, "tcp", "198.51.100.20", 443, 50001);
back(5, "tcp", "192.0.2.66", 4444, 3389);                     // unsolicited
back(6, "tcp", "192.0.2.66", 4444, 50000);                    // right port, wrong remote
back(40, "udp", "198.51.100.53", 53, 41000);                  // reply came too late
show();

t=0 OUT tcp 192.168.1.10:50000 -> 198.51.100.20:443  rewritten src = 203.0.113.5:50000
t=1 OUT tcp 192.168.1.11:50000 -> 198.51.100.20:443  rewritten src = 203.0.113.5:50001
t=2 OUT udp 192.168.1.12:41000 -> 198.51.100.53:53  rewritten src = 203.0.113.5:41000
  proto pub-port  inside              remote               last
  tcp   50000     192.168.1.10:50000  198.51.100.20:443    t=0
  tcp   50001     192.168.1.11:50000  198.51.100.20:443    t=1
  udp   41000     192.168.1.12:41000  198.51.100.53:53     t=2
t=3 IN  tcp 198.51.100.20:443 -> 203.0.113.5:50000  rewritten dst = 192.168.1.10:50000
t=4 IN  tcp 198.51.100.20:443 -> 203.0.113.5:50001  rewritten dst = 192.168.1.11:50000
t=5 IN  tcp 192.0.2.66:4444 -> 203.0.113.5:3389  no matching entry -> DROP
t=6 IN  tcp 192.0.2.66:4444 -> 203.0.113.5:50000  no matching entry -> DROP
t=40 entry udp:41000 idle 38s > 30s -> expired
t=40 IN  udp 198.51.100.53:53 -> 203.0.113.5:41000  no matching entry -> DROP
  proto pub-port  inside              remote               last
  tcp   50000     192.168.1.10:50000  198.51.100.20:443    t=3
  tcp   50001     192.168.1.11:50000  198.51.100.20:443    t=4

Linux-এ NAT: masquerade আর conntrack

বাসার বেশিরভাগ Wi-Fi router-এর ভেতরে আসলে একটি ছোট Linux চলে, আর NAT করে kernel-এর netfilter অংশ। নিয়ম লেখা হয় পুরোনো iptables বা নতুন nftables দিয়ে। নিচের কমান্ডগুলো root ছাড়া চলে না, আর অন্যের যন্ত্রে নয় — শুধু নিজের ল্যাব বা VM-এ চেষ্টা করবেন।

# ১. kernel-কে packet forward করতে দেওয়া (router হতে এটি লাগে)
$ sudo sysctl -w net.ipv4.ip_forward=1

# ২ক. পুরোনো iptables: LAN 192.168.1.0/24 থেকে eth0 দিয়ে বেরোলে উৎস বদল
$ sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# ২খ. একই কাজ nftables-এ (আধুনিক Linux-এ পছন্দের পথ)
$ sudo nft add table ip nat
$ sudo nft add chain ip nat postrouting '{ type nat hook postrouting priority srcnat; }'
$ sudo nft add rule ip nat postrouting ip saddr 192.168.1.0/24 oifname "eth0" masquerade

MASQUERADE মানে “বাইরের interface-এর বর্তমান ঠিকানাটাই উৎস হিসেবে বসানো” — ISP DHCP দিয়ে ঠিকানা বদলালেও নিয়ম কাজ করে। ঠিকানা স্থির হলে SNAT --to-source 203.0.113.5 (nftables-এ snat to 203.0.113.5) লেখা যায়। খেয়াল করুন: নিয়মটি শুধু প্রথম packet-এ দেখা হয়। তারপর kernel-এর conntrack (connection tracking) প্রতিটি কথোপকথনের দুই দিকের চেহারা মনে রাখে, আর পরের সব packet সরাসরি সেই হিসাবে বদলায় — ঠিক উপরের simulator-এর table. conntrack টুল (root লাগে) দিয়ে সেই table দেখা যায়:

$ sudo conntrack -L -p tcp
tcp  6 431995 ESTABLISHED src=192.168.1.11 dst=198.51.100.20 sport=50000 dport=443
                          src=198.51.100.20 dst=203.0.113.5 sport=443 dport=50001 [ASSURED] mark=0 use=1
$ sudo conntrack -L -p udp
udp  17 27 src=192.168.1.12 dst=198.51.100.53 sport=41000 dport=53
           src=198.51.100.53 dst=203.0.113.5 sport=53 dport=41000 mark=0 use=1

প্রতিটি সারিতে দুটি অংশ: প্রথমটি মূল দিক (ল্যাপটপ যা পাঠিয়েছিল), দ্বিতীয়টি প্রত্যাশিত উত্তর — কোথা থেকে আসবে, কোন ঠিকানা:port-এ। দ্বিতীয় অংশের dst=203.0.113.5 dport=50001-ই NAT-এর প্রমাণ। মাঝের সংখ্যাটি (431995, 27) হলো সারি মুছে যেতে আর কত সেকেন্ড বাকি। Cisco-র মতো router-এ একই কাজ “overload” শব্দে হয়:

interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
interface GigabitEthernet0/1
 ip address 203.0.113.5 255.255.255.252
 ip nat outside
!
access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/1 overload
!
R1# show ip nat translations
Pro Inside global       Inside local        Outside local      Outside global
tcp 203.0.113.5:50001   192.168.1.11:50000  198.51.100.20:443  198.51.100.20:443

Cisco-র চারটি নাম মনে রাখার মতো: inside local (ভেতরের যন্ত্রের আসল ঠিকানা), inside global (বাইরে সেই যন্ত্র যে ঠিকানায় পরিচিত), outside global (বাইরের সার্ভারের আসল ঠিকানা), outside local (ভেতর থেকে সেই সার্ভার যে ঠিকানায় দেখা যায় — সাধারণত একই)। CCNA-ধরনের পরীক্ষায় এই চারটি প্রায়ই আসে।

৪ · ঠিকানা বদলালে checksum-ও বদলায় — দ্রুত হিসাবের কৌশল

পর্ব ০৯-এ দেখেছেন, IP header-এ একটি ১৬ bit-এর checksum থাকে: header-এর সব ১৬ bit-এর শব্দ one's complement পদ্ধতিতে যোগ করে (উপচে পড়া carry আবার নিচে যোগ করে) ফলটি উল্টে দেওয়া (RFC 1071). NAT উৎস ঠিকানা বদলালে header-এর দুটি শব্দ বদলায়, তাই checksum ঠিক না করলে পরের router packet-টি নষ্ট ভেবে ফেলে দেবে।

ঝামেলা এখানেই শেষ নয়। TCP আর UDP-র checksum শুধু নিজের header আর ডেটার ওপর নয়, একটি pseudo-header-এর ওপরও হিসাব হয় — উৎস IP, গন্তব্য IP, protocol নম্বর আর দৈর্ঘ্য, যেগুলো আসলে IP header-এর ঘর। ফল: NAT যখন শুধু IP ঠিকানা বদলায়, তখনও TCP/UDP checksum ভুল হয়ে যায়। তাই NAT-কে layer 3-এর যন্ত্র হয়েও layer 4-এর header খুলে ঠিক করতে হয় — স্তরের নিয়ম ভাঙার (layer violation) একটি ক্লাসিক উদাহরণ। (IPv4-এ UDP checksum 0 মানে “checksum নেই”; তখন NAT সেটি 0-ই রাখে।)

পুরোটা আবার না যোগ করে — RFC 1624

প্রতিটি packet-এর পুরো segment আবার যোগ করা ব্যয়বহুল। কিন্তু one's complement যোগের একটি সুন্দর গুণ আছে: যোগের ক্রম কোনো ব্যাপার নয়, আর একটি শব্দ m-কে বাদ দেওয়া মানে তার উল্টো ~m যোগ করা (কারণ one's complement-এ m + ~m = 0xFFFF, যা “শূন্য”-এর আরেক রূপ)। তাই পুরোনো checksum HC থেকে নতুনটি পাওয়া যায় শুধু বদলানো শব্দগুলো দিয়ে:

কেন ঠিক: ধরুন সব শব্দের one's complement যোগফল S, তাহলে HC = ~S, অর্থাৎ ~HC = S. একটি শব্দ m বদলে m′ হলে নতুন যোগফল S′ = S − m + m′. One's complement-এ “− m” মানে “+ ~m”, তাই S′ = ~HC + ~m + m′, আর নতুন checksum HC′ = ~S′. কয়েকটি শব্দ বদলালে প্রতিটির জন্য একটি করে (~m + m′) যোগ করলেই হয়। (আগের RFC 1141-এর সূত্র HC′ = HC + m + ~m′ একটি বিশেষ অবস্থায় one's complement-এর “দুই শূন্য” — 0x0000 আর 0xFFFF — গুলিয়ে ভুল ফল দিত; RFC 1624 সেটি শুধরে উপরের রূপ দেয়।)

নিচের কোড একটি ২০ byte-এর IPv4 header আর একটি TCP segment-এর (pseudo-header-সহ) checksum বানায়, তারপর NAT-এর মতো উৎস 192.168.1.11:50000 বদলে 203.0.113.5:50001 করে — একবার পুরো আবার হিসাব করে, একবার RFC 1624-এর সূত্রে — আর দুটি মেলায়।

// NAT changes src IP + src port: update checksums incrementally (RFC 1624) vs full recompute.
const hex = n => "0x" + n.toString(16).padStart(4, "0");
const fold = s => { while (s > 0xffff) s = (s & 0xffff) + (s >>> 16); return s; };
const csum = words => (~fold(words.reduce((a, b) => a + b, 0))) & 0xffff;   // RFC 1071
const ip = s => s.split(".").map(Number), w = (a, b) => (a << 8) | b;
const ipWords = s => { const o = ip(s); return [w(o[0], o[1]), w(o[2], o[3])]; };
// IPv4 header (20 bytes) as 10 words; word 5 = checksum, words 6-9 = src, dst
function ipHeader(src, dst) {
  return [0x4500, 60, 0x1c46, 0x4000, w(64, 6), 0, ...ipWords(src), ...ipWords(dst)];
}
// TCP: pseudo-header (src, dst, proto 6, length 20) + 20-byte header, checksum word 8
function tcpWords(src, dst, sport) {
  return [...ipWords(src), ...ipWords(dst), 6, 20,
          sport, 443, 0x0000, 0x0001, 0x0000, 0x0000, 0x5010, 0xfaf0, 0, 0];
}
const inc = (hc, olds, news) => {                  // HC' = ~(~HC + ~m + m')
  let s = (~hc) & 0xffff;
  olds.forEach((m, i) => { s += ((~m) & 0xffff) + news[i]; });
  return (~fold(s)) & 0xffff;
};
const IN = "192.168.1.11", OUT = "203.0.113.5", DST = "198.51.100.20";
const ipOld = csum(ipHeader(IN, DST)), ipNew = csum(ipHeader(OUT, DST));
const ipInc = inc(ipOld, ipWords(IN), ipWords(OUT));
console.log("IP  checksum before NAT :", hex(ipOld));
console.log("IP  full recompute      :", hex(ipNew), " incremental:", hex(ipInc),
            ipNew === ipInc ? "MATCH" : "DIFF");
const tOld = csum(tcpWords(IN, DST, 50000)), tNew = csum(tcpWords(OUT, DST, 50001));
const tInc = inc(tOld, [...ipWords(IN), 50000], [...ipWords(OUT), 50001]);
console.log("TCP checksum before NAT :", hex(tOld));
console.log("TCP full recompute      :", hex(tNew), " incremental:", hex(tInc),
            tNew === tInc ? "MATCH" : "DIFF");
console.log("words touched: IP 2 of 10, TCP 3 of 16 (pseudo-header + header)");

IP  checksum before NAT : 0x327b
IP  full recompute      : 0xb828  incremental: 0xb828 MATCH
TCP checksum before NAT : 0x03dc
TCP full recompute      : 0x8988  incremental: 0x8988 MATCH
words touched: IP 2 of 10, TCP 3 of 16 (pseudo-header + header)

৫ · ভেতরের সার্ভার বাইরে দেখানো — port forwarding, timeout আর hairpinning

PAT-এর table শুধু ভেতর থেকে শুরু হওয়া কথোপকথনে তৈরি হয়। কিন্তু অফিসের 192.168.1.50-এ চলা ওয়েব সার্ভার বাইরের গ্রাহকদের দেখাতে চাইলে? বাইরে থেকে আসা অনুরোধের কোনো সারি নেই! সমাধান হলো হাতে একটি স্থায়ী নিয়ম লেখা: “public ঠিকানার TCP port 8080-এ যা আসবে, তা ভেতরের 192.168.1.50:80-এ যাবে” — এর নাম port forwarding, আর Linux-এর ভাষায় DNAT (destination NAT), কারণ এখানে বদলায় গন্তব্য. আগের অংশের masquerade ছিল SNAT — উৎস বদল।

# iptables: eth0-তে TCP 8080 এলে ভেতরের 192.168.1.50:80-এ
$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 \
       -j DNAT --to-destination 192.168.1.50:80
# FORWARD chain-এর নীতি DROP হলে এই সংযোগটি অনুমতি দিতে হবে
$ sudo iptables -A FORWARD -p tcp -d 192.168.1.50 --dport 80 \
       -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

# nftables-এ একই কাজ
$ sudo nft add chain ip nat prerouting '{ type nat hook prerouting priority dstnat; }'
$ sudo nft add rule ip nat prerouting iifname "eth0" tcp dport 8080 dnat to 192.168.1.50:80

বাসার router-এর “Port Forwarding” মেনুতে একই কাজ হয়। কিছু যন্ত্র প্রোগ্রামকে নিজে থেকে নিয়ম খোলার সুযোগ দেয় — UPnP IGD, NAT-PMP (RFC 6886) বা তার উত্তরসূরি PCP (Port Control Protocol, RFC 6887). ঝুঁকি হলো, ভেতরের ক্ষতিকর প্রোগ্রাম বা দুর্বল IoT যন্ত্রও নিজের জন্য দরজা খুলতে পারে — তাই নিরাপত্তা-সচেতন নেটওয়ার্কে UPnP সাধারণত বন্ধ থাকে।

NAT timeout — table-এর সারি কতক্ষণ বাঁচে

Table অসীম নয়, তাই অব্যবহৃত সারি একসময় মুছতে হয়। TCP-তে router সংযোগের শুরু (SYN) আর শেষ (FIN/RST) দেখতে পায়, তাই বুঝতে পারে কোন সংযোগ বন্ধ হলো; বন্ধ হলে অল্প সময় পরেই সারি মোছে। কিন্তু UDP-তে “সংযোগ” বলে কিছু নেই — router জানেই না কথোপকথন শেষ হয়েছে কি না, তাই শুধু নীরবতার সময় গোনে। ফলে UDP-র timeout অনেক ছোট।

এর বাস্তব ফল: একটি SSH সংযোগ অনেকক্ষণ ফেলে রাখলে হঠাৎ “জমে” যায় — পথের কোনো NAT সারিটি মুছে ফেলেছে, অথচ দুই প্রান্ত ভাবছে সংযোগ চালু। প্রতিকার keepalive: নির্দিষ্ট সময় পরপর ছোট একটি packet পাঠিয়ে সারিটি “জীবিত” রাখা (SSH-এ ServerAliveInterval, TCP-তে socket-এর keepalive).

Hairpinning — ভেতর থেকে নিজের public ঠিকানায়

অফিসের ভেতরের একজন কর্মী যদি ব্রাউজারে 203.0.113.5:8080 লেখেন — নিজের অফিসের সার্ভারেই, কিন্তু public ঠিকানা দিয়ে? Packet router-এ গিয়ে DNAT হয়ে ঘুরে ভেতরে ফেরে — চুলের কাঁটার মতো বাঁক, তাই নাম hairpinning (বা NAT loopback). শুধু DNAT করলে সমস্যা: সার্ভার দেখে উৎস 192.168.1.11, একই LAN-এ, তাই router এড়িয়ে সরাসরি উত্তর দেয় — আর কর্মীর কম্পিউটার এমন একটি ঠিকানা থেকে উত্তর পায় যাকে সে অনুরোধই পাঠায়নি। তাই hairpin-এ router উৎসও বদলায় (নিজের ঠিকানা বসায়), যাতে উত্তর router দিয়েই ফেরে। RFC 4787 hairpinning সমর্থন করতে বলে, কিন্তু সব বাসার router করে না; বিকল্প হলো ভেতরের DNS-এ সার্ভারের ভেতরের ঠিকানা দেওয়া (split DNS; DNS-এর কাজের ধরন পর্ব ৩৫-এ)।

৬ · দুজনেই NAT-এর পেছনে — ভিডিও কল কীভাবে সংযোগ পায়

ওয়েব ব্রাউজিং-এ NAT প্রায় অদৃশ্য, কারণ সবসময় ক্লায়েন্টই সংযোগ শুরু করে আর সার্ভারের থাকে public ঠিকানা। কিন্তু ঢাকায় আপনি আর চট্টগ্রামে আপনার বন্ধু দুজনেই বাসার Wi-Fi-তে, দুজনেই NAT-এর পেছনে। ভিডিও কলে সবচেয়ে ভালো হয় সরাসরি peer-to-peer পথে UDP পাঠালে — কম delay, মাঝের সার্ভারের খরচ নেই। সমস্যা: আপনার packet বন্ধুর router-এ পৌঁছালে তা “অনুরোধ-ছাড়া inbound” — DROP. বন্ধুর packet-ও আপনার router-এ DROP. দুজনেরই দরজা ভেতর থেকে বন্ধ। এই সমস্যার নাম NAT traversal.

NAT-এর চার ধরন — RFC 3489-এর পুরোনো নাম

কোন NAT কতটা “বন্ধুসুলভ”, তা নির্ভর করে দুটি আচরণের ওপর: ম্যাপিং (ভেতরের একই IP:port থেকে আলাদা আলাদা গন্তব্যে গেলে বাইরের port কি একই থাকে?) আর ফিল্টারিং (বাইরের কে কে সেই port-এ packet পাঠাতে পারবে?)। ২০০৩ সালের RFC 3489 (প্রথম STUN) চারটি নাম দিয়েছিল, যা আজও বই আর ইন্টারভিউতে চলে:

পরে বোঝা গেল বাস্তবের NAT এই চার বাক্সে ঠিকমতো আঁটে না। তাই ২০০৭ সালের RFC 4787 ম্যাপিং আর ফিল্টারিংকে আলাদা করে দেখে — প্রতিটির তিনটি সম্ভাব্য আচরণ (endpoint-independent, address-dependent, address and port-dependent), আর ২০০৮ সালের নতুন STUN (RFC 5389) পুরোনো শ্রেণিবিভাগ বাদ দেয়। NAT যেন বাধা কম তৈরি করে, সেজন্য RFC 4787 endpoint-independent mapping বাধ্যতামূলক (MUST) বলে।

STUN, hole punching, TURN আর ICE

• STUN (Session Traversal Utilities for NAT, এখন RFC 8489): ইন্টারনেটে একটি সহজ সার্ভার, যাকে একটি UDP packet পাঠালে সে উত্তরে বলে “আপনার packet আমার কাছে এসেছে এই IP:port থেকে” — অর্থাৎ আপনার NAT-এর বাইরের চেহারা। একে বলে server-reflexive ঠিকানা।
• UDP hole punching: দুজনেই নিজের বাইরের ঠিকানা একটি signaling server-এর মাধ্যমে বিনিময় করেন, তারপর একই সময়ে একে অপরের বাইরের ঠিকানায় UDP পাঠান। নিজের পাঠানো packet নিজের NAT-এ সেই গন্তব্যের জন্য “দরজা খোলে”, তাই অপর দিকের packet এলে ঢুকতে পারে।
• TURN (Traversal Using Relays around NAT, RFC 8656): সরাসরি না হলে শেষ ভরসা — public ঠিকানার একটি relay সার্ভার, যার মাধ্যমে দুজনের সব packet যায়। সবসময় কাজ করে, কিন্তু খরচ আর delay বাড়ে।
• ICE (Interactive Connectivity Establishment, RFC 8445): সবগুলো একসাথে চালানোর পদ্ধতি। প্রতিটি পক্ষ নিজের সব সম্ভাব্য ঠিকানা (“candidate”) — ভেতরের, STUN-এর, TURN-এর — বিনিময় করে, জোড়ায় জোড়ায় পরীক্ষা করে সেরাটি বাছে। WebRTC (ব্রাউজারের ভিডিও কল) ICE ব্যবহার করে।

সব জোড়ার জন্য ফলটা কেমন? নিচের simulator চার ধরনের NAT-এর প্রতিটি জোড়ায় উপরের পদ্ধতি চালায়: STUN দিয়ে ঠিকানা জানা, তারপর তিন দফা দুই দিক থেকে পাঠানো। কেউ packet পেলে সে অপর প্রান্তের আসল উৎস ঠিকানা শিখে নেয় (ICE-এর “peer-reflexive” candidate) আর সেখানেই পরের packet পাঠায়।

// UDP hole punching between two NATed peers, for the four classic (RFC 3489) NAT types.
const TYPES = ["full-cone", "restricted", "port-restricted", "symmetric"];
function makeNat(type, ip) {
  const maps = [], nat = { type, ip, next: 40000 };
  nat.send = (dst) => {                 // returns the public port used toward dst
    let m = maps.find(m => type !== "symmetric" || m.dst === dst);
    if (!m) { m = { dst, port: nat.next++, seen: [] }; maps.push(m); }
    m.seen.push(dst);                    // remember whom we talked to (filtering)
    return m.port;
  };
  nat.accept = (port, from) => {        // does an inbound packet pass?
    const m = maps.find(m => m.port === port);
    if (!m) return false;
    if (type === "full-cone") return true;
    if (type === "restricted") return m.seen.some(d => d.split(":")[0] === from.split(":")[0]);
    return m.seen.includes(from);        // port-restricted and symmetric
  };
  return nat;
}
function tryPunch(tA, tB) {
  const A = makeNat(tA, "203.0.113.5"), B = makeNat(tB, "198.51.100.9"), S = "192.0.2.1:3478";
  let aSeesB = B.ip + ":" + B.send(S), bSeesA = A.ip + ":" + A.send(S);  // STUN answers
  let aGot = false, bGot = false;
  for (let round = 0; round < 3; round++) {        // both keep sending a few times
    const pa = A.ip + ":" + A.send(aSeesB);         // A -> B
    if (B.accept(+aSeesB.split(":")[1], pa)) { bGot = true; bSeesA = pa; }
    const pb = B.ip + ":" + B.send(bSeesA);         // B -> A
    if (A.accept(+bSeesA.split(":")[1], pb)) { aGot = true; aSeesB = pb; }
  }
  return aGot && bGot ? "direct" : "TURN relay";
}
console.log("A \\ B".padEnd(17) + TYPES.map(t => t.padEnd(16)).join(""));
for (const a of TYPES) console.log(a.padEnd(17) + TYPES.map(b => tryPunch(a, b).padEnd(16)).join(""));

A \ B            full-cone       restricted      port-restricted symmetric
full-cone        direct          direct          direct          direct
restricted       direct          direct          direct          direct
port-restricted  direct          direct          direct          TURN relay
symmetric        direct          direct          TURN relay      TURN relay

৭ · Carrier-grade NAT — আপনার ISP-ও NAT করছে

IPv4 ফুরিয়ে যাওয়ার পর ISP-রা নিজেরাও যথেষ্ট public ঠিকানা পায় না — কিনতে হয় বাজার থেকে, বেশ দামে। সমাধান: ISP-র নেটওয়ার্কেই একটি বিশাল NAT বসানো, যার নাম carrier-grade NAT (CGNAT বা CGN). গ্রাহকের router-এর WAN পাশে তখন একটি public ঠিকানার বদলে আসে আরেকটি অ-public ঠিকানা, আর ISP-র CGNAT শত শত গ্রাহককে একটি public ঠিকানার পেছনে রাখে।

এজন্য RFC 6598 (২০১২) আলাদা একটি ব্লক দিয়েছে: 100.64.0.0/10, নাম “shared address space”. RFC 1918-এর ব্লক কেন নয়? কারণ গ্রাহকের বাসার ভেতরেই হয়তো 192.168.1.0/24 বা 10.0.0.0/8 চলছে; ISP-ও একই ব্লক ব্যবহার করলে router-এর দুই পাশে একই subnet পড়তে পারে, আর routing ভেঙে যায়। আলাদা ব্লক এই সংঘর্ষ এড়ায়। মোবাইল ডেটায় অপারেটররা অনেক সময় 10.x ঠিকানাও দেয় — ফোন তো নিজেই একক যন্ত্র, তার পেছনে আরেকটি বাসার LAN সাধারণত থাকে না।

CGNAT-এর প্রভাব

বাংলাদেশে মোবাইল ডেটা ব্যবহারকারীরা সাধারণভাবে CGNAT-এর পেছনে থাকেন বলে ধরে নেওয়া যায় — ফোনের সেটিংসে নিজের ঠিকানা প্রায়ই 10.x বা 100.x-এর মতো দেখা যায় — আর অনেক ব্রডব্যান্ড ISP-ও একই পথে হাঁটে। তবে এটি অপারেটর, এলাকা আর প্যাকেজ ভেদে আলাদা, আর সময়ের সাথে বদলায়। নিজের সংযোগ যাচাই করার সহজ পথ: router-এর পাতায় WAN ঠিকানা দেখুন, আর কোনো “আমার IP কত” ধরনের ওয়েবসাইটে যে ঠিকানা দেখায় তার সাথে মেলান। দুটি আলাদা হলে, বিশেষত WAN ঠিকানা 100.64.0.0/10-এর মধ্যে হলে, আপনি CGNAT-এর পেছনে।

৮ · NAT firewall নয়, protocol ভাঙে, আর end-to-end নীতির সাথে লড়াই

“NAT আছে, তাই নিরাপদ” — অর্ধেক সত্য

অংশ ৩-এর simulator-এ দেখেছেন, অনুরোধ-ছাড়া inbound packet DROP হয়। তাই অনেকে ভাবেন NAT-ই firewall. সূক্ষ্ম পার্থক্যটা বোঝা জরুরি। Stateful NAT (PAT) যা করে তা আসলে একটি পার্শ্বফল: router জানেই না packet কাকে দেবে, তাই ফেলে দেয়। এটা সত্যিকারের firewall-এর “ভেতরে শুরু হওয়া সংযোগের উত্তরই শুধু ঢুকবে” নীতির (stateful firewall, পর্ব ৪৯) সাথে মেলে বটে, কিন্তু তফাতগুলো বড়:

• বাইরে যাওয়া কিছুই আটকায় না। ভেতরের ভাইরাস-আক্রান্ত যন্ত্র আক্রমণকারীর সার্ভারে নিজেই সংযোগ খুলতে পারে — NAT সানন্দে পার করে দেয়।
• নিয়ম কম, নিয়ন্ত্রণ নেই। কোন সেবা, কোন ঠিকানা, কোন সময় — এমন নীতি NAT-এর কাজ নয়। Port forwarding আর UPnP নিজেই দরজা খোলে।
• ভেতরের নেটওয়ার্ক রক্ষা করে না। একই LAN-এর যন্ত্রগুলো একে অপরের কাছে খোলা; অতিথির ফোন অফিসের প্রিন্টারে পৌঁছায়।
• IPv6-এ NAT নেই বললেই চলে। NAT-কেই নিরাপত্তা ভাবলে IPv6 চালু হওয়ামাত্র সব যন্ত্র খোলা হয়ে যেত। এজন্য IPv6 router-এ ডিফল্ট stateful firewall — বাইরের অনুরোধ-ছাড়া সংযোগ বন্ধ — রাখার সুপারিশ আছে (RFC 6092).

যেসব protocol NAT-এ ভাঙে — আর ALG

NAT শুধু header বদলায়। কিন্তু কিছু protocol নিজের ডেটার ভেতরে IP ঠিকানা বা port লিখে পাঠায় — সেটা NAT দেখে না, বদলায়ও না। ক্লাসিক উদাহরণ FTP-র active mode: ক্লায়েন্ট সার্ভারকে PORT 192,168,1,11,195,80 কমান্ডে বলে “আমার এই ঠিকানা:port-এ ডেটা-সংযোগ খুলুন” (শেষ দুটি সংখ্যা port = ১৯৫ × ২৫৬ + ৮০ = ৫০,০০০)। সার্ভার একটি private ঠিকানায় সংযোগ খোলার চেষ্টা করে — ব্যর্থ। সমাধান দুটি: passive mode (ক্লায়েন্টই দ্বিতীয় সংযোগ শুরু করে, NAT-বান্ধব), অথবা router-এ একটি ALG (Application Layer Gateway) — যা FTP-র কমান্ড পড়ে ভেতরের ঠিকানা বদলে দেয় আর আগাম একটি সারিও বানিয়ে রাখে।

ALG ভঙ্গুর জোড়াতালি: প্রতিটি protocol-এর জন্য আলাদা কোড, এনক্রিপ্টেড ডেটায় অচল, আর ভুল ALG ভালো protocol-কেও ভাঙে। VoIP-এর SIP-এর ALG এর কুখ্যাত উদাহরণ — অনেক IP ফোন সমস্যার প্রথম পরামর্শই থাকে “router-এ SIP ALG বন্ধ করে দেখুন”. IPsec VPN-ও NAT-এ সমস্যায় পড়ে (ESP-তে port নেই, আর AH-এর integrity যাচাই IP ঠিকানাও ঢাকে), তাই এসেছে NAT-T: ESP-কে UDP port 4500-এ মুড়ে পাঠানো।

End-to-end নীতির সাথে টানাপোড়েন

পর্ব ০৩-এ দেখেছেন end-to-end principle: বুদ্ধি থাকবে দুই প্রান্তে, মাঝের নেটওয়ার্ক শুধু packet বহন করবে। মূল ইন্টারনেটে প্রতিটি যন্ত্র অন্য যেকোনো যন্ত্রের কাছে সরাসরি পৌঁছাতে পারত। NAT এই প্রতিশ্রুতি ভেঙেছে: এখন একটি middlebox header বদলায়, transport-এর অবস্থা মনে রাখে, অচেনা protocol দেখলে (যেমন TCP বা UDP নয় এমন নতুন transport) প্রায়ই ফেলে দেয়। এর একটি বড় ফল protocol-এর ossification: SCTP-র মতো নতুন transport protocol ইন্টারনেটে ছড়াতে পারেনি, আর QUIC (পর্ব ৩৩) ইচ্ছা করেই UDP-র ওপর তৈরি, যাতে বিদ্যমান NAT আর middlebox-গুলো তাকে পার করে দেয়। ক্ষতি বেশি হয়েছে peer-to-peer আর “সবাই সার্ভার” ধারণার।

দীর্ঘমেয়াদি উত্তর: IPv6

IPv6-এর ঠিকানা ১২৮ bit — ২^১২৮ ঠিকানা, এত বেশি যে প্রতিটি বাসাকে সাধারণত পুরো একটি ব্লক দেওয়া হয় (ISP ভেদে /48 থেকে /64), আর প্রতিটি যন্ত্র পায় নিজের global ঠিকানা। তাই NAT-এর দরকার নেই, আর peer-to-peer আবার সরাসরি সম্ভব (firewall-এর অনুমতি সাপেক্ষে)। IPv6 পুরোপুরি না আসা পর্যন্ত দুই জগৎ পাশাপাশি চলে, আর মাঝের রূপান্তরে (NAT64, DNS64) NAT আবার অন্য রূপে ফেরে। IPv6-এর ঠিকানা, header আর রূপান্তরের কৌশল পর্ব ২১-এ।

৯ · AI-এর যুগে NAT, port forwarding আর NAT traversal

“আমার বাসার CCTV বাইরে থেকে দেখতে চাই, router-এ কী করব?” — AI দ্রুত ধাপগুলো বলে দেবে। কিন্তু AI আপনার আসল পরিস্থিতি (CGNAT আছে কি না) জানে না, আর সহজতম পথটি প্রায়ই সবচেয়ে অনিরাপদ। চেনা ভুলগুলো:

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

• নিজের WAN ঠিকানা দেখে নিশ্চিত হয়েছি আমি CGNAT-এর পেছনে কি না
• Private ব্লক আর subnet-এর হিসাব নিজে ক্যালকুলেটরে বা হাতে মিলিয়েছি
• শুধু দরকারি port খুলেছি, DMZ আর UPnP বন্ধ রেখেছি, router-এর admin পাতার ডিফল্ট পাসওয়ার্ড বদলেছি
• কমান্ডগুলো man nft/man iptables বা vendor-এর ডকুমেন্টেশনের সাথে মিলিয়েছি, আর আগে ল্যাব বা VM-এ চালিয়ে দেখেছি
• শুধু নিজের বা অনুমতিপ্রাপ্ত নেটওয়ার্কে পরীক্ষা করেছি; ফল যাচাই করেছি conntrack -L আর নিজের ল্যাবের packet capture দিয়ে