Exercises — NAT traversal, VPN, tunneling

• NAT outgoing packets ka source IP:port rewrite karke router ke public IP:port se replace karta hai, aur ek translation table rakhta hai taaki replies wapas map ho sakein — kai private hosts ek hi public address share karte hain.
• Tunnel ek complete packet ko kisi outer packet ka payload bana ke wrap karta hai, taaki woh aise network ko cross kar sake jo normally use route nahi karta.
• VPN ek tunnel hai jo encrypted aur authenticated bhi hota hai, jisse do endpoints ek hi private LAN ki tarah behave karte hain.

• STUN → ek host ko uska public IP:port batata hai jaisa bahar se dikhta hai.
• TURN → jab direct connection fail ho, tab traffic ko ek public server ke through relay karta hai.
• ICE → woh framework hai jo saare candidate addresses gather karta hai aur sabse accha working pair choose karta hai.
• Hole punching → dono peers simultaneously send karte hain taaki har ek outgoing packet ek NAT mapping khol sake jo doosre ka packet use kar sake.

Outer overhead $h=20+8=28$ B. Inner packet outer ke andar fit hona chahiye, isliye ${\text{MTU}}_{\text{inner}}={\text{MTU}}_{\text{path}}-h=1500-28=\boxed{1472\text{B}}.$ Figure s01 — kya dekhna hai: cyan outline pura 1500 B path budget hai; left side ka amber block woh $28$ B outer header hai jo kisi bhi inner data se pehle kharcha hota hai; faint cyan block woh hai jo bachta hai — exactly $1472$ B. Picture yeh dikhata hai ki header front se subtract hota hai, upar se add nahi.

$\frac{h}{L+h}=\frac{28}{1472+28}=\frac{28}{1500}=0.018\overline{6}\approx 1.9\%.$ Toh ek full-sized packet ke liye tunnel wire ka sirf $1.9\%$ wrapper bytes pe waste karta hai — chhota hai, lekin tiny packets ke liye sharply badhta hai (agla question).

$\frac{28}{40+28}=\frac{28}{68}\approx 0.4118=41.2\%.$ Wahi header ab $41.2\%$ cost karta hai — 20× se zyaada bura — kyunki wrapper ek fixed cost hai jo kam payload bytes mein spread hoti hai.

Sabse likely symmetric NAT hai. Symmetric NAT per destination ek naya public port allocate karta hai. STUN server ne woh mapping dekhi jo STUN server ko traffic ke liye bani thi, yaani 203.0.113.9:40000. Jab wahi host ab peer ko (alag destination IP:port) send karta hai, NAT ek alag public port kholta hai — isliye STUN server ne jo port report kiya tha woh peer ka path describe nahi karta. Peer ek stale mapping pe send karta hai aur drop ho jaata hai. Yahi reason hai kyun symmetric NAT TURN par fallback force karta hai.

Notation note: neeche double-headed arrow "$\leftrightarrow$" ka matlab sirf "paired/associated hai" — yeh mark karta hai woh two-way link jo ek NAT table row tumhari public mapping aur us specific remote peer ke beech record karta hai jiski liye woh khuli thi. Yeh subtraction ya koi operation nahi hai, sirf "yeh dono ek saath belong karte hain".

Pehle, do flavours (dono "restricted-cone" hain, farq sirf kitna strict return filter hai usمیں hai):

• Address-restricted cone — ek inbound packet tab hi admit hota hai jab uska source IP kisi aise IP se match kare jisme inside host pehle se send kar chuka ho; us IP se koi bhi port allowed hai.
• Port-restricted cone — zyaada strict: inbound packet ka source IP aur source port dono ko kisi aisi cheez se match karna hoga jisme inside host ne send kiya ho.

Ab attack. Tumhare outgoing punch ne yeh pair create kiya: $(\text{your public IP:port})\leftrightarrow (\mathrm{198.51.100.7}:6000,\text{the peer}).$

• Address-restricted NAT ke under filter sirf source IP check karta hai → woh inbound packets forward karta hai jinka source IP 198.51.100.7 ho. Attacker ka source 45.10.10.10 IP check mein fail → dropped.
• Port-restricted NAT ke under filter aur tight hai, source IP aur port dono check karta hai → attacker immediately fail karta hai.

Kisi bhi case mein attacker andar aata hai: nahi. "Hole" peer-specific hai (IP tak, aur port-restricted NAT ke under exact port tak), general khula darwaza nahi hai.

Step 1 — outer overhead byte-by-byte derive karo. $52$ B koi magic number nahi hai; yeh ek common IPsec ESP-in-tunnel-mode configuration ke concrete header fields ka sum hai AES-CBC + HMAC ke saath:

Variable pieces (IV, padding, ICV) exactly yahi reason hai kyun real ESP overhead fluctuate karta hai — worst-case padding use $32$ B se kaafi aage push kar sakta hai. Is exercise ke liye hum ek representative ESP contribution of $32$ B lete hain ($=8+16+\text{small padding}+\text{trailer}+\text{ICV rounded}$), jo outer total $20+32=52$ B deta hai. Hamesha apna ESP assumption state karo; "32" ko universal mat memorise karo.

Step 2 — MTU budget karo har wrapper subtract karke, outermost pehle: $1500-52=1448(\text{VPN ke baad}),$ $1448-20=\boxed{1428\text{B}}(\text{6in4 ke baad}).$ Overheads additively stack hote hain kyunki har layer ka header pichli layer ke payload ke andar hota hai. Nested tunnels "bade transfers stall ho jaate hain" bugs ki classic wajah hain. Figure s02 — kya dekhna hai: wahi 1500 B pipe ke liye teen stacked bars. Top white outline raw path hai; har lower bar left pe aur ek amber (VPN 52 B) ya cyan (6in4 20 B) header slice add karta hai, aur usable payload (faint cyan) har baar shrink hota hai — $1500\to 1448\to 1428$ dekhne ke liye labels right-to-left padho.

Term reminder — "signalling channel": koi bhi media flow hone se pehle, dono browsers ko ek tarika chahiye apne discover kiye gaye candidate addresses ki lists exchange karne ka. Woh out-of-band application channel (typically apne web server ke through ek chhota WebSocket/HTTPS connection, peer-to-peer path nahi) signalling channel kehlata hai. Yeh sirf setup metadata carry karta hai, media nahi.

1. Har browser candidates gather karta hai — ICE chaar type recognize karta hai:
   • host candidate — uska apna local 192.168.x.x:port.
   • server-reflexive candidate — uska public mapping, STUN server se poochh ke seekha "tum mujhe kaun sa address dekhte ho?"
   • peer-reflexive candidate — runtime pe discover hua mapping: jab ek connectivity check kisi aisi address se aata hai jisko kisi ne advertise nahi kiya (aksar isliye kyunki NAT ne peer-to-peer path ke liye naya mapping create kiya), receiver us newly-seen source ko peer-reflexive candidate ke roop mein record karta hai aur pool mein add karta hai. Yeh woh quadrant hai jo STUN pre-discover nahi kar sakta.
   • relayed candidate — TURN server pe ek address, pehle se reserved.
2. Candidates signalling channel ke through exchange hote hain jaise upar define kiya.
3. ICE local×remote candidates pair karta hai, priority se order karta hai (host > peer-reflexive > server-reflexive > relayed, kyunki relay sabse slow/costly hai), aur har pair pe connectivity checks (STUN pings) bhejta hai — yahi checks peer-reflexive candidates reveal karte hain.
4. ICE woh highest-priority pair choose karta hai jo actually kaam karta hai. Agar dono symmetric NAT ke peeche hain aur koi direct pair succeed nahi karta, ICE TURN-relayed pair pe fallback karta hai — hamesha kaam karta hai, lekin relay hop add hota hai. Net effect: jab possible ho direct, relay sirf jab zaroorat ho.

• Tunnel mode. Site-to-site ko puri inner IP packets carry karni hoti hain jo private 10.x hosts ko addressed hain, public Internet ke across. Tunnel mode poore inner IP packet ko encrypt karta hai aur ek naya outer IP header prepend karta hai (gateway→gateway), taaki private addresses hidden rahein aur sirf andar route ho sakein. Transport mode sirf payload encrypt karta hai aur original IP header rakhta hai — koi kaam ka nahi jab original addresses non-routable private hon.
• TLS on 443 roaming worker ke liye kyunki restrictive networks (hotels, cafés) aksar IPsec/UDP block karte hain lekin 443 almost kabhi block nahi karte — VPN traffic ordinary HTTPS jaisi lagti hai aur firewalls se slip kar jaati hai.

Pehle, do terms jinki hamen zaroorat hogi:

• DF (Don't Fragment) flag — IPv4 header mein ek single bit. Jab set ho, ek router jo packet ko next link ke liye bada paata hai, use fragment karna forbidden hai; usse packet drop karni hoti hai aur sender ko ICMP "Fragmentation Needed" message wapas bhejna hota hai jo chhota MTU batata hai. Yeh mechanism Path MTU Discovery (PMTUD) hai.
• ICMP black-hole — agar path mein koi firewall silently un ICMP "too big" messages ko discard kar de, sender ko kabhi pata nahi chalta ki use shrink karna hai. Bade DF packets drop hote rehte hain bina kisi feedback ke → transfer sirf hang ho jaata hai. Yahi broken state tunnel MTU bugs ko itna pareshaan karta hai.

(a) Inner MTU $=1420-60=\boxed{1360\text{B}}$. (b) MSS TCP payload per segment hai, isliye inner IP+TCP header (40 B) inner MTU se subtract karo: $\text{MSS}=1360-40=\boxed{1320\text{B}}.$ (c) Bulk downloads full-size packets use karte hain jo wrap hone ke baad path MTU exceed kar lete hain; DF flag set hone ke saath woh drop ho jaate hain aur — agar PMTUD ka ICMP feedback black-hole ho jaaye — kabhi resize nahi hote, isliye transfer stall ho jaata hai, jabki chhote browsing requests already fit ho jaate hain aur theek lagte hain. MSS ko $1320$ B clamp karna force karta hai ki har TCP segment itना chhota born ho ki pura wrapped packet survive kar sake.

• "Mera ISP kuch nahi padh sakta" — partly true: ISP sirf gateway tak encrypted VPN traffic dekhta hai, isliye content ke liye yeh clause theek hai, lekin ISP phir bhi dekhta hai ki tum VPN use kar rahe ho aur traffic volume bhi.
• "VPN provider kuch nahi padh sakta" — false. Traffic VPN server pe decrypt hoti hai; usse aage packets inner protocol jis form mein ho usमें bank ki taraf exit karte hain. Provider ab woh party hai jo tumhari traffic dekh sakti hai. Sirf end-to-end TLS (HTTPS) content ko provider se bhi chhupata hai.
• "Fully anonymous" — false. Bank phir bhi tumhe authenticate karta hai (login, cookies). VPN sirf kaun sa IP dikhta hai aur kisPar trust karna hai change karta hai, tum kaun ho yeh nahi. Correct model: ek VPN trust boundary shift karta hai tumhare ISP/local network se VPN provider ki taraf, aur encryption sirf VPN server tak hoti hai. Anonymity aur end-to-end secrecy alag properties hain jo doosre tools se milti hain.

• host × host candidate pair — sirf tab kaam karta hai jab dono same LAN pe hon (do remote users ke case mein nahi).
• server-reflexive candidates — yahan useless hain: symmetric NAT per destination naya port deta hai, isliye STUN-learned port peer path par apply nahi hota.
• peer-reflexive candidates — symmetric NAT per destination mapping change karta rehta hai, isliye ek check pe runtime-discovered address agla check tak survive karna zarooori nahi; yahan unreliable hai.
• relayed candidates — intended fallback hai, lekin TURN blocked hai, isliye unavailable. Honest outcome: connection fail ho jaata hai. Dono ends pe symmetric NAT aur koi working relay nahi hone se ICE apne options exhaust kar chuka hai. Yeh textbook scenario hai jahan NAT traversal succeed nahi kar sakta — sirf ICE ke bahar ke fixes kaam karenge (jaise ek side pe Port forwarding / static mapping, IPv6 global address ke saath, ya reachable relay).

NAT tumhe chhupata hai, isliye bahar wala knock nahi kar sakta. STUN tumhe woh address batata hai jo duniya dekhti hai; agar woh stable hai, tum aur tumhara dost ek saath knock karte ho (hole punching) aur dono darwaze khul jaate hain. Agar tumhara NAT har dost ke liye apna port change karta hai (symmetric), tum haath utha dete ho aur ek helper ke through route karte ho (TURN). Har wrapper jo tum add karte ho — tunnel, VPN, nested tunnel — tumhare packet se bytes chura leta hai, isliye tumhe packet shrink karna hoga (MSS ghata do) taaki woh itna mota na ho ki pass na ho sake. Aur VPN tumhe invisible nahi banata; woh sirf yeh change karta hai ki kisko tumhare secrets ke saath trust karna hai.