VPN గేట్‌వే రెండు వైపులా క్యాప్చర్ పెట్టండి, ఒక ప్రవాహం నాలుగు వేర్వేరు చిరునామాలను చూపగలదు. మూల NAT ప్యాకెట్ ఎక్కడి నుండి వస్తున్నట్లు చెబుతుందో తిరిగి రాస్తుంది; గమ్య NAT అది ఎక్కడికి వెళ్తుందో తిరిగి రాస్తుంది. Masquerade మూడవ దిశ కాదు, స్థిర విలువకు బదులు బయలుదేరే ఇంటర్‌ఫేస్ చిరునామాను తీసుకునే మూల-NAT నియమం. మూడింటిలో మీకు నిజంగా ఏది కావాలో పేరు పెట్టండి, చాలా «VPN పాడైంది» టికెట్లు తిరిగి వచ్చే మార్గం గురించిన ప్రశ్నగా కుదించబడతాయి.

ప్రతి నియమం ఏమి తిరిగి రాస్తుంది

మూల NAT, సాధారణంగా SNAT అని రాస్తారు, ప్రవాహం రౌటర్ లేదా గేట్‌వేను విడిచిపెట్టినప్పుడు దాని మూల చిరునామాను మారుస్తుంది. స్వీకరించే సేవ అనువదించిన చిరునామాకు ప్రతిస్పందిస్తుంది, అనువాదం చేసే పెట్టె ఆ కనెక్షన్ కోసం ఉంచుకున్న స్థితిని ఉపయోగించి మార్పును తిరిగి తిప్పుతుంది. Linux లో ఆ స్థితి conntrack లో నివసిస్తుంది, అందుకే conntrack -L అసలు మరియు ప్రతిస్పందన జంటలను పక్కపక్కనే ముద్రిస్తుంది.

గమ్య NAT, DNAT, దానికి బదులుగా గమ్యాన్ని మారుస్తుంది. UDP 51820 లో పబ్లిక్ చిరునామాకు పంపిన ప్యాకెట్‌ను 10.8.0.2:51820 లోని అంతర్గత WireGuard సర్వర్‌కు తిరిగి రాయవచ్చు. ఇంటి రౌటర్ లేదా క్లౌడ్ లోడ్ బ్యాలెన్సర్ VPN శ్రోతను ఇలాగే ప్రచురిస్తుంది, అది సొరంగం తర్వాత ఏమి మోయగలదో గురించి ఏమీ చెప్పదు.

Masquerade SNAT కుటుంబానికి చెందుతుంది. నియమం ఏ చిరునామానూ పేర్కొనదు; ప్యాకెట్ బయలుదేరే సమయంలో బయలుదేరే ఇంటర్‌ఫేస్ వద్ద ఉన్న చిరునామాను ఉపయోగిస్తుంది. Linux దానికి సొంత లక్ష్యాన్ని ఇస్తుంది, DHCP లేదా PPPoE నుండి చిరునామా పొందే WAN ఇంటర్‌ఫేస్‌లో ఇది సాధారణ ఎంపిక.

మ్యాపింగ్ ఎక్కడ నివసిస్తుందో అది వైఫల్యాన్ని నిర్ణయిస్తుంది

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

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

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

Masquerade లేదా స్పష్టమైన SNAT

రెండింటినీ అవి వాగ్దానం చేసే దానితో పోల్చండి. Masquerade నిష్క్రమణ చిరునామాన్ని ఎంచుకుంటుంది, స్పష్టమైన SNAT దాన్ని పిన్ చేస్తుంది. స్థిరమైన పబ్లిక్ చిరునామా ఉన్న గేట్‌వేలో పిన్నింగ్ లాగ్‌లకు మరియు భాగస్వామి అనుమతి జాబితాలకు ఒక అంచనా వేయగల విలువను ఇస్తుంది. చలన WAN లింక్‌లో పిన్ చేసిన SNAT చిరునామా లీజ్ మారిన క్షణంలోనే తప్పు అవుతుంది, Masquerade సరిగ్గా ఆ సందర్భం కోసమే నిర్మించబడింది.

ఎంపిక అంతే పరిధి కూడా ముఖ్యం. గేట్‌వేను విడిచిపెట్టే ప్రతి ప్యాకెట్‌కు సరిపోయే, మూల లేదా గమ్య పరిమితి లేని Masquerade నియమం మీరు అలాగే ఉంచాలనుకున్న ట్రాఫిక్‌ను కూడా అనువదిస్తుంది, ఇతర ప్రైవేట్ నెట్‌వర్క్‌లకు వెళ్లే ట్రాఫిక్‌తో సహా. నియమాన్ని క్లయింట్ పరిధి, ఉద్దేశించిన గమ్యం మరియు ఇంటర్‌ఫేస్‌కు పరిమితం చేయండి.

విధాన ఆధారిత IPsec లో ఇది ఎక్కువగా కరుస్తుంది. strongSwan యొక్క ఫార్వార్డింగ్ మార్గదర్శిని IP ఫార్వార్డింగ్‌ను ఆన్ చేయడం మరియు క్లయింట్లకు మూల-NAT నియమాన్ని జోడించడం దశలవారీగా చూపుతుంది, అదే పత్రం అసలు చిరునామాను నిలబెట్టుకోవాల్సిన ట్రాఫిక్‌ను మినహాయించడాన్ని కూడా కవర్ చేస్తుంది. భద్రతా విధానం సరిపోలే ముందు మూలాన్ని అనువదించండి, సొరంగం పైకి రావచ్చు కానీ ట్రాఫిక్ ఇంకా పడిపోతూనే ఉంటుంది, ఎందుకంటే ప్యాకెట్ ఇకపై చర్చించిన ఎంపికదారులా కనిపించదు.

దూర చివర ఏమి చూడాలో కూడా నిర్ణయించండి. అనువాదం తర్వాత సేవ గేట్‌వేను చూస్తుంది, వ్యక్తిగత క్లయింట్‌ను కాదు. ఇది తిరిగి మార్గనిర్దేశనాన్ని సులభతరం చేస్తుంది మరియు అదే సమయంలో లాగ్‌లను చదును చేసి ప్రతి క్లయింట్ అనుమతి జాబితాలను నిష్ప్రయోజనం చేస్తుంది. క్లయింట్ చిరునామాలను కాపాడుకోవడం ముఖ్యమైతే, పరీక్ష పాస్ కావడానికి వాటిని దాచడం బదులు మార్గనిర్దేశిత తిరిగి మార్గాన్ని ప్రణాళిక చేయండి.

Linux గేట్‌వేలో నియమాలను చదవడం

10.8.0.0/24 లో క్లయింట్లు మరియు eth0 అనే WAN ఇంటర్‌ఫేస్ ఉన్న రిమోట్ యాక్సెస్ గేట్‌వేకు ఫార్వార్డింగ్ ఆన్‌లో మరియు ప్రవాహాన్ని అనుమతించే ఫిల్టర్ విధానం అవసరం, అప్పుడే ఏదైనా NAT నియమం సహాయపడగలదు. iptables వెర్షన్ రెండు దిశలను nat పట్టికలో ఉంచుతుంది:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables రూపం అదే రెండు హుక్‌లను పేరున్న ఇంటర్‌ఫేస్ మరియు స్పష్టమైన గొలుసుతో ఉపయోగిస్తుంది:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

రెండు భాగాలు ఫిల్టర్ గొలుసు ఇప్పటికే ఫార్వార్డ్ చేసిన ప్రవాహాన్ని అంగీకరిస్తుందని ఊహిస్తాయి. NAT అనుమతి నియమం కాదు, సరిగ్గా అనువదించిన ప్యాకెట్ కూడా ఒక పట్టిక తర్వాత విస్మరించబడవచ్చు. conntrack -L తో ప్రత్యక్ష మ్యాపింగ్‌ను నిర్ధారించండి, nft list ruleset లేదా iptables-save -t nat తో ఏమి లోడ్ అయిందో నిర్ధారించండి, ఆ తర్వాత చిరునామా నిజంగా మారుతున్నట్లు చూడటానికి రెండు ఇంటర్‌ఫేస్‌లలో క్యాప్చర్ చేయండి.

చెడు నియమంలా కనిపించే వైఫల్య విధానాలు

హెయిర్‌పిన్ ట్రాఫిక్ క్లాసిక్. సర్వర్ పబ్లిక్ చిరునామా ద్వారా అంతర్గత సర్వర్‌ను చేరే అంతర్గత క్లయింట్‌కు లోపలికి వచ్చే మార్గంలో DNAT మరియు తిరిగి బయటకు వెళ్లే మార్గంలో మూల అనువాదం అవసరం, లేకపోతే సర్వర్ నేరుగా క్లయింట్‌కు ప్రతిస్పందిస్తుంది మరియు ప్రతిస్పందన తిరస్కరించబడుతుంది. పరిష్కారం ఆ అంతర్గత-నుండి-పబ్లిక్ సందర్భం కోసం రెండవ, సన్నని నియమం, అన్నింటికీ విస్తృత Masquerade నియమం కాదు.

రెట్టింపు అనువాదం నిశ్శబ్దమైనది. ఇప్పటికే ఆపరేటర్ స్థాయి NAT వెనుక ఉన్న క్లయింట్ తిరిగి మార్గనిర్దేశించలేని చిరునామాతో మీ గేట్‌వేకు వస్తాడు, కాబట్టి మళ్లీ అనువదిస్తారు. పని చేస్తుంది, కానీ లాగ్‌లు ఇప్పుడు ప్రైవేట్ చిరునామాకరణ యొక్క రెండు దాటులను మోస్తాయి మరియు ఏ దర్యాప్తుకైనా రెండు మ్యాపింగ్‌లు కావాలి. విధాన ఆధారిత IPsec మూడవ మలుపును జోడిస్తుంది: విధానం సరిపోలే ముందు అనువదించండి, ట్రాఫిక్ దాటకుండానే పైకి లేచిన SA లభిస్తుంది, ఇది NAT ది కాదు, ఫైర్‌వాల్ బగ్‌లా చదవబడుతుంది.

ఆ తర్వాత పాస్ అయ్యే పరీక్ష మరియు విఫలమయ్యే అమలు ఉన్నాయి. NAT ఆదేశాన్ని చేతితో నడపడం యాంత్రికతను నిరూపిస్తుంది, కాన్ఫిగరేషన్‌ను కాదు. రన్‌టైమ్‌లో జోడించిన నియమం రీబూట్‌లో లేదా తదుపరి ఇంటర్‌ఫేస్ సంఘటనలో మాయమవుతుంది, సంఖ్య మారే ఇంటర్‌ఫేస్‌కు కట్టివేసిన Masquerade నియమం దూర చివర చూసే చిరునామాను నిశ్శబ్దంగా మార్చగలదు. నియమాన్ని దాని యజమాని ఫైర్‌వాల్ కాన్ఫిగరేషన్‌లో పెట్టి, తిరిగి కనెక్ట్ అయిన తర్వాత మళ్లీ పరీక్షించండి.

నియమాన్ని సేవ్ చేయడానికి ముందు తనిఖీ జాబితా

మొదట దిశను పేరు పెట్టండి: మూలం, గమ్యం లేదా రెండూ. తర్వాత స్థితిని ఎవరు ఉంచుకోవాలో నిర్ణయించండి — గేట్‌వే, పై రౌటర్ లేదా IPsec భాగస్వామి — మరియు ప్రతిస్పందన మార్గం దాని గుండా తిరిగి వస్తుందని నిర్ధారించండి. నియమాన్ని మీరు నిజంగా ఉద్దేశించిన క్లయింట్ పరిధి, గమ్యం మరియు ఇంటర్‌ఫేస్‌కు పరిమితం చేయండి, దూర చివర గేట్‌వేను చూడాలా అసలు క్లయింట్ చిరునామాను చూడాలా ముందుగానే నిర్ణయించండి.

గేట్‌వే నుండి కాదు, క్లయింట్ నుండి పరీక్షించండి. గేట్‌వేలోని బ్రౌజర్ క్లయింట్ అనువాద నియమాన్ని పూర్తిగా దాటవేయగలదు, కాబట్టి అక్కడ పనిచేసే పేజీ సొరంగం గురించి ఏమీ నిరూపించదు. క్లయింట్ నుండి మొదలైన ఒక అభ్యర్థనను పంపండి, కౌంటర్లు మరియు conntrack పట్టికను గమనించండి, మీరు పనిచేసే చోట ఏదైనా సాధ్యమైతే సొరంగం తిరిగి కనెక్ట్ అయిన తర్వాత మరియు WAN చిరునామా మారిన తర్వాత దాన్ని పునరావృతం చేయండి.

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