nginx పగలకముందే OpenVPN SNAT నియమ పరిధిని నిర్ణయించండి

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

కంటైనర్ tun పరికరాన్ని సృష్టించగలదని నిర్ధారించండి

సొరంగ ఇంటర్ఫేస్ ఉనికిలో ఉండలేకపోతే మరేదీ ముఖ్యం కాదు. /dev/net/tun ఉందని మరియు పరీక్షా పరికరం సృష్టించడం విజయవంతమవుతుందని తనిఖీ చేయండి, ఎందుకంటే చాలా మంది ప్రదాతలు కంటైనర్లలో tunను డిఫాల్ట్గా నిలిపివేస్తారు. ఎప్పుడూ సృష్టించబడని పరికరాన్ని ఏ firewall పనీ పూర్తి చేయదు.

పరికరం లేకపోతే హోస్ట్ లేదా ప్రదాత మాత్రమే దాన్ని ప్రారంభించగలరు. ఒక వారం నిడివి ఉన్న తెరిచిన మద్దతు థ్రెడ్ కంటే వేరే ప్రణాళిక తరచుగా చవకగా ఉంటుంది. OpenVPN లాగ్లో ఒక్క లైన్ చదవకముందే దీన్ని నిర్ధారించండి. లేకపోతే ఎప్పుడూ ప్యాకెట్ చూడని నియమాలను సర్దుబాటు చేస్తూ సాయంత్రాన్ని గడుపుతారు.

ఈ ఇంటర్ఫేస్పై MASQUERADE ఏమి చేస్తుందో నిర్ణయించండి

సాధారణ వర్చువల్ మెషీన్లో సాధారణ ఎగ్రెస్ నియమం ప్రధాన ఇంటర్ఫేస్ నుండి POSTROUTING MASQUERADE ఉంటుంది. OpenVZ కంటైనర్లో కనిపించే పరికరం తరచుగా venet0, అంటే హోస్ట్ నిర్వహించే వర్చువల్ ఇంటర్ఫేస్, రూట్ చేసిన NIC కాదు, మరియు MASQUERADE అక్కడ ట్యుటోరియల్లు ఊహించినట్లు ఎప్పుడూ ప్రవర్తించదు.

పనిచేసే రూపం క్లయింట్లు ఇప్పటికే చేరుకునే చిరునామాకు స్పష్టమైన అనువాదం, రెండు దిశల్లో ఫార్వార్డింగ్ అనుమతించబడుతుంది. సర్వర్ కాన్ఫిగరేషన్ నుండి pool మార్చడం చిరునామా మార్చడంతో సమానంగా ముఖ్యం. పేస్ట్ చేయకముందు ప్రతి లైన్ చదవండి.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ఫార్వార్డింగ్ నియమాలు లేకుండా అనువాదం ఇప్పటికీ జరుగుతుంది మరియు కెర్నల్ ఇప్పటికీ ఫార్వార్డ్ చేయడానికి నిరాకరిస్తుంది. ఈ కలయిక NAT నియమంపై కౌంటర్లు పెరుగుతుండగా క్లయింట్కు ఏమీ రాని గందరగోళ స్థితిని సృష్టిస్తుంది. రెండు FORWARD లైన్లు కూడా అదే చైన్లో ఏదైనా విస్తృత drop నియమానికి ముందు ఉండాలి. క్రమం కాన్ఫిగరేషన్లో భాగం, అమలు వివరం కాదు.

నియమాన్ని ఒక pool మరియు ఒక ఇంటర్ఫేస్కు పరిమితం చేయండి

రెండవ లక్షణానికి వేరే కారణం ఉంది: మూలం లేదా అవుట్పుట్ పరిమితి లేని POSTROUTING నియమం. అలాంటి నియమం హోస్ట్ను వదిలే ప్రతి ప్యాకెట్ను తిరిగి వ్రాస్తుంది.

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

పరిష్కారం ఏమిటంటే సరిపోలికను సొరంగ pool మరియు ఎగ్రెస్ ఇంటర్ఫేస్కు సంకుచితం చేసి, అనేకాన్ని కవర్ చేయడానికి ఒక నియమాన్ని విస్తరించే బదులు ప్రతి pool కు ఒక నియమం జోడించడం.

నియమాలను శాశ్వతం చేసి అవి ఇంకా ఎవరి స్వంతమో తెలుసుకోండి

చేతితో జోడించిన నియమాలు రీబూట్లో కనుమరుగవుతాయి, కాబట్టి వాటిని iptables-save తో సేవ్ చేయండి లేదా ఇన్స్టాల్ చేసిన చోట netfilter-persistent ద్వారా నిర్వహించండి. OpenVPN ప్రారంభం కాకముందే పునరుద్ధరణ నడుస్తుందని నిర్ధారించండి. ఆపై సంఘటన సమయంలో ఖాళీని కనుగొనే బదులు ఉద్దేశపూర్వకంగా ఒకసారి రీబూట్ చేయండి.

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

కౌంటర్లు మరియు ఒక క్యాప్చర్ చేసిన ప్రవాహంతో ధృవీకరించండి

కనెక్ట్ అయిన క్లయింట్ నుండి, బాహ్య సేవ నివేదించే పబ్లిక్ చిరునామాను తనిఖీ చేయండి. అది సర్వర్ చిరునామాతో సరిపోలితే అనువాదం పనిచేస్తుంది; సరిపోలకపోతే ప్యాకెట్ మరొక మార్గంలో బయటకు వెళ్తోంది లేదా అసలు వెళ్లడం లేదు. ఆపై సర్వర్లో హోస్ట్ చేసిన సేవ మరియు పబ్లిక్ ఇంటర్నెట్లోని సేవ రెండింటినీ ప్రయత్నించండి, ఎందుకంటే అవి ఒకే నియమ సముదాయం గుండా వేరే మార్గాలను తీసుకుంటాయి.

సర్వర్లో iptables -t nat -L -v -n తో NAT మరియు FORWARD నియమాలపై ప్యాకెట్ కౌంటర్లను చదివి, క్యాప్చర్లో ఒక ప్రవాహాన్ని గమనించండి. క్యాప్చర్లో క్లయింట్ చిరునామా కనిపించి స్పందన రాకపోతే, ఖాళీ తిరిగి వచ్చే మార్గంలో లేదా ప్రదాత ఫిల్టరింగ్లో ఉంది, క్లయింట్ ప్రొఫైల్లో కాదు. క్యాప్చర్ చేసిన మూలాన్ని నియమం అనువదించే చిరునామాతో పోల్చండి, ఎందుకంటే సరిపోలకపోవడం అంటే మరో నియమం ముందుగా సరిపోలింది. గమనించిన ఒక ప్రవాహం ఒక పేజీ కాన్ఫిగరేషన్ చదవడం కంటే ఎక్కువ తీర్మానిస్తుంది.

pool, అనువదించిన చిరునామా మరియు ఇంటర్ఫేస్ పేరును మార్పు రికార్డులో కలిసి ఉంచండి. ఒక pool కు సరైన నియమం తదుపరి దాన్ని తప్పుగా అనువదిస్తుంది.