NAT traversal, VPN, tunneling: Visual walkthrough — Hinglish deep dive

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

Parent: 4.3.30 NAT traversal, VPN, tunneling (Hinglish)

Step 1 — Packet hota kya hai (ek box with a nametag)

KYA: hum ek packet ko ek rectangle ki tarah draw karte hain jiska width bytes mein measure hota hai (ek byte = 8 bits = storage ka ek "letter").

KYUN: baaki sab kuch inn rectangles ki width ke baare mein hai, isliye humein ek aisi picture chahiye jahan width ka matlab literally "number of bytes" ho.

PICTURE: orange band header hai, blue band payload hai. Inki combined width packet ki total size hai.

Step 2 — MTU: woh darwaza jisme har packet fit hona chahiye

KYA: hum MTU ko $1500$ bytes ke ek fixed-width darwaaze ki tarah draw karte hain aur packets ko iske through slide karte hain.

KYUN yeh idea aur "bas bhej do" nahi: links infinite nahi hote. Hardware har packet ke liye ek fixed buffer reserve karta hai, isliye ek hard ceiling hoti hai. Header jo bhi byte khata hai, woh byte darwaza tumhare data ke liye aur nahi khar sakta — wahi trade-off poori derivation hai.

PICTURE: exactly $1500$ B wide ek packet barely squeeze hoke nikal jaata hai; ek aur bada packet block ho jaata hai (red).

Step 3 — Tunneling: poore packet ko ek naye envelope ke andar dalna

KYA: original packet ko inner packet ka naam do. Iske aage ek naya outer header $H_{outer}$ lagao. Result hai tunnel packet.

$TunnelPacket = new nametag routers read H_{outer} ∥ the whole old packet, now just "data" [H_{inner} ∥ payload]$

Symbol $∥$ ka matlab hai "saath mein glued" (bytes ka concatenation).
$H_{outer}$ woh ek hi part hai jo raaste ke routers padhte hain.
Bracketed part unke liye opaque hai — woh andar kabhi nahi dekhte.

KYUN yeh tool: routers outermost header padh kar route karte hain. Unhe ek valid public outer header do aur woh khushi se ek aisa packet carry karenge jo unhe samajh nahi aata — exactly waisi hi tarah ek WireGuard ya IPsec tunnel ek private packet ko Internet ke across smuggle karta hai.

PICTURE: original orange+blue packet ek single blue "inner" block mein shrink ho jaata hai, aur ek fresh orange outer header left par snap ho jaata hai.

Step 4 — The squeeze: outer header darwaaze mein se khata hai

KYA: ab tunnel packet ko Step 2 ke usi $1500$ B darwaaze se push karo. Darwaza bada nahi hua — lekin packet bada ho gaya, kyunki humne $H_{outer}$ add kiya.

KYUN: yahi toh core baat hai. Darwaaze ki width physical link se fixed hai (ise $MTU_{path}$ kaho, route mein kahin bhi sabse chhoti MTU). Outer header mandatory overhead hai. Toh outer header jitni bhi space leta hai woh inner packet se chori ho jaati hai.

Outer header ka size $h$ (bytes mein) naam dete hain:

$h = ∣ H_{outer} ∣$

Tunnel packet ko abhi bhi Step 2 ka rule maanna hoga:

$outer header h + whole inner packet L_{inner} \leq doorway MTU_{path}$

Yahan $L_{inner}$ inner packet ki total size hai (uska apna header plus uska payload — ab yeh sab ek lump count hota hai).

PICTURE: orange outer header blue inner block ko rightward push karta hai jab tak uska ek part band darwaaze ke edge se jam na jaaye — woh jamed slice hi woh space hai jo hum kho chuke hain.

Step 5 — Inner limit ke liye solve karo: the effective MTU

KYA: Step 4 ki inequality lo aur $L_{inner}$ ko isolate karo — inner packet kitna bada ho sakta hai.

$L_{inner} \leq MTU_{path} - h$

Hum is sabse badi allowed value ko apna naam dete hain, effective inner MTU:

$MTU_{inner} = MTU_{path} - h$

Term by term:

$MTU_{inner}$ — sabse choda packet jo tunnel andar carry kar sakta hai.
$MTU_{path}$ — path ka real darwaza width (sabse chhoti link MTU).
$h$ — outer header ne jo bytes churaaye (aur koi bhi encryption/auth trailer, ek VPN mein).

KYUN subtraction aur kuch fancy nahi: headers ek fixed number of bytes hain jo ek baar har packet mein add hote hain — ek flat toll, koi percentage nahi. Flat toll subtraction se hata diya jaata hai. Yahi poori wajah hai ki formula mein minus sign hai.

PICTURE: darwaze ki bar do coloured segments mein split — $h$ width ka ek fixed orange slice (the toll) aur $MTU_{path} - h$ width ka ek green slice (jo bacha hai tumhare inner packet ke liye).

Step 6 — The overhead ratio: tumhara pipe kitna waste ho raha hai

KYA: engineers yeh bhi jaanna chahte hain ki wire ka kitna fraction data ki bajaye wrapper par kharcha hota hai. Agar inner packet $L$ bytes ka hai aur wrapper $h$ bytes add karta hai, toh total mein wrapper ka share hai:

$overhead ratio = \frac{h}{L + h}$

Numerator $h$ — pure wrapper ke bytes.
Denominator $L + h$ — wire par actually bheje gaye total bytes.

KYUN ratio aur sirf $h$ nahi: $28$ wasted bytes ek bade $1472$ B packet par kuch nahi hain lekin ek tiny $40$ B packet par bahut bada hain. Sirf ratio hi capture karta hai "is trip ka kitna hissa waste tha."

PICTURE: do pie-style bars — ek bada packet (overhead ka patla orange sliver) versus ek tiny packet (mota orange overhead) — same $h$ , bilkul alag waste.

Step 7 — Degenerate & edge cases (reader ko kabhi stranded mat chodo)

KYA + KYUN + PICTURE — chaar scenarios jinse formula ko bachna chahiye:

Koi tunnel nahi ( $h = 0$ ): $MTU_{inner} = MTU_{path} - 0 = MTU_{path}$ . Formula collapse ho jaata hai "bas darwaza" — sanity check passed: koi wrapper nahi toh kuch nahi khota.
Wrapper utna bada jitna darwaza ( $h = MTU_{path}$ ): $MTU_{inner} = 0$ . Data ke liye zero bytes bache — tunnel pure overhead hai aur kuch carry nahi kar sakta. Ek valid warning sign, koi paradox nahi.
Wrapper darwaaze se bada ( $h > MTU_{path}$ ): formula negative ho jaata hai. Negative MTU physically impossible hai — iska matlab hai yeh path yeh tunnel bilkul carry nahi kar sakta; tumhe path lower karna hoga ya wrapper chhota karna hoga.
Nested tunnels (ek tunnel ke andar ek tunnel): har layer apna header subtract karti hai. Do wrappers $h_{1}, h_{2}$ dete hain $MTU_{inner} = MTU_{path} - h_{1} - h_{2}$ . Tolls simply stack ho jaate hain — isliye ek 6in4 tunnel ke andar VPN surprisingly kam room chhod sakta hai.

PICTURE: darwaaze ki bar chaar baar redraw ki gayi, har case ke liye, green "usable" slice poori se shrink hoke zero, phir negative (hatched red = impossible), phir double-toll stack tak.

The one-picture summary

Poori derivation ek frame mein: $MTU_{path}$ width ka ek fixed darwaza, outer header ka $h$ bytes ka orange toll, aur green remainder $MTU_{path} - h$ jo sabse bada inner packet hai jo tunnel carry kar sakta hai.

Recall Feynman: plain words mein walkthrough

Socho ek letter ko ek mail slot ke through bhejne ki, jo exactly ek fixed size ka hai. Tumhara letter ek packet hai: ek chhota "to/from" band (the header) aur message (the payload). Ab maano letter ko ek aisi country cross karni hai jo use as-is accept nahi karegi, toh tum poore letter, band aur sab, ko ek bade envelope mein stuff karte ho aur bahar fresh address likhte ho — woh ek tunnel hai. Lekin mail slot bada nahi hua! Naye envelope ka apna band slot-space chura leta hai, isliye tumhara original letter ab thoda chhota hona chahiye taaki abhi bhi fit ho sake. Kitna chhota? Exactly utne bytes jitne outer band use karta hai — unhe subtract karo, yahi effective inner MTU hai. Agar wrapper tumhare letter ke comparison mein tiny hai, almost koi waste nahi; agar tumhara letter ek keystroke hai, wrapper use dwarf kar deta hai aur trip ka zyada hissa packaging hai. Aur corner cases theek behave karte hain: koi wrapper nahi matlab koi loss nahi, slot jitna bada wrapper kuch nahi chhodta, slot se bada wrapper matlab "impossible — fit nahi hoga," aur do envelopes stack karna bas do tolls pay karna hai.

Recall

Effective inner MTU formula ::: $MTU_{inner} = MTU_{path} - h$ Overhead ratio formula ::: $h / (L + h)$ Path 1500 aur IP+GRE header (28 B) ke liye inner MTU ::: $1472$ B h=28 ke saath 12-byte inner packet ke liye overhead ratio ::: $70%$ Correction subtraction kyun hai, percentage kyun nahi ::: header ek fixed flat number of bytes hai jo ek baar add hota hai, isliye subtract karke hata diya jaata hai.

Related: NAT · Firewalls · Port forwarding · TLS · WebRTC · IPv4 exhaustion