Worked examples — NAT traversal, VPN, tunneling

4.3.30 · D3 · Coding › Computer Networks › NAT traversal, VPN, tunneling

---

The scenario matrix

Examples karne se pehle, chalte hain har possible case class enumerate karte hain jo yeh topic throw kar sakta hai. Neeche har example ek cell ke saath tagged hai jo woh fill karta hai.

Cell	Case class	Kya cheez isse alag banati hai	Example
A	Simple encapsulation overhead	ek wrapper, positive-sized packet	Ex 1
B	Stacked / double tunnel (VPN-in-tunnel)	overhead add hota hai	Ex 2
C	Degenerate: inner packet exceeds effective MTU	fragmentation / drop	Ex 3
D	Limiting case: tiny payload	overhead ratio → near 1	Ex 4
E	Limiting case: huge payload	overhead ratio → 0	Ex 4
F	NAT-type decision (kaunsa traversal kaam karega?)	full-cone vs symmetric	Ex 5
G	STUN mapping read-off (public IP:port)	table arithmetic	Ex 6
H	Real-world word problem (TURN ka throughput cost)	latency + bandwidth	Ex 7
I	Exam twist: encryption payload ko expand karta hai	crypto overhead ≠ sirf header	Ex 8

Pehle matrix kyun? Taaki tum dekh sako ki koi hidden scenario nahi hai. Positive/normal, degenerate (too big), do limits (tiny/huge), aur discrete decision cases (NAT type) — har input space covered hai.

---

Do formulas jo hum baar baar use karte hain

Yahan sab kuch parent note ke do relations pe tika hai. Chalte hain unhe phir se anchor karte hain taaki koi bhi symbol unexplained na rahe.

"Ratio" kyun, sirf "bytes" kyun nahi? Ratio yeh batata hai "mera kitna fraction bandwidth wrappers par waste ho raha hai?" — ek percentage, packet sizes ke across comparable. Raw byte count yeh batata hai "kya yeh fit hoga?". Alag sawaal, alag tools.

---

Cell A — Simple encapsulation overhead

1. Outer headers add karo. $h=20+8=28$ B. Yeh step kyun? GRE ek IP delivery header plus apna 8-byte GRE header stack karta hai; dono "outer" bytes hain jo wire carry karta hai.
2. Effective inner MTU. ${\text{MTU}}_{\text{inner}}=1500-28=1472$ B. Yeh step kyun? Inner packet outer ek ke andar fit hona chahiye; 28 B kisi bhi inner byte se pehle spend ho jaate hain.
3. Kya 1400 fit hoga? $1400\le 1472$ ✓ — koi fragmentation nahi. Yeh step kyun? Hamesha $L$ ko ${\text{MTU}}_{\text{inner}}$ se compare karo, 1500 se kabhi nahi.
4. Overhead ratio. $\frac{h}{L+h}=\frac{28}{1400+28}=\frac{28}{1428}\approx 0.0196=1.96\%$.

Verify: Wrapped packet = $1400+28=1428\le 1500$ ✓ path mein fit hai. Overhead $1.96\%$ ka matlab hai ~98% wire bytes useful hain — ek mote 1400-byte packet ke liye reasonable hai.

---

Cell B — Stacked tunnels (double wrap)

1. Saare outer bytes sum karo. $h=60+20=80$ B. Yeh step kyun? Har wrapper apne bahar wale ke liye opaque hai; wire ke nazariye se yeh sirf aur outer header hain. Bytes add hote hain.
2. Effective inner MTU. $1500-80=1420$ B. Yeh step kyun? Dono layers usi 1500-B budget mein se khate hain.
3. Fit check. $1300\le 1420$ ✓.
4. Overhead ratio. $\frac{80}{1300+80}=\frac{80}{1380}\approx 0.0580=5.80\%$.

Verify: Total on-wire = $1300+80=1380\le 1500$ ✓. Overhead 5.8% > Ex 1 ka 1.96% — zyada wrappers, zyada waste, jaise expect kiya tha.

---

Cell C — Degenerate: inner packet too big

1. Effective inner MTU. $1500-73=1427$ B. Yeh step kyun? IPsec tunnel mode poore inner IP packet ko plus ESP overhead ko wrap karta hai — yahan ek bhaari 73 B.
2. Compare karo. $L=1500>1427$. Wrapped packet $1500+73=1573>1500$ B hoga — path ke liye too big. Yeh step kyun? Yahi exactly degenerate cell hai: inner size effective MTU se zyada hai.
3. Outcome. Ya toh router use fragment karta hai (slow, kabhi kabhi Firewalls block karte hain) ya, agar inner packet mein Don't-Fragment bit set hai, toh use drop kar diya jaata hai aur ICMP "too big" return hota hai — jise firewall swallow kar sakta hai, jiski wajah se silent stall hota hai. Yeh step kyun? s01 dekho: red packet outer envelope ke mouth se lamba hai — woh poora andar nahi ja sakta.
4. Sabse bada safe inner packet. $L_{\max }={\text{MTU}}_{\text{inner}}=1427$ B.

Verify: $1427+73=1500\le 1500$ ✓ exactly fit hai. Ek aur byte ($1428$) se $1501>1500$ ✗ — toh 1427 sach mein ceiling hai.

---

Cells D & E — Do limits (tiny aur huge payload)

1. Tiny payload (cell D). $\frac{40}{1+40}=\frac{40}{41}\approx 0.9756=97.56\%$. Yeh step kyun? Jab $L\to 0$, fraction $\frac{h}{L+h}\to \frac{h}{h}=1$: almost saare bytes wrapper hain. Isi liye interactive traffic (SSH keystrokes, VoIP) tunnels ke through bandwidth-inefficient hota hai.
2. Huge payload (cell E). $\frac{40}{65000+40}=\frac{40}{65040}\approx 0.000615=0.0615\%$. Yeh step kyun? Jab $L\to \infty$, $\frac{h}{L+h}\to 0$: fixed wrapper ek giant payload ke against negligible ho jaata hai.
3. Trend. s02 dekho: jaise $L$ left se right badhta hai, overhead curve ~100% se 0 ki taraf girta hai. Fixed header ek toll hai: ek bade truck ke liye sasta, ek tiny scooter ke liye mahenga.

Verify: Dono limits bracket hain: $0<0.000615<0.9756<1$ ✓. Function $\frac{40}{L+40}$ strictly decreasing hai $L$ mein, toh tiny maximum deta hai aur huge minimum deta hai. ✓

---

Cell F — Kaunsa traversal kaam karega? (NAT-type decision)

1. Yaad karo har NAT kya karta hai. Full-cone: ek public port khula, koi bhi use kar sakta hai. Symmetric: har destination ke liye ek naya public port. Yeh step kyun? Traversal success poori tarah depend karta hai is baat par ki kya peer STUN se seekha port wahi port hai jo doosre peer tak pahunchne ke liye use hoga.
2. P STUN se apna mapping seekhta hai. Lekin P ka NAT symmetric hai: woh port jo P STUN server se baat karte waqt dekhta hai, woh STUN server se alag hoga jo Q se baat karte waqt allocate hoga. Yeh step kyun? Q, P ke STUN-reflexive port par bhejta — lekin woh port sirf STUN server tak map karta hai, Q tak nahi. Q ka packet koi matching entry nahi milti → drop ho jaata hai.
3. Reverse direction try karo. P, Q ke full-cone mapping par bhejta hai — yeh kaam karta hai (full-cone sab ko allow karta hai). Toh P→Q ek hole punch karta hai. Lekin two-way connection ke liye ICE ko ek working pair chahiye; Q→P step 2 ki wajah se fail hota hai. Yeh step kyun? Media connection ke liye dono directions chahiye; one-way success kaafi nahi hai.
4. Decision. Symmetric × kuch bhi (sivaaye full-cone-with-luck ke) → TURN relay par fall back karo.

Verify: Parent rule se match karta hai: "Symmetric NAT → traversal often fails → use TURN." Relay hamesha kaam karta hai kyunki dono peers relay par outbound initiate karte hain, har ek apna valid hole punch karta hai. ✓

---

Cell G — STUN mapping read-off

1. Reflexive candidate identify karo. Public mapping jo peer ko use karni hai woh hai 198.51.100.7:41000. Yeh step kyun? STUN ka poora kaam hai baahri view reveal karna — woh address jo NAT table is host par map karta hai.
2. Private wala kyun nahi? 192.168.1.20 public Internet par non-routable hai (RFC 1918). Wahan aim kiya gaya peer packet kabhi peer ke apne LAN se bahar nahi jaayega. Yeh step kyun? Private ranges (192.168.x.x, 10.x, 172.16–31.x) har jagah reuse hoti hain; inhe globally address nahi kiya ja sakta. Dekho IPv4 exhaustion.
3. Advertise karo. Host peer ko signaling ke through bolta hai: "Mujhe 198.51.100.7:41000 par reach karo."

Verify: Reply address = NAT ka outside mapping = 198.51.100.7:41000, table entry 192.168.1.20:52000 ↔ 198.51.100.7:41000 se match karta hai. ✓ Advertised port (41000) translated port ke equal hai, internal 52000 nahi. ✓

---

Cell H — Real-world word problem (TURN cost)

1. Relay se total bitrate. Up + down = $2+2=4$ Mbps. Yeh step kyun? TURN har direction alag relay karta hai, toh dono legs relay bandwidth consume karti hain.
2. Duration seconds mein. $10\text{ min}\times 60=600$ s.
3. Total bits. $4\times 10^6\text{ bit/s}\times 600\text{ s}=2.4\times 10^9$ bits. Yeh step kyun? bitrate × time = total bits. Units dhyan rakho: Mbps = $10^6$ bits/s.
4. Gigabytes mein convert karo. $\frac{2.4\times 10^9\text{ bits}}{8}$ bytes $=3.0\times 10^8$ bytes $=0.3$ GB ($1\text{ GB}=10^9$ bytes use karke). Yeh step kyun? Bandwidth bytes mein bill hota hai; bits ko 8 se divide karo.
5. Cost. 0.3 \text{ GB} \times \0.10/\text{GB} = $0.03$.

Verify: Units cascade karte hain: \text{Mbit/s} \to \text{bit} \to \text{byte} \to \text{GB} \to \text{\}$✓.$4\text{ Mbps}\times 600\text{ s} = 2400\text{ Mbit} = 300\text{ MB} = 0.3\text{ GB}, cost \0.03. Per call sasta — lekin hazaaron concurrent calls se multiply karo aur TURN wahi reason ban jaata hai kyun engineers direct traversal prefer karte hain. ✓

---

Cell I — Exam twist: encryption payload ko expand karta hai

1. Pehle padding. ESP (payload + 2 trailer bytes) encrypt karta hai aur 16-byte multiple tak pad karta hai. Pad se pehle encrypted region = $1400+2=1402$ B. 1402 se upar 16 ka agla multiple $1408$ hai. Pad bytes = $1408-1402=6$ B. Yeh step kyun? Block ciphers (TLS/IPsec often AES use karte hain 16-byte blocks ke saath) require karte hain ki input length blocks ka whole number ho — yeh real overhead hai jo payload ko grow karta hai, unlike ek fixed header.
2. Har added byte sum karo. $h=\underset{\text{IP}}{\underbrace{20}}+\underset{\text{ESP}}{\underbrace{8}}+\underset{\text{IV}}{\underbrace{16}}+\underset{\text{pad}}{\underbrace{6}}+\underset{\text{pad/nxt}}{\underbrace{2}}+\underset{\text{ICV}}{\underbrace{12}}=64$ B. Yeh step kyun? Encryption overhead = headers + IV + padding + authentication tag — jo students sirf IP header count karte hain woh yeh exam question galat karte hain.
3. Fit check. Wrapped = $1400+64=1464\le 1500$ ✓.
4. Overhead ratio. $\frac{64}{1400+64}=\frac{64}{1464}\approx 0.0437=4.37\%$.

Verify: $1402$ ko 16-multiple tak round up karo: $1402=16\times 87+10$, toh agla multiple $16\times 88=1408$ hai, pad $=6$ ✓. Total $20+8+16+6+2+12=64$ ✓. On-wire $1464\le 1500$ ✓, koi fragmentation nahi. ✓

---

Recall

Recall "Fit hoga ya nahi" vs "kitna wasteful" ke liye kaunsa formula?

Fit ::: $L$ ko ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h$ se compare karo. Waste ::: overhead ratio $=h/(L+h)$.

Recall Ex 3:

$h=73$, path 1500 ke saath sabse bada safe inner packet? $1500-73=1427$ B ::: (1428 se 1501 overflow ho jaata).

Recall Ex 4: payload → 0 aur → ∞ par overhead limits?

$L\to 0\Rightarrow$ ratio → 100%; $L\to \infty \Rightarrow$ ratio → 0% ::: fixed header ek toll hai — tiny packets par brutal, huge ones par negligible.

Recall Ex 5: symmetric × full-cone NAT — direct ya TURN?

TURN relay ::: symmetric NAT har destination ke liye naya port allocate karta hai, toh STUN-learned port match nahi karta; hole punching ek direction mein fail hota hai.

Recall Ex 8: crypto overhead sirf header se zyada kyun hai?

IV + padding-to-block-size + auth tag add karta hai ::: padding payload alignment ke saath badhti bhi hai, fixed constant nahi hai.