ఒక బ్రౌజర్ https://203.0.113.10:8443 ను అభ్యర్థిస్తుంది, ప్రాక్సీ కనెక్షన్ను అంగీకరిస్తుంది, WireGuard peer లోని సేవ ఎప్పటికీ ప్రతిస్పందించదు. DNAT నియమం తన పని చేస్తోంది; విఫలమయ్యే భాగం ప్రతిస్పందన. ప్యాకెట్ను రెండు అనువాదాల ద్వారా అనుసరించండి, మిస్సయిన నియమం స్పష్టమవుతుంది. పరిష్కారం సరైన hook లో మరో NAT ప్రకటన, కొత్త టన్నెల్ కాదు.

ఒక అభ్యర్థనను మొదటి నుండి చివరి వరకు అనుసరించండి

అభ్యర్థన ప్రాక్సీ యొక్క పబ్లిక్ ఇంటర్ఫేస్కు చేరుతుంది, మూలం క్లయింట్ పబ్లిక్ చిరునామా మరియు గమ్యం ప్రాక్సీ చిరునామా. nat PREROUTING లో DNAT నియమం గమ్యాన్ని peer యొక్క టన్నెల్ చిరునామా 10.90.0.2 కు తిరిగి రాస్తుంది. తర్వాత రూటింగ్ నిర్ణయం ప్యాకెట్ను wg0 ద్వారా బయటకు పంపుతుంది, ఫార్వర్డ్ మార్గం పూర్తవుతుంది.

peer లో ప్యాకెట్ ఇప్పుడు అసలు పబ్లిక్ మూల చిరునామాను మోస్తుంది, ఎందుకంటే ఏదీ దాన్ని తిరిగి రాయలేదు. సేవ కనెక్షన్ను అంగీకరించి తన ప్రతిస్పందనను తన డిఫాల్ట్ గేట్వేకు పంపుతుంది, అది peer ముందు ఉన్న ఇంటి రౌటర్. ఆ రౌటర్ కు ఎప్పుడూ చూడని ప్రవాహానికి స్థితి లేదు, కాబట్టి అది ప్యాకెట్ను విసిరేస్తుంది లేదా తన పబ్లిక్ చిరునామాకు అనువదిస్తుంది, క్లయింట్ దాన్ని అంగీకరించదు.

అసమానత్వమే మొత్తం సమస్య: అభ్యర్థన ప్రాక్సీ గుండా వెళుతుంది, ప్రతిస్పందన నేరుగా వెళ్లడానికి ప్రయత్నిస్తుంది. ప్రాక్సీ కనెక్షన్ ట్రాకింగ్ ప్రతిస్పందన ప్రాక్సీ ద్వారా తిరిగి వచ్చినప్పుడే సహాయపడుతుంది, మూల చిరునామా ఇంకా అసలు క్లయింట్ వైపు చూపుతున్నంత వరకు అది అక్కడికి తిరిగి రాలేదు.

తిరిగి వచ్చే అనువాదాన్ని జోడించండి

ఫార్వర్డ్ అయ్యే ప్రవాహం యొక్క మూలాన్ని peer వైపు వెళ్లే ముందు ప్రాక్సీ టన్నెల్ చిరునామాకు తిరిగి రాయండి. తర్వాత సేవ 10.90.0.1 కు ప్రతిస్పందిస్తుంది, ప్రాక్సీ దాన్ని స్వీకరిస్తుంది, ప్యాకెట్ క్లయింట్ వద్దకు తిరిగి వెళ్లే ముందు కనెక్షన్ ట్రాకింగ్ రెండు అనువాదాలను తిప్పుతుంది.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING నియమం ఉద్దేశపూర్వకంగా సన్ననిది: ఇది అనువదించిన గమ్యం మరియు టన్నెల్ ఇంటర్ఫేస్తో సరిపోతుంది, కాబట్టి wg0 ద్వారా యాదృచ్ఛికంగా బయటకు వెళ్లే అసంబంధిత ట్రాఫిక్ను తిరిగి రాయదు. విస్తృత masquerade నియమం క్లయింట్ చిరునామాను కూడా దాచుతుంది, కానీ అది ప్రతి ప్రవాహానికి అలా చేస్తుంది మరియు NAT పట్టికను ఆడిట్ చేయడం కష్టతరం చేస్తుంది.

టన్నెల్ ఉన్న చోట నియమాలను ఉంచండి

టన్నెల్ చిరునామా లేదా ఇంటర్ఫేస్ను సూచించే నియమాలు wg-quick దాన్ని కాన్ఫిగర్ చేసిన తర్వాత అమలు కావాలి. ఇంటర్ఫేస్ PreUp కు ముందు సృష్టించబడుతుంది, కానీ చిరునామాలు, MTU, DNS మరియు మార్గాలు తర్వాత వర్తింపజేయబడతాయి, అవన్నీ స్థానంలో ఉన్నప్పుడు PostUp అమలవుతుంది. జోడింపులను PostUp లో, తొలగింపులను PreDown లో ఉంచండి.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

తొలగింపులు జోడింపులతో టోకెన్ వారీగా సరిపోవాలి, multiport మరియు ఇంటర్ఫేస్ సరిపోలికలతో సహా. ఒక సరిపోలికలో భిన్నంగా ఉన్న తొలగింపు ఏమీ తొలగించదు, తదుపరి పునఃకనెక్షన్ నియమం యొక్క రెండవ ప్రతిని జోడిస్తుంది. కొన్ని పునఃకనెక్షన్ల తర్వాత పట్టికలో కాన్ఫిగరేషన్ లైన్కు ఆపాదించడం కష్టమైన నకళ్లు ఉంటాయి.

ఫలితాన్ని iptables -t nat -S తో పునఃకనెక్షన్ తర్వాత తనిఖీ చేయండి. అదే నియమం రెండుసార్లు కనిపిస్తే PreDown లైన్ సరిపోవడం లేదు మరియు శుభ్రపరచడం నిశ్శబ్దంగా విఫలమవుతుంది.

ఫార్వర్డింగ్, ఫిల్టరింగ్ మరియు మరో NAT

IPv4 ఫార్వర్డింగ్ను శాశ్వతంగా ప్రారంభించి, తర్వాత ఫిల్టర్ పట్టికలో ఫార్వర్డ్ అయ్యే ప్రవాహాన్ని అనుమతించండి. DNAT FORWARD చైన్కు ముందు జరుగుతుంది, కాబట్టి ఫిల్టర్ నియమం పబ్లిక్ చిరునామాతో కాకుండా అనువదించిన గమ్యంతో సరిపోతుంది. UFW ఫైర్వాల్ను నిర్వహిస్తే, అనుమతిని మార్గ నియమంగా వ్యక్తపరచండి; సాధారణ host నియమం ఫార్వర్డ్ అయ్యే ట్రాఫిక్ను కవర్ చేయదు.

ప్రాక్సీ నియమాలు సరైనప్పటికీ మరో రెండు NAT పొరలు మార్గాన్ని విచ్ఛిన్నం చేయగలవు. ఇంటి కనెక్షన్లో పబ్లిక్ చిరునామా రౌటర్ది, దాని ఫైర్వాల్లో పోర్టును తెరవడం ఆ పోర్టును ప్రాక్సీకి పంపే పోర్ట్-ఫార్వర్డ్ నమోదును సృష్టించడంతో సమానం కాదు. బయట నుండి తెరిచినట్లు కనిపిస్తున్నా ఏదీ ప్రతిస్పందించని పోర్టుకు సాధారణంగా అదే మ్యాపింగ్ ఉండదు.

NAT VPS లో ప్రదాత పబ్లిక్ పోర్టును ప్రైవేట్ చిరునామాకు మ్యాప్ చేస్తారు. మ్యాపింగ్ మీరు ప్రకటించే పోర్టుతో సరిపోవాలి, అసమానత విరిగిన టన్నెల్ లాగానే కనిపిస్తుంది. WireGuard కాన్ఫిగరేషన్ మార్చే ముందు ప్రదాత మ్యాపింగ్ను నిర్ధారించండి.

తిరిగి వచ్చే మార్గాన్ని ధృవీకరించి ఖర్చును అంగీకరించండి

ప్రాక్సీ LAN కాని నెట్వర్క్ నుండి కనెక్ట్ అవ్వండి, తర్వాత కనెక్షన్ తెరిచి ఉన్నప్పుడు అనువాద జంటను పరిశీలించండి:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack నమోదు అసలు tuple, అనువదించిన tuple మరియు ప్రతిస్పందన దిశను చూపాలి. ప్రతిస్పందన లేకపోతే peer టన్నెల్ ద్వారా పంపడం లేదు, దాని అర్థం సాధారణంగా SNAT నియమం వర్తించలేదు లేదా peer యొక్క స్వంత ఫైర్వాల్ ప్రవాహాన్ని విసిరింది.

PostUp నియమాలను తిరిగి వర్తింపజేస్తుందని నిరూపించడానికి ఒకసారి రీబూట్ చేయండి, తర్వాత టన్నెల్ ఆపి PreDown వాటిని తొలగించినట్లు నిర్ధారించండి. డిస్కనెక్ట్ తర్వాత మిగిలిన మృత నియమాలే తర్వాతి మార్పు ఊహించని విధంగా ప్రవర్తించడానికి కారణం.

చివరగా, SNAT యొక్క ఖర్చును అంగీకరించండి. సేవ ప్రతి అభ్యర్థనను ప్రాక్సీ నుండి వచ్చినట్లే చూస్తుంది, కాబట్టి యాక్సెస్ లాగ్లు, ప్రతి క్లయింట్ రేటు పరిమితులు మరియు అనుమతించిన చిరునామా జాబితాలు ఇకపై వినియోగదారులను వేరు చేయవు. hairpin కేసుకు ప్రాక్సీ LAN లోని క్లయింట్ల కోసం దాని సొంత మూల అనువాదం అవసరం. peer కు నిజమైన క్లయింట్ చిరునామాలు కావాలంటే, ప్రత్యామ్నాయం క్లయింట్ నెట్వర్క్కు తిరిగి వెళ్లే మార్గం, అది ఎక్కువ పని కానీ సమాచారాన్ని నిలుపుతుంది.

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