PiVPN హ్యాండ్షేక్ పనిచేస్తుంది, పేజీలు నిలిచిపోతాయి: MASQUERADE తనిఖీ చేయండి

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

క్లయింట్ ఏమి చేరుకోగలదు, ఏమి చేరుకోలేదు అనే దానితో ప్రారంభించండి

కనెక్ట్ అయిన క్లయింట్ నుండి, పబ్లిక్ ఇంటర్నెట్లో ఉన్న పేజీని లోడ్ చేసి అది వెంటనే విఫలమవుతుందా లేదా మధ్యలో ఆగిపోతుందా అని గమనించండి. తర్వాత VPN సర్వర్ సొంత ప్రైవేట్ చిరునామాలో ఒక వనరును తెరిచి రెండు ఫలితాలను పోల్చండి.

పబ్లిక్ సైట్లు సమయం మించిపోతుండగా ping కి సమాధానం ఇచ్చే టన్నెల్ చిరునామా ఫార్వార్డింగ్ లేదా అనువాద సమస్య సంకేతం, విరిగిన హ్యాండ్షేక్ కాదు. క్లయింట్ సొంత స్థితి ప్యానెల్ వాటిని వేరు చేయలేదు, ఎందుకంటే నియంత్రణ ఛానెల్ పైన ఉందని మాత్రమే అది తెలుసుకుంటుంది. సర్వర్లో టన్నెల్ ఇంటర్ఫేస్ను దీనితో తనిఖీ చేయండి: ip -br addr show tun0 మరియు క్లయింట్కు ఇచ్చిన చిరునామా మీరు కాన్ఫిగర్ చేసిన పూల్ లోపల ఉందని నిర్ధారించండి. పూల్ మరియు క్లయింట్ చిరునామా సరిపోలకపోతే, మొదట దాన్ని సరిచేయండి, ఎందుకంటే క్రింది ప్రతి నియమం పూల్తో సరిపోలుతుంది.

తర్వాత, పబ్లిక్ చిరునామాను చేరుకోవడానికి సర్వర్ ఏ ఇంటర్ఫేస్ ఉపయోగిస్తుందో అడగండి. ip route get 203.0.113.9 తన మొదటి వరుసలో ఎంచుకున్న పరికరాన్ని మరియు మూలాన్ని ముద్రిస్తుంది. ఆ పరికరం పేరును రాయండి, ఎందుకంటే NAT నియమంలో ఉండాల్సిన విలువ అదే.

ప్యాకెట్లు బయటకు వెళ్తాయా లేదా అని నిర్ణయించే నియమాన్ని చదవండి

MASQUERADE ఒక ప్యాకెట్ను తిరిగి రాసేది ఆ ప్యాకెట్ నియమంలో పేర్కొన్న ఇంటర్ఫేస్ ద్వారా బయటకు వెళ్లినప్పుడు మాత్రమే. వైర్ ఉన్న పరికరానికి పరిమితమైన నియమం Wi-Fi ద్వారా బయటకు వెళ్లే ట్రాఫిక్కు ఏమీ చేయదు, మరియు ప్యాకెట్ తన ప్రైవేట్ మూల చిరునామాను పై రౌటర్ వరకు ఉంచుతుంది. ఆ రౌటర్కు మీ టన్నెల్ పూల్ వైపు తిరిగి వెళ్లే మార్గం లేదు, కాబట్టి అది సమాధానాన్ని విసిరేస్తుంది, మరియు క్లయింట్ తెరుచుకుని తర్వాత చనిపోయే కనెక్షన్ను చూస్తుంది. మొదటి సమాధానం అవసరమయ్యే ముందు పేజీ ఎంత భాగం వస్తుందనే దానితో లక్షణం పెరుగుతుంది.

లైవ్ పట్టికను జాబితా చేయండి మరియు MASQUERADE అనే పదాన్ని మాత్రమే వెతకడం బదులు అవుట్-ఇంటర్ఫేస్ నిలువు వరుసను చదవండి. ఫార్మాట్ చేసిన జాబితా కంటే జోడించే రూపం యొక్క అవుట్పుట్ పోల్చడం సులభం:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

ఒకప్పుడు Ethernet మరియు ఇప్పుడు Wi-Fi ఉపయోగించే Raspberry Pi లో, పాత పేరే దాదాపు ఎప్పుడూ మొత్తం కథ. ఇన్స్టాలర్ సెటప్ సమయంలో ఏ పరికరం ఉందో నమోదు చేసింది, మరియు సేవ్ చేసిన నియమ సముదాయం ప్రతి బూట్లో దాన్ని మళ్లీ నడుపుతుంది. మరేదైనా మార్చే ముందు రూట్ శోధన నుండి వచ్చిన పరికరాన్ని నియమంలోని పరికరంతో పోల్చండి. అవి సరిపోలితే, ఇంటర్ఫేస్ మీ సమస్య కాదు, మీరు చివరి భాగంలోని కౌంటర్లకు వెళ్లాలి. అవి భిన్నమైతే, సరిదిద్దడం అంటే స్థిరత్వ ఫైల్లో ఒక పదాన్ని సవరించడం.

సేవ్ చేసిన నియమ సముదాయాన్ని సరిచేయండి, నడుస్తున్నది మాత్రమే కాదు

లైవ్ పట్టికను మాత్రమే సవరించడం తదుపరి రీబూట్ వరకు నిలుస్తుంది, అది సమస్య పరిష్కారమైందని మీకు నమ్మకం కలిగించడానికి సరిగ్గా సరిపోతుంది. బూట్లో తిరిగి వచ్చే నియమాలు firewall స్థిరత్వ ప్యాకేజీ మళ్లీ లోడ్ చేసే ఫైల్లో నివసిస్తాయి. Debian ఆధారిత Pi ఇమేజ్లలో ఆ ఫైల్ సాధారణంగా /etc/iptables/rules.v4.

దాన్ని తాకే ముందు కాపీ తీసుకోండి, తర్వాత MASQUERADE వరుసలోని అవుట్-ఇంటర్ఫేస్ను మీరు నమోదు చేసిన పరికరంతో భర్తీ చేయండి, ఉదాహరణకు -o wlan0 బదులు -o eth0. మీ క్లయింట్ పూల్ మారకపోతే మూల పరిధిని అలాగే ఉంచండి. మళ్లీ లోడ్ చేసి, నియమం ఇప్పుడు సరైన పరికరాన్ని పేర్కొంటున్నదని నిర్ధారించండి:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

పక్కపక్కన ఉన్న రెండు సెట్టింగ్లను మరచిపోవడం సులభం. sysctl net.ipv4.ip_forward 1 గా నివేదించాలి, మరియు పై రౌటర్ ప్రైవేట్ మూల చిరునామాలను తానే ఫిల్టర్ చేయకూడదు.

నియమం పనిచేస్తుందని నిరూపించండి, తర్వాత ఇంకా ఏది నెమ్మదిగా ఉందో వేరు చేయండి

ఒక నియమం సరిపోలిందనడానికి కౌంటర్లే ఏకైక నిజాయితీ రుజువు. వివరణాత్మక జాబితాను అమలు చేయండి, క్లయింట్లో డౌన్లోడ్ ప్రారంభించి మళ్లీ అమలు చేయండి. మీ నియమం పక్కన ఉన్న ప్యాకెట్ మరియు బైట్ నిలువు వరుసలు పెరగాలి, సున్నా వద్ద ఉండే నియమం ఇంకా సరిపోలదు. కౌంటర్లు కదులుతున్నా పేజీలు ఇంకా విఫలమైతే, మూల పరిధిని అసలు పూల్తో దీనితో పోల్చండి grep -n "^server " /etc/openvpn/server.conf. అవి కదిలి పేజీలు లోడ్ అయినా పనితీరు బలహీనంగా ఉంటే, అనువాదం పూర్తయింది మరియు మిగిలిన సమస్య మరెక్కడో ఉంది.

అదే క్లయింట్ నుండి రెండు బదిలీలను పోల్చండి, ఒకటి స్థానిక నెట్వర్క్లోని హోస్ట్కు మరియు మరొకటి టన్నెల్ ద్వారా అదే హోస్ట్కు. రెండింటిలో నెమ్మదిగా ఉండటం VPN కాదు, Pi పై లింక్ లేదా Wi-Fi కనెక్షన్ను సూచిస్తుంది. టన్నెల్ ద్వారా మాత్రమే నెమ్మదిగా ఉండటం MTU మరియు పునఃప్రసారాలను సూచిస్తుంది, వాటిని దీనితో పరిశీలించవచ్చు ip -s link show tun0 ఏదైనా క్రిప్టో సెట్టింగ్ మార్చే ముందు.

ప్రయోగాన్ని రద్దు చేయడానికి కాపీని పునరుద్ధరించి మళ్లీ లోడ్ చేయండి, తర్వాత అసలు నియమం మరియు దాని కౌంటర్లు తిరిగి వచ్చాయని నిర్ధారించండి. తదుపరి పై లింక్ మార్పు అదే అసమానతను మళ్లీ కనుగొంటుంది కాబట్టి, ఎగ్రెస్ పరికరాన్ని మరియు మళ్లీ లోడ్ చేసే ఆదేశాన్ని సర్వర్ నోట్స్లో రాయండి. తప్పు పరికరాన్ని పేర్కొనే నియమం ట్రాఫిక్కు అది అవసరమయ్యే వరకు కనిపించదు.