అన్ని పోర్టులను ఫార్వర్డ్ చేసే నియమాలు మీ WireGuard లిజనర్‌ను మింగేయగలవు
విస్తృత ఫార్వర్డ్ నియమం గేట్‌వే యొక్క స్వంత WireGuard మరియు SSH లిజనర్‌లను మింగేయగలదు. సన్నని నియమాలు లేదా ప్రత్యేక పబ్లిక్ చిరునామాను ఎంచుకోండి, ఆ తర్వాత నియంత్రణ మార్గాన్ని పరీక్షించండి.
ఒక పబ్లిక్ గేట్‌వే ఇప్పటికే UDP 51820లో WireGuard, 22లో SSH మరియు ఇంటర్నెట్ నుండి చేరుకోవాల్సిన ఒక అప్లికేషన్‌ను నడుపుతోంది. ఆకర్షణీయమైన నియమం ప్రతి పోర్టును peerకు ఫార్వర్డ్ చేసి పని పూర్తయిందని ప్రకటిస్తుంది. WireGuard గేట్‌వేలో ఆ నియమం సొరంగం యొక్క స్వంత రవాణాను పట్టుకుని, దాన్ని ముగించే మెషీన్ నుండి మిమ్మల్ని బయట లాక్ చేయగలదు. ప్రచురణ అనేది నియంత్రణ తలానికి మినహాయింపుతో కూడిన రూటింగ్ నిర్ణయం, ఒక DNAT లైన్ కాదు.
పబ్లిక్ ప్రవేశం లేదా సొరంగ ప్రవేశం: ఒకటి ఎంచుకోండి
సేవను ప్రచురించడం ఇంటర్నెట్‌లో కొత్త ప్రవేశ బిందువును సృష్టిస్తుంది. సందర్శకుడు ఎప్పుడూ సొరంగంలోకి ప్రవేశించనందున, గేట్‌వే బ్యాకెండ్ యొక్క పబ్లిక్ ముఖంగా మారడం వల్ల ఇది peerకు VPN సభ్యత్వం ఇవ్వడంతో సమానం కాదు. ఆ భేదమే నియమం యొక్క ప్రేక్షకులను మరియు దాని ధృవపత్రాన్ని నిర్ణయిస్తుంది.
నిర్వాహక ఇంటర్‌ఫేస్‌లు ఆ స్థానానికి అరుదుగా సరిపోతాయి. అధికారం ఉన్న VPN క్లయింట్‌లు చేరుకునే నిర్వాహక పేజీ దాడి ఉపరితలాన్ని సొరంగం లోపల ఉంచుతుంది మరియు లాగిన్ ఫారమ్‌ను ఏకపక్ష స్కానింగ్‌కు బహిర్గతం చేయడాన్ని నివారిస్తుంది. పబ్లిక్ అప్లికేషన్ ఎండ్‌పాయింట్లకు ఇప్పటికీ స్వంత TLS ధృవపత్రం, ప్రామాణీకరణ మరియు రేటు పరిమితి అవసరం; గుప్తీకరించిన WireGuard దాటకం సందర్శకుడి గేట్‌వే వరకు ఉన్న భాగాన్ని రక్షించదు.
సేవ నిజంగా పబ్లిక్‌గా ఉండాల్సి ఉంటే, హోస్ట్ పేరు, దాన్ని కవర్ చేసే ధృవపత్రం మరియు దాన్ని చేరుకోవాల్సిన సందర్శకుల పరిధులను రాసుకోండి. ఆ మూడు వాస్తవాలు తర్వాత నియమం ఆకారాన్ని మరియు ఫిల్టర్ విధానాన్ని నిర్ణయిస్తాయి. వాటికి బయట ఉన్నదంతా పబ్లిక్ లిజనర్‌పై పరిధి విస్తరణ.
ఒక పోర్టు లోపలికి, ఒక backend బయటికి
ఒకే పబ్లిక్ పోర్టు మరియు ఒకే backend సేవను ఉపయోగించండి. ఈ ఉదాహరణలో eth0 పబ్లిక్ చిరునామా 198.51.100.20ను మోస్తుంది, గేట్‌వే సొరంగ చిరునామా 10.200.0.1, peer అప్లికేషన్‌ను 10.200.0.7లో నడుపుతుంది. పబ్లిక్ TCP 9443 peer యొక్క TCP 8443కు మ్యాప్ అవుతుంది:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT నియమం అనువదించిన backend మరియు అసలు పబ్లిక్ గమ్యానికి సరిపోతుంది, కాబట్టి అదే backend సేవకు మరో కనెక్షన్ ఈ మ్యాపింగ్ వెలుపల ఉంటుంది. ఇది సందర్శకుడి చిరునామాను peer నుండి దాచుతుంది, మరియు మూలాన్ని కాపాడే రూటెడ్ తిరిగి వచ్చే మార్గాన్ని ప్రత్యేక రూపకల్పనగా చేసే రాజీ ఇదే. iptables పొడిగింపుల సూచన రెండు లక్ష్యాలను మరియు వాటి సరిపోలిక ఎంపికలను నమోదు చేస్తుంది.
ఫార్వర్డింగ్ ఇప్పటికీ ప్రారంభించబడాలి, మరియు ఫిల్టర్ చైన్‌కు అనువదించిన గమ్యం మరియు పోర్టుతో పాటు స్థాపించిన ప్రతిస్పందనలకు అనుమతి అవసరం. FORWARD చైన్ DNAT తర్వాత అనువదించిన గమ్యాన్ని చూస్తుంది, కాబట్టి పబ్లిక్ చిరునామాపై రాసిన నియమం ఫార్వర్డ్ అయ్యే ప్యాకెట్‌తో సరిపోలదు. అనుమతిని పబ్లిక్‌పై కాదు, backend టపుల్‌పై రాయండి.
peer గేట్‌వే సొరంగ చిరునామా నుండి సేవ కనెక్షన్‌ను అంగీకరించి, ప్రతిస్పందనను సొరంగం ద్వారా తిరిగి పంపాలి. దాని AllowedIPs నిజంగా స్వీకరించే మూలాన్ని అధికారం ఇవ్వాలి, మూల అనువాదం కింద అది గేట్‌వే సొరంగ చిరునామా, మరియు ఈ రూపకల్పనకు ప్రతి peerలో విస్తృత 0.0.0.0/0 నమోదు అవసరం లేదు. తిరిగి వచ్చే ట్రాఫిక్‌ను పడేయడం అనేది ఆ చిరునామాను జాబితా నుండి వదిలే peer, లేదా దానికి బదులుగా సందర్శకుడి స్వంత చిరునామాను పంపే మూలాన్ని కాపాడే రూపకల్పన, కాబట్టి మీ నియమంలో ఉన్నది కాదు, peer నిజంగా చూసే మూలాన్ని తనిఖీ చేయండి.
గేట్‌వే యొక్క స్వంత లిజనర్‌లను నియమం వెలుపల ఉంచండి
పోర్టు సరిపోలికను ప్రతి TCP మరియు UDP గమ్యాన్ని కవర్ చేసే నియమంతో భర్తీ చేయండి, గేట్‌వే యొక్క స్వంత WireGuard సాకెట్ దానిలో పడుతుంది. గమ్య అనువాదం మెషీన్ ప్యాకెట్ స్థానికమని నిర్ణయించడానికి ముందే జరుగుతుంది, కాబట్టి UDP 51820 ప్రతి peer కనెక్షన్‌ను పట్టుకునే ప్రక్రియకు బదులు peerకు చేరుకోవచ్చు. నియమం విజయవంతంగా లోడ్ అవుతుంది మరియు సొరంగం చనిపోతుంది, ఇది peer వైపు నుండి చదవడం కష్టమైన వైఫల్యం.
SSH, పర్యవేక్షణ ఏజెంట్లు మరియు గేట్‌వేలో హోస్ట్ చేసిన ఏదైనా ఇతర సేవ అదే బహిర్గతతను కలిగి ఉంటాయి. అన్నింటినీ ఫార్వర్డ్ చేసే నియమం నియంత్రణ తలాన్ని ప్రచురించిన అప్లికేషన్ నుండి వేరు చేయదు, మరియు మార్పు తర్వాత మొదటి రీబూట్ లాకవుట్ స్పష్టమయ్యే క్షణం. అన్నింటినీ పట్టుకునే నియమం తాను నిశ్శబ్దంగా స్వీకరించిన సేవ గురించి హెచ్చరించదు. తదుపరి కనెక్షన్ విఫలమైనప్పుడు తెలుస్తుంది.
విస్తృత ఫార్వర్డింగ్ నిజంగా అవసరమైతే, అన్నింటినీ పట్టుకునే నియమానికి ముందు నియంత్రణ పోర్టులను కేటాయించండి లేదా ప్రచురణ కోసం ప్రత్యేక పబ్లిక్ చిరునామాను ఉపయోగించండి. రెండవ ఎంపిక శుభ్రమైనది ఎందుకంటే నియంత్రణ చిరునామా దాని స్వంత విధానాన్ని నిలుపుకుంటుంది, కానీ ప్రదాత ఆ చిరునామాను ఇవ్వాలి; DNS రికార్డు జోడించడం చిరునామాను కేటాయించదు.
విస్తృత TCP మరియు UDP ఫార్వర్డింగ్ కూడా అన్ని ప్రోటోకాల్‌లు కావు. ICMP, IPv6, path-MTU ఫీడ్‌బ్యాక్ మరియు బాహ్య VPN రవాణాకు స్వంత విధానం అవసరం, TCP మరియు UDPను కవర్ చేసే నియమం ఆ సందర్భాలను డిఫాల్ట్ చైన్‌కు వదిలివేస్తుంది.
నియమాలు రాసే ముందు నమూనాను ఎంచుకోండి
నాలుగు ఆకారాలు గేట్‌వే నుండి జరిగే చాలా ప్రచురణలను కవర్ చేస్తాయి, ఎంపిక మీరు ఎన్ని సేవలు నడుపుతున్నారు మరియు నియంత్రణ తలంలో ఎంత ప్రమాదాన్ని భరించగలరు అనే దానిపై ఆధారపడి ఉంటుంది. క్రింది పట్టిక వాటిని అతి సన్నని నుండి అతి విస్తృతం వరకు క్రమబద్ధీకరిస్తుంది.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
తర్వాత మరిన్ని సేవలు ఆశించినా సన్నని నమూనాతో ప్రారంభించండి. దాన్ని ఆడిట్ చేయడం చాలా సులభం, మరియు సన్నని నియమాల సమితిని సమీక్షించిన అన్నింటినీ పట్టుకునే నియమంగా మార్చడం, విస్తృత నియమం ఏ లిజనర్‌ను పట్టుకుందో కనుగొనడం కంటే సులభం. ఏ నమూనా ఎంచుకున్నా, నియమాలను ఫైర్‌వాల్ యజమాని వద్ద ఉంచండి. అదే చైన్‌లను నిర్వహించే UFW లేదా nftables కాన్ఫిగరేషన్ పక్కన iptables వరుసలను వర్తింపజేయడం బూట్ క్రమాన్ని బట్టి మారే విధానాన్ని ఉత్పత్తి చేస్తుంది.
ప్రచురణ మరియు నియంత్రణ మార్గం రెండింటినీ నిరూపించండి
అధికారం ఉన్న బాహ్య క్లయింట్ నుండి ఆమోదించిన హోస్ట్ పేరు మరియు దానికి చెల్లుబాటు అయ్యే ధృవపత్రంతో పరీక్షించండి. ఏ backend ప్రతిస్పందించిందో నిర్ధారించి, ఆ తర్వాత సంబంధం లేని పబ్లిక్ పోర్టులు తిరస్కరించబడుతూనే ఉన్నాయని తనిఖీ చేయండి. నిలిపివేసిన ధృవపత్ర తనిఖీ ఉత్తీర్ణత పొందిన HTTPS పరీక్ష కాదు, మరియు తప్పు backendను చేరుకునే కనెక్షన్ విఫలమైన దానికంటే అధ్వాన్నం.
ఆ తర్వాత గేట్‌వేను స్వయంగా ధృవీకరించండి: ఒక WireGuard peerను కనెక్ట్ చేయండి, ఒక SSH సెషన్ తెరవండి మరియు పర్యవేక్షణ ఇంకా నివేదిస్తోందని నిర్ధారించండి. నియంత్రణ తలం పాడైనప్పుడు కూడా ప్రచురిత సేవ పనిచేయగలదు, కాబట్టి రెండు తనిఖీలు ఒకే మార్పు విండోలో ఉంటాయి. నియమాలు ఆశించిన క్రమంలో మళ్లీ వర్తింపజేయబడతాయని నిరూపించడానికి ఒకసారి రీబూట్ చేయండి, ఆ తర్వాత ప్రచురణను తీసివేసి, తీసివేత నిజంగా జోడింపుకు సరిపోతుందని నిర్ధారించండి. బూట్ సమయంలో పెద్ద సంఖ్యలో జోడింపులు మరియు అసంపూర్ణ శుభ్రత — తాత్కాలిక పరీక్ష శాశ్వత రంధ్రంగా మారే మార్గం ఇదే.