ఒక SSH సెషన్, ఒక వెబ్ యాప్ మరియు ఒక పేరు శోధన పోర్ట్ల కోసం పోరాడకుండా ఒకే VPN కనెక్షన్ను పంచుకోగలవు. క్లయింట్ గేట్వే వైపు ఒక గుప్తీకరించిన ప్రవాహాన్ని నిర్మిస్తుంది, మరియు ప్రతి అప్లికేషన్ సంభాషణ దాని లోపల ప్రయాణిస్తుంది. బయట సొరంగం యొక్క స్వంత రవాణా మరియు పోర్ట్ మాత్రమే కనిపిస్తాయి. లోపల ప్రతి సేవ తన స్వంత పోర్ట్ను ఉంచుకుని ఇప్పటికీ తన స్వంత అనుమతి అవసరం.

బయటి ప్రవాహం ఏమి మోస్తుంది, ఏమి దాచుతుంది

క్లయింట్ ప్రతి ప్యాకెట్ను మెషీన్ నుండి బయటకు వెళ్లే ముందు సొరంగం రవాణాలో చుట్టుతుంది. ఆ బయటి ప్రవాహానికి VPN కాన్ఫిగర్ చేసినప్పుడు నిర్ణయించిన ఒక గమ్యస్థాన పోర్ట్ ఉంటుంది. రేపర్ లోపల ప్రతి అసలు ప్యాకెట్ తాను లక్ష్యంగా చేసుకున్న సేవ చిరునామా మరియు పోర్ట్ను ఉంచుకుంటుంది. గేట్వే రేపర్ను తీసివేసి లోపలి హెడర్ ప్రకారం మార్గనిర్దేశం చేస్తుంది, కాబట్టి గమ్యం నెట్వర్క్ నుండి వచ్చే సాధారణ క్లయింట్ను చూస్తుంది.

అందుకే WAN ఇంటర్ఫేస్పై క్యాప్చర్ మూడు కాదు, ఒక సంభాషణను చూపుతుంది. లోపలి పోర్ట్లు డీక్యాప్సులేషన్ తర్వాత మాత్రమే కనిపిస్తాయి. అందుకే ఒక ఫైర్వాల్ రంధ్రం SSH, HTTPS మరియు DNS లను ఒకేసారి మోయగలదు.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP డాక్యుమెంటేషన్ మార్గనిర్దేశిత TUN పరికరం కెర్నల్ మరియు వినియోగదారు స్పేస్ ప్రాసెస్ మధ్య IP ప్యాకెట్లను అందించే హ్యాండ్ఓఫ్ను వివరిస్తుంది. ఆ హ్యాండ్ఓఫ్ లోపలి హెడర్ను గేట్వే మార్గనిర్దేశం మరియు ఫైర్వాల్ కోడ్కు కనిపించేలా చేస్తుంది. ఏ సేవలు అనుమతించబడ్డాయనే దాని గురించి బయటి పోర్ట్ ఏమీ చెప్పకపోవడానికి కారణాన్ని కూడా వివరిస్తుంది.

NAT ఫార్వర్డింగ్ శ్రోతకు చెందుతుంది, అప్లికేషన్లకు కాదు

IPv4 NAT వెనుక స్వీయ-హోస్ట్ గేట్వేకు ఒక ఇన్బౌండ్ అనువాదం అవసరం: పబ్లిక్ చిరునామా మరియు పోర్ట్ VPN శ్రోతకు మ్యాప్ చేయబడతాయి. సొరంగ వినియోగదారులు చేరుకుంటున్నందుకే SSH, HTTPS లేదా DNS కి ఎటువంటి నియమం అవసరం లేదు. ఆ పోర్ట్లను ప్రచురించడం సొరంగం ఇప్పటికే రక్షిస్తున్న సేవలను బయటపెడుతుంది. ఫార్వర్డింగ్ నియమం శ్రోత యొక్క చేరుకోగల తనాన్ని వివరిస్తుంది, లోపల ఏదైనా అనుమతి కాదు.

వ్యతిరేకం కూడా నిజం. సొరంగ పోర్ట్ను తెరవడం వేరే ఏదీ బయటపెట్టదు, కాబట్టి సొరంగం ద్వారా మాత్రమే చేరుకోగల సేవ తన పబ్లిక్ ఉపరితలాన్ని మూసి ఉంచుతుంది. ఆ విభజన సాధారణంగా సేవను ప్రైవేట్గా ఉంచడానికి కారణం.

ప్రవేశం నిజంగా నిర్ణయించబడేది లోపలి విధానంలోనే

గుప్తీకరణ మార్గాన్ని రక్షిస్తుంది; అది గమ్యానికి అధికారం ఇవ్వదు. ఏ ప్రిఫిక్స్లు సొరంగంలోకి ప్రవేశిస్తాయో క్లయింట్ మార్గాలు ఎంచుకుంటాయి, ప్యాకెట్లు దాని నుండి బయటకు వెళ్లగలవా అని గేట్వే ఫార్వర్డింగ్ విధానం నిర్ణయిస్తుంది, సేవ సమాధానం ఇస్తుందా అని గమ్యం ఫైర్వాల్ మరియు లాగిన్ నిర్ణయిస్తాయి. DNS అత్యంత స్పష్టమైన సందర్భం: ప్రశ్నలను మోయడం వల్ల రిజాల్వర్ వాటిని మీ క్లయింట్ పూల్ నుండి అంగీకరించదు. ప్రతి పొర స్వతంత్రంగా కాదు అని చెప్పగలదు.

సొరంగం ద్వారా ప్రతి సేవను విడిగా పరీక్షించండి. విజయవంతమైన శోధన వెబ్ పోర్ట్ గురించి ఏమీ చెప్పదు, విజయవంతమైన వెబ్ అభ్యర్థన SSH గురించి ఏమీ చెప్పదు.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

సొరంగం నడుస్తున్నప్పుడు అన్నీ విఫలమైతే మొదట క్లయింట్ మార్గ పట్టికను చదవండి. ఒక సేవ విఫలమైతే మిగతావి పనిచేస్తుంటే, లోపం ఆ గమ్యంలో ఉంది. ఈ రెండు పరిశీలనలు వేర్వేరు బాధ్యులను సూచిస్తాయి, వాటిని కలపడం సమయాన్ని వృథా చేస్తుంది.

WireGuard అదే గీతను గీస్తుంది

WireGuard తన బయటి శ్రోతను ListenPort అని పిలుస్తుంది, లోపలి అప్లికేషన్ ఇప్పటికీ తనకు అవసరమైన సేవ పోర్ట్ను ఉపయోగిస్తుంది. AllowedIPs అనేది మార్గనిర్దేశిత ప్రిఫిక్స్ల సమితి, అనుమతించిన సేవ పోర్ట్ల జాబితా కాదు. దాన్ని పోర్ట్ అనుమతి జాబితాగా చదవడం సొరంగం చేసే దానికి సరిపోని నియమాలను ఉత్పత్తి చేస్తుంది. నామకరణం భిన్నం; పొరలు కాదు.

సేవ హోస్ట్పైనే నడుస్తుంటే స్థానిక ఇన్పుట్ విధానంలో, లేదా ఆ హోస్ట్ వెనుక ఉంటే ఫార్వర్డింగ్ విధానంలో దాన్ని అనుమతించండి. ఈ భేదం ఏ నియమ సమితి ప్యాకెట్ను చూస్తుందో నిర్ణయిస్తుంది.

సాధారణ రూపం అనేక లోపలి సంభాషణలతో ఒక బయటి రవాణా. అనేక బయటి మార్పిడులు లేదా వేరే IP ప్రోటోకాల్ అవసరమయ్యే ఉత్పత్తులు, ఒక-పబ్లిక్-పోర్ట్ నమూనా ఈ రూపకల్పనను వివరిస్తుంది, ప్రతి VPN కాదు అని గుర్తు చేస్తాయి.

సంబంధిత వ్యాసాలు