CGNAT వెనుక నుండి VPN క్లయింట్ పోర్ట్ను ప్రచురించండి: చెక్లిస్ట్

ఒక సేవను క్యారియర్-గ్రేడ్ NAT వెనుక ఉన్న ల్యాప్టాప్పై ఉంచండి, ఆ ల్యాప్టాప్ను VPN ద్వారా VPS వైపు మళ్లించండి, బయటి నుండి ఎవరూ దానిని చేరుకోలేరు. మీరు VPSలో గమ్యస్థాన NAT నియమాన్ని జోడిస్తారు మరియు నిశ్శబ్దం కంటే చెడ్డది పొందుతారు: కనెక్షన్లు తెరుచుకుని ఆపై నిలిచిపోతాయి. ప్రతిస్పందన పోలేదు, అది క్లయింట్ స్వంత డిఫాల్ట్ మార్గం ద్వారా బయటకు వెళ్తోంది, అంటే సర్వర్ దానిని ఎప్పటికీ చూడదు. ఈ ఐదు తనిఖీలను క్రమంగా చేయండి మరియు నిలబడని మొదటి దగ్గర ఆగండి.

సర్వర్ అసలు ఫార్వార్డ్ చేస్తుందో లేదో నిర్ధారించుకోండి

ఒక్క అనువాదం రాయకముందే ఈ పెట్టెను టిక్ చేయండి. కర్నెల్ ఫార్వార్డ్ చేయడానికి నిరాకరించే ప్యాకెట్ కోసం DNAT నియమాన్ని నియమ పార్సర్ అంగీకరిస్తుంది, ఆపై ఫార్వార్డ్ మార్గం దానిని విసిరేస్తుంది, ఇది ఫైర్వాల్ సమస్యలా కనిపించే టైమ్అవుట్ను సృష్టిస్తుంది.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

నడుస్తున్న కర్నెల్లో దీన్ని సెట్ చేయడం రీబూట్ అంతటా సెట్ చేయడం వంటిది కాదు. net.ipv4.ip_forward=1 ను /etc/sysctl.d/ కింద ఉన్న ఫైల్లో రాయండి, sysctl --system ను అమలు చేయండి, ఆపై ఫైల్ తీసుకోబడిందని నమ్మడం బదులు విలువను తిరిగి చదవండి. తన స్వంత నెట్వర్క్ నామస్థలాన్ని నిర్వహించే కంటైనర్కు ఆ స్థలం లోపల అదే విలువ అవసరం, హోస్ట్పై మాత్రమే కాదు.

తిరిగి చదివినా ఇంకా సున్నా అయితే, ఇక్కడ ఆగండి. కింద ఏదీ పని చేయదు.

ఏ నియమం దానిని సూచించకముందే టన్నెల్ చిరునామాను స్థిరపరచండి

పూల్ చిరునామాలను కనెక్షన్ క్రమంలో పంపిణీ చేస్తుంది, కాబట్టి నేటి లీజ్ కోసం రాసిన నియమం వచ్చే వారం నిశ్శబ్దంగా మరో క్లయింట్ను సూచించవచ్చు. చిరునామాను రాక క్రమానికి కాదు, సర్టిఫికెట్ గుర్తింపుకు కట్టండి.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

తిరిగి కనెక్ట్ అయిన తర్వాత చిరునామా మారితే, ఆగండి. కదిలే లక్ష్యాన్ని అనుసరించే NAT నియమం అడపాదడపా విఫలమవుతుంది మరియు మీకు ఏమీ నేర్పదు.

రెండు దిశల్లో అనువదించండి

గమ్యస్థాన అనువాదం వచ్చే ప్యాకెట్ను క్లయింట్కు పంపుతుంది. మూల అనువాదమే క్లయింట్ను అసలు పంపినవారికి కాకుండా సర్వర్కు ప్రతిస్పందించేలా చేస్తుంది, అదే ప్రజలు వదిలేసే నియమం.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

iptables -t nat -S తో రెండు నియమాలను తిరిగి చదివి, ఇంటర్ఫేస్ పేరు పబ్లిక్ చిరునామాను మోసుకెళ్లేదేనా అని నిర్ధారించుకోండి. ఇప్పటికే nftablesతో ఫిల్టర్ చేసే హోస్ట్పై, సాధనాలను కలపడం బదులు సరిపోయే చిరునామా కుటుంబానికి చెందిన nftables NAT గొలుసులో అనువాదాన్ని రాయండి.

ఫిల్టర్ పట్టికను దాటనివ్వండి

NAT పట్టికలు శీర్షికలను తిరిగి రాస్తాయి; అవి అనుమతి ఇవ్వవు. డిఫాల్ట్ DROP విధానంతో ఫార్వార్డ్ అయ్యే ప్రవాహానికి దాని స్వంత అనుమతి కావాలి, అదనంగా తిరిగి వచ్చే దిశను చాలా విధానాలు ఇప్పటికే established,related నియమంతో కవర్ చేస్తాయి.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ఏదైనా జోడించే ముందు FORWARD గొలుసు విధానాన్ని తనిఖీ చేయండి, ఎందుకంటే ముందుగా వచ్చే DROP క్రమం మీ నియమం అసలు పరిగణించబడుతుందో లేదో నిర్ణయిస్తుంది. ఫిల్టరింగ్ nftablesలో నివసించే హోస్ట్పై, సమానమైన నియమాన్ని inet పట్టిక forward హుక్కు జోడించి, మూల గొలుసు స్థానిక ఇన్పుట్ మాత్రమే కాకుండా నిజంగా ఫార్వార్డ్ అయ్యే ట్రాఫిక్ను చూస్తుందని నిర్ధారించుకోండి. కొత్త నియమంపై ప్యాకెట్ కౌంటర్ సున్నాలో ఉండి NAT కౌంటర్లు పెరిగితే, ప్యాకెట్ మీ నియమానికి ముందే విసిరివేయబడుతోంది. అది గొలుసుల క్రమాన్ని చదవడానికి సంకేతం, అదే నియమం రెండవ ప్రతిని జోడించడానికి కాదు.

బయటి నెట్వర్క్ నుండి దాన్ని నిరూపించండి

సంబంధం లేని నెట్వర్క్ నుండి పరీక్షించండి. అదే LANలోని మరో మెషీన్ నుండి చేసే పరిశీలన hairpin NAT మద్దతు గుండా వెళ్లవచ్చు మరియు దూర క్లయింట్ ఉపయోగించే మార్గాన్ని ఎప్పటికీ ప్రయోగించదు, కాబట్టి అక్కడి ఆకుపచ్చ ఫలితం తప్పుడు విషయాన్ని నిరూపిస్తుంది.

tcpdump -ni any port 29443
conntrack -L | grep 29443

సర్వర్లో మరియు క్లయింట్లో ఒకే సమయంలో క్యాప్చర్ను అమలు చేయండి. సర్వర్ క్యాప్చర్ అనువదించిన ప్యాకెట్ టన్నెల్ వైపు వెళ్తుందో లేదో చూపుతుంది; క్లయింట్ క్యాప్చర్ అభ్యర్థన వస్తుందో మరియు ప్రతిస్పందన ఎక్కడ చిరునామా చేయబడిందో చూపుతుంది. conntrack -L లోని అనువాద నమోదు నియమం సరిపోలిందని నిరూపిస్తుంది, దాని లేకపోవడం ప్యాకెట్ ఎప్పటికీ NAT గొలుసుకు చేరలేదని నిరూపిస్తుంది.

పోర్ట్ స్కానర్లు బలహీనమైన సాక్ష్యం. అప్లికేషన్ బైండ్ అయ్యి వినిపించే వరకు అవి పోర్ట్ను మూసివేసినట్లు నివేదిస్తాయి, కాబట్టి నిజమైన సేవకు నిజమైన కనెక్షన్ ఉపయోగించండి. చివరకు పని చేసినప్పుడు, బహిర్గతత్వాన్ని ఆ ఒక్క పోర్ట్కే పరిమితం చేయండి: మొదటి నియమం అసౌకర్యంగా అనిపించిందని SSH లేదా అడ్మిన్ ప్యానెల్ను ఫార్వార్డ్ చేయడం సేవను ప్రచురించడం కంటే చాలా పెద్ద నిర్ణయం.