పోర్ట్ ఫార్వార్డ్ vs VPN యాక్సెస్: ప్యాకెట్ నిజంగా ఎక్కడికి వెళుతుంది

పోర్ట్ ఫార్వార్డ్ గమ్యాన్ని తిరిగి రాసి అక్కడే ఆగుతుంది; VPN మొదట ప్యాకెట్ను చుట్టుతుంది. ఏ పొరను ఏది మారుస్తుంది, HTTPSకి దాని అర్థం ఏమిటో చూడండి.

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

DNAT నియమం గమ్యాన్ని తిరిగి రాసి అక్కడే ఆగుతుంది

Linux గేట్వేలో సేవను ప్రచురించడం అంటే nat పట్టికలోని PREROUTING గొలుసులో నియమం, లేదా nftablesలో దానికి సమానమైనది. నియమం పబ్లిక్ చిరునామా మరియు పోర్ట్తో సరిపోలి, తర్వాత గమ్యాన్ని అప్లికేషన్ యొక్క ప్రైవేట్ చిరునామాకు తిరిగి రాస్తుంది. మూల చిరునామా, మూల పోర్ట్ మరియు పేలోడ్ తాకబడకుండా ఉంటాయి, conntrack మ్యాపింగ్ను నమోదు చేస్తుంది, కాబట్టి ప్రతిస్పందనలు బయటకు వెళ్లేటప్పుడు తిరిగి రాయబడతాయి. ఈ ప్రవర్తన RFC 3022 లో వివరించిన సాంప్రదాయ చిరునామా అనువాద నమూనా.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

అప్లికేషన్ వినేది కనెక్షన్ అనువాదం ద్వారా వచ్చిందని ఎప్పటికీ తెలియదు. క్లయింట్ యొక్క నిజమైన మూల చిరునామాన్ని చూస్తుంది, ఇది యాక్సెస్ లాగ్లు మరియు వేగ పరిమితులకు ఉపయోగపడుతుంది, conntrack మ్యాపింగ్ను తిరగబెట్టడం వల్ల ప్రైవేట్ చిరునామాకు ప్రతిస్పందిస్తుంది. ఆ మార్గంలో ఏదీ డీక్రిప్ట్ లేదా తిరిగి ఎన్క్రిప్ట్ చేయబడదు: TLS ఇప్పటికీ క్లయింట్ మరియు అప్లికేషన్ యొక్క స్వంత ధృవపత్రం మధ్య నడుస్తుంది.

నియమం తర్వాత ఎదురయ్యే వైఫల్య విధానాలను కూడా నిర్ణయిస్తుంది. గేట్వే ఫార్వార్డ్ చేసినా అప్లికేషన్ హోస్ట్కు క్లయింట్కు తిరిగి వెళ్లే మార్గం లేకపోతే, ప్రతిస్పందనలు తప్పు మూలంతో బయటకు వెళతాయి మరియు హ్యాండ్షేక్ ఆగిపోతుంది. రెండవ నియమం మొదట సరిపోలితే, క్రమం ఫలితాన్ని నిర్ణయిస్తుంది, iptables -t nat -L -n -v ఏ నియమం ప్యాకెట్ను తీసుకుందో నిరూపించే కౌంటర్లను చూపుతుంది.

సొరంగం వినేది చూసే ముందు ప్యాకెట్ను చుట్టుతుంది

VPN అప్లికేషన్ను అసలు ప్రచురించదు. క్లయింట్ గేట్వే యొక్క పబ్లిక్ చిరునామాకు లక్ష్యంగా బయటి ప్యాకెట్ను నిర్మించి, లోపలి ప్యాకెట్ను దానిలో ఎన్క్రిప్ట్ చేస్తుంది, గేట్వే డీక్రిప్ట్ చేసి లోపలి ప్యాకెట్ను ప్రైవేట్ గమ్యానికి మళ్లిస్తుంది. WireGuardలో బయటి రవాణా UDP, సాధారణంగా ఎత్తైన పోర్ట్లో; OpenVPN TCP 443పై ఉన్నప్పుడు మార్గాన్ని గమనించే ఏదైనా దానికి బయటి ప్యాకెట్ TLSలా కనిపిస్తుంది.

సొరంగం లోపల లోపలి ప్యాకెట్ ప్రైవేట్ చిరునామాలను నిలుపుకుంటుంది: క్లయింట్ యొక్క సొరంగ చిరునామా, అనుకుందాం 10.8.0.6, మరియు అప్లికేషన్ 10.20.30.40 లో. అందువల్ల వినేది సొరంగ కొలనులోని మూలాన్ని చూస్తుంది, ప్రతి క్లయింట్ ఆ గేట్వేను తదుపరి దూకుడుగా పంచుకుంటుంది. VPN వెనుక ఉన్న యాక్సెస్ లాగ్లు వినియోగదారుకు బదులు గేట్వేను చూపడానికి సరైన కారణం ఇదే, గేట్వే అసలు మూలాన్ని కాపాడకపోతే.

చుట్టడం శీర్షిక స్థలాన్ని ఖర్చు చేస్తుంది, కొలవగల పరిణామం ఉన్న ఏకైక యాంత్రిక స్థాయి భేదం అదే. బయటి IP శీర్షిక మరియు UDP మరియు WireGuard యొక్క స్వంత శీర్షిక మార్గం యొక్క MTU నుండి తింటాయి, కాబట్టి పెద్ద ప్యాకెట్లను విభజించాలి లేదా లోపలి TCP స్టాక్ తన MSSని పరిమితం చేయాలి. ఫార్వార్డ్ చేసిన మార్గంలో పనిచేసే బదిలీ, మధ్యస్థ పరికరం చిన్న MTUను తెలిపే ICMPను పడవేసినప్పుడు సొరంగంలో ఆగిపోవచ్చు.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

ఎక్స్పోజర్ ప్రవేశం వద్ద నిర్ణయించబడుతుంది, సైఫర్ ద్వారా కాదు

రెండు డిజైన్లు ఒకే TLS వినేది వద్ద ముగుస్తాయి, కాబట్టి రెండూ ఒకే ధృవపత్రం, ఒకే ప్రోటోకాల్ వెర్షన్లు మరియు ఒకే అప్లికేషన్ లాగిన్ను వారసత్వంగా పొందుతాయి. మారేది హ్యాండ్షేక్ ప్రారంభించడానికి ఎవరికి అనుమతి ఉంది అనేది. పబ్లిక్ ఫార్వార్డ్లో, 203.0.113.10:443 ను చేరే ఏ హోస్ట్ అయినా మీ అప్లికేషన్ అధికారం పరిశీలించబడక ముందే TCP హ్యాండ్షేక్ మరియు TLS ClientHello పొందుతుంది. సొరంగం ద్వారా మాత్రమే యాక్సెస్లో, గేట్వే సొరంగంలోకి మళ్లించే చిరునామాల నుండి మాత్రమే వినేదిని చేరుకోవచ్చు, అపరిచితుడి SYN గేట్వే విధానంలో మరణిస్తుంది.

ఆ భేదం చేరుకోగల సామర్థ్యం గురించి, గోప్యత గురించి కాదు. ఫార్వార్డ్ చేసిన HTTPS సేవ సాధారణ పాఠ్యం కాదు, VPN అప్లికేషన్ ప్రామాణీకరణ అవసరాన్ని తొలగించదు: సొరంగంలోకి ప్రవేశం పరికరం ఈ నెట్వర్క్లోకి ప్యాకెట్లు పంపగలదా అని సమాధానమిస్తుంది, ఫైల్ అప్లికేషన్ వినియోగదారు పత్రాన్ని చదవగలరా అని. రెండింటినీ కలపడమే జట్లు మొత్తం LAN ఇచ్చే VPN మరియు ఒకే పంచుకున్న పాస్వర్డ్ ఉన్న అప్లికేషన్తో ముగిసే మార్గం.

వినేదిని మరియు విధానాన్ని విడివిడిగా తనిఖీ చేయండి, ఎందుకంటే వాటిలో ఏదైనా మీరు ఊహించినదానికంటే విస్తృతంగా ఉండవచ్చు:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss వినేది 0.0.0.0 కు బంధించబడి ఉందని చూపితే, రూటింగ్ మరియు ఫైర్వాల్ విధానం అనుమతించే ఎక్కడి నుండైనా అప్లికేషన్ చేరుకోగలదు, ఫార్వార్డ్ ప్రవేశించే మార్గాలలో ఒకటి మాత్రమే. ప్రైవేట్ చిరునామాకు బంధించడం, లేదా ఫైర్వాల్లో మూల పరిధిని పరిమితం చేయడం, VPN ఎంపికకు భిన్నమైన నిర్ణయం, ఎక్స్పోజర్ను నిజంగా తగ్గించేది ఆ నిర్ణయమే.

మార్గాన్ని కొలవండి, లేబుల్ కాదు

ఫార్వార్డ్ వేగంగా ఉందని ఎవరైనా చెబితే, నిజాయితీ పోలిక మిగిలిన అన్నింటినీ స్థిరంగా ఉంచుతుంది: అదే క్లయింట్, అదే యాక్సెస్ నెట్వర్క్, అదే ఫైల్, అదే TLS కాన్ఫిగరేషన్, అదే అప్లికేషన్ హోస్ట్. ప్రతి మార్గంలో బదిలీని రెండుసార్లు నడపండి మరియు మొత్తం సమయం, వైఫల్యాల సంఖ్య మరియు ప్రతిస్పందనను నమోదు చేయండి, సంబంధం లేని వేగ పరీక్ష అవుట్పుట్ కాదు.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

ఈ సంఖ్యలు కనెక్షన్ ఏర్పాటును బదిలీ సమయం నుండి వేరు చేస్తాయి, ఇది ముఖ్యం ఎందుకంటే రెండు మార్గాలు సాధారణంగా సైఫర్ ఖర్చులో కాదు, రాకపోకల ఆలస్యం మరియు MTUలో భిన్నంగా ఉంటాయి. TLS పని రెండు డిజైన్లలోనూ చివరల్లో జరుగుతుంది, సొరంగం ఎన్క్యాప్సులేషన్, వేరే మార్గం మరియు బహుశా రద్దీగా ఉన్న గేట్వేను జోడిస్తుంది. సొరంగ మార్గం పొడవైనా లేదా దాని గేట్వే భారంగా ఉన్నా, భేదం మార్గానిది, ఎన్క్రిప్షన్ అనే పదానిది కాదు.

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

డిజైన్ను పూర్తయిందని ప్రకటించే ముందు నాలుగు విషయాలను నిర్ధారించుకోండి: వినేది ఏ చిరునామాకు బంధించబడింది, ఏ నియమం లేదా మార్గం ప్యాకెట్ను లోపలికి అనుమతిస్తుంది, క్లయింట్ యొక్క నిజమైన చిరునామా నుండి తిరిగి వెళ్లే మార్గం పనిచేస్తుందా, పెద్ద పేలోడ్లు MTUను దాటుతాయా. వాటిలో ప్రతిదానికి పైన ఆదేశం ఉంది, ఏదీ «సురక్షితం» అనే పదం లేదా బ్యాండ్విడ్త్ చార్ట్తో సమాధానం ఇవ్వబడదు.

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