4.3.30 · D5 · HinglishComputer Networks
Question bank — NAT traversal, VPN, tunneling
4.3.30 · D5· Coding › Computer Networks › NAT traversal, VPN, tunneling
Yahan har answer justified hai, kabhi bhi bare "true/false" nahi. Ek-word answer ka score zero hai.
Teen pictures jinhe yeh page baar baar refer karta hai
True ya false — justify karo
TF1. Ek NAT router har private host ko apna public IP address assign karta hai.
False. NAT ka poora point yahi hai ki kaafi saare private hosts ek hi public IP share karte hain; router replies ko ports rewrite karke alag karta hai (Figure 1 dekho), addresses de karke nahi. NAT dekho.
TF2. NAT mainly security ke liye banaya gaya tha.
Mostly false. Iska purpose tha IPv4 exhaustion se ladna, ek address share karke; "outsiders connection shuru nahi kar sakte" wala effect ek side benefit hai, design goal nahi — real security ek asli firewall karta hai.
TF3. Jab IPv6 har jagah ho jayega, NAT traversal ki problems poori tarah khatam ho jayengi.
Principle mein true. IPv6 har host ko globally routable address deta hai, isliye translate karne ke liye kuch nahi hoga — lekin firewalls phir bhi unsolicited inbound packets block kar sakte hain, isliye reachability logic (jaise Port forwarding) persist ho sakta hai.
TF4. Ek tunnel hamesha inner packet ko encrypt karta hai.
False. Tunneling sirf ek packet ko doosre ke andar wrap karta hai (Figure 2) — jaise 6in4 IPv6 ko IPv4 ke upar clear mein carry karta hai. Encryption woh hai jo ek VPN upar se add karta hai; ek plain tunnel poori tarah readable hota hai.
TF5. STUN akela do peers ko connect karne ki guarantee de sakta hai.
False. STUN sirf tumhari public mapping reveal karta hai; symmetric NAT ke peechhe mapping har destination ke saath badal jaati hai, isliye jo STUN ne dekha woh peer ke liye bekaar hai aur tumhe TURN par fall back karna padega.
TF6. TURN direct connection se worse privacy deta hai kyunki relay tumhara traffic dekhta hai.
Partly true. Relay tumhare packets forward karta hai. Chahe payload end-to-end encrypted ho (jaise WebRTC mein) taaki relay sirf ciphertext dekhe, phir bhi woh metadata observe karta hai — kaun kisse baat karta hai, packet timing, sizes, aur outer headers — saath hi extra latency aur bandwidth bhi lagta hai. Encryption content chhupata hai, conversation ka fact aur shape nahi.
TF7. Ek VPN tumhe online anonymous bana deta hai.
False. Encryption sirf VPN server tak hoti hai, jo sab kuch dekhta hai aur log kar sakta hai; uske aage traffic clear mein nikalta hai jab tak TLS protect na kare. Ek VPN move karta hai ki tumhe kis par trust karna hai, woh tumhe erase nahi karta.
TF8. Hole punching tumhare NAT ki protection disable kar deta hai aur attackers ko andar aane deta hai.
False. Punched hole ek specific mapping hai (tumhara port us ek peer ke liye, Figure 3). Restricted-cone NAT par, sirf us peer ka IP:port admit hota hai; ek random attacker ke paas phir bhi koi table entry nahi hai.
Error dhundho
SE1. "Ek tunnel packet ka outer header private 10.x address carry karta hai taaki packet Internet ke paar route ho sake."
Error: yeh ulta hai. Inner header non-routable
10.x address rakhta hai; outer header ek public IP carry karta hai taaki routers actually deliver kar sakein (Figure 2, blue outer layer). Private IP addressing dekho.SE2. "Kyunki routers ko tunneled packet forward karne ke liye inner protocol samajhna padta hai, tunneling slow hoti hai."
Error: routers sirf outer header padhte hain. Inner packet opaque payload hai — precisely isliye ek IPv4-only path ek IPv6 packet carry kar sakta hai bina use samjhe.
SE3. "1500-byte path MTU aur 28-byte outer header ke saath, inner packet phir bhi 1500 bytes ka ho sakta hai."
Error: inner packet outer ke andar fit hona chahiye, isliye effective inner MTU 1500 minus 28 hai, yaani 1472 bytes (Figure 2 mein pink bracket). Ise ignore karna classic "VPN kaam karta hai lekin bade downloads stall ho jaate hain" bug hai.
SE4. "Full-cone NAT traverse karna sabse mushkil hai."
Error: full-cone sabse aasaan hai — ek baar port open ho gaya, koi bhi use reach kar sakta hai. Symmetric NAT sabse mushkil hai kyunki woh har destination ke liye ek naya public port allocate karta hai.
SE5. "IPsec transport mode do networks ke beech site-to-site VPNs ke liye use hota hai."
Error: transport mode sirf existing packet ka payload encrypt karta hai; tunnel mode poore inner IP packet ko wrap aur encrypt karta hai aur yahi site-to-site links ke liye use hota hai.
SE6. "ICE ek NAT-traversal protocol hai jo STUN aur TURN ko replace karta hai."
Error: ICE ek framework hai jo STUN aur TURN use karta hai. Yeh candidates gather karta hai (local, STUN-reflexive, TURN-relayed) aur pairs test karke best working ek select karta hai.
Why questions
WQ1. NAT ke public IP par ek unsolicited inbound packet kyun drop ho jata hai?
Translation entry sirf tab create hoti hai jab inside host pehle bhejta hai. Koi matching table row nahi hone par (Figure 1 mein missing bottom row), router ke paas packet map karne ke liye koi private host nahi hai, isliye woh discard kar deta hai.
WQ2. Insider ko connection shuru karwana peer-to-peer contact kaise enable karta hai?
Insider ka outgoing packet ek NAT mapping install karta hai (ek hole punch karta hai); peer ki reply phir us existing hole se match karti hai aur pass ho jaati hai, bajaaye unsolicited ki tarah drop hone ke.
WQ3. Symmetric NAT STUN-based hole punching ko kyun defeat karta hai?
Symmetric NAT har naye destination ke liye ek alag public port allocate karta hai. STUN ne jo port observe kiya (STUN server se baat karte waqt) woh peer ki taraf jaate waqt use port nahi hai, isliye advertised mapping galat hai.
WQ4. Ek VPN 10.x packet ko sirf bhejne ki jagah doosre header mein kyun wrap karta hai?
10.x address public Internet par non-routable hai — routers ise drop kar dete hain. Outer public-IP header woh hai jo journey survive karta hai, private packet ko cargo ki tarah carry karta hai.WQ5. Ek TLS-based VPN restrictive firewalls se kyun nikal sakta hai?
Yeh port 443 par tunnel karta hai aur ordinary HTTPS traffic jaisa lagta hai, isliye jo firewall web browsing allow karta hai woh ise normal TLS sessions se aasani se alag nahi kar sakta.
WQ6. Encapsulation ki har layer real data ke liye bachi jagah kyun reduce karti hai?
Har outer header fixed path MTU se bytes consume karta hai, isliye inner payload ko compensate karne ke liye shrink karna padta hai — overhead unavoidable hai, sirf iska size vary karta hai.
WQ7. Authentication, sirf encryption nahi, ek VPN ka hissa kyun hai?
Encryption outsiders ko tunnel padhne se rokti hai, lekin authentication ke bina ek attacker aisi packets forge kar sakta hai jo trusted endpoint se aati lage — auth prove karta hai ki packet kisne daala.
WQ8. Port-preserving NAT traversal ko sometimes port-randomizing NAT se aasaan kyun banata hai?
Port-preserving NAT inside port number ko public port ke roop mein rakhta hai jab ho sake, isliye peer mapping guess kar sakta hai; port-randomizing NAT ek unpredictable public port choose karta hai, isliye guessing fail ho jati hai aur tumhe STUN se seekhna ya TURN se relay karna padta hai.
Edge cases
EC1. Dono peers ek hi NAT ke peechhe hain aur ek doosre ke public reflexive address par hole punching karte hain — kya galat ho sakta hai?
Kuch NATs "hairpin" nahi karte (traffic ko apne public IP par wapas loop nahi karte), isliye reflexive path fail ho jata hai; ICE ko local candidate addresses bhi try karne chahiye, jo succeed karte hain kyunki dono ek hi LAN par hain.
EC2. Ek tunnel ka inner packet bilkul path MTU size ka hai aur "don't fragment" bit set hai — kya hota hai?
Outer header ise MTU se upar push kar deta hai; router fragment nahi kar sakta (DF set hai) isliye packet drop kar deta hai aur (ideally) ICMP "too big" return karta hai — black-hole agar woh ICMP filter ho jaye.
EC3. VPN server khud NAT ke peechhe hai — kya woh phir bhi gateway ki tarah kaam kar sakta hai?
Sirf tab agar uske liye mapping exist karti ho: ise Port forwarding chahiye ya use woh side hona chahiye jo initiate kare, warna clients ke inbound packets use drop ho jayenge jaise kisi bhi unsolicited NAT traffic ki tarah.
EC4. Ek user VPN aur site HTTPS dono run karta hai — kya data do baar encrypt hota hai, aur kya yeh wasteful hai?
Haan, doubly encrypted (VPN tunnel + TLS), jo thoda CPU cost karta hai lekin good hai: TLS ise VPN ke exit point ke baad bhi protect karta hai, jahan VPN ki encryption already khatam ho chuki hoti hai.
EC5. Punched hole se kaafi der tak zero traffic flow karta hai — uska kya hota hai?
NAT mappings idle periods ke baad time out ho jaati hain, isliye hole band ho jata hai; peers periodic keepalive packets bhejte hain mapping refresh karne aur connection alive rakhne ke liye.
EC6. Ek peer ke paas NAT ke bina public IP hai — kya STUN/TURN phir bhi matter karte hain?
STUN simply wohi address report karta hai jo uske paas already hai (harmless), aur koi traversal ki zaroorat nahi; connection direct ho sakta hai, halanki firewall inbound block kar sakta hai aur configuration ki zaroorat pad sakti hai.
EC7. Tumhara ISP tumhe carrier-grade NAT (CGNAT) ke peechhe rakhta hai aur tumhara home router bhi NAT karta hai — yeh "double NAT" kya todta hai?
Ab do translation layers hain, aur outer wala tumhare control mein nahi hai. Tumhare home router par Port forwarding bekaar hai kyunki ISP ke CGNAT mein koi matching entry nahi, aur dono sides ka CGNAT'd hona often ek TURN relay force karta hai kyunki koi bhi directly reach nahi ho sakta.
EC8. CGNAT ke under, hazaron subscribers ek public IP share karte hain — yeh port behaviour ko kaise change karta hai?
Carrier ko bahut saare users mein ports bahut hi kanjoos tarike se baantne padte hain, isliye woh symmetric/port-randomizing NAT ki tarah behave karta hai (har flow ke liye naya port) — exactly woh case jahan STUN ki observed mapping unreliable hoti hai aur traversal sabse mushkil hoti hai.
EC9. Kya ek NAT jo port preserve karta hai, traversal ke liye hamesha rely karna safe hai?
Nahi — woh port tab tak preserve kar sakta hai jab tak collision na ho, phir silently random port par switch ho sakta hai. Traversal logic ko gracefully fall back karna chahiye, kyunki "port-preserving" ek best-effort behaviour hai, guarantee nahi.
Recall Quick self-test: failure mode ka naam batao
Symmetric NAT kaun si technique todta hai, kaun se fallback ko force karta hai? ::: STUN-based hole punching todta hai (galat port advertised); TURN relay fallback force karta hai. Outer header size ignore karne wala tunnel kaun sa symptom cause karta hai? ::: Oversized inner packets → fragmentation ya silent drops (bade transfers stall ho jaate hain) effective inner MTU exceed hone se. "VPN = anonymous" fail hota hai kyunki encryption kahan khatam hoti hai? ::: VPN server par, jo tumhara traffic dekhta hai aur use clear mein bahar nikalta hai jab tak end-to-end TLS protect na kare. Double/carrier-grade NAT ek single home NAT se zyada mushkil kyun hai? ::: Tum outer (ISP) translation layer control nahi karte, isliye port forwarding fail hota hai aur CGNAT ke per-flow ports often ek relay force karte hain.