OpenVPN తో కనెక్ట్ అయింది కానీ ఏదీ లోడ్ కావట్లేదు: క్లయింట్ నుండి బయటకు ఒక ప్రయాణం

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

క్లయింట్ నుండి ప్రారంభించి బయటకు వెళ్లండి

ఈ క్రమంలో మూడు పరీక్షలు చేసి మొదటిది ఎక్కడ విఫలమవుతుందో రాయండి. సర్వర్ టన్నెల్ చిరునామాకు ping చేయండి, అది టన్నెల్ స్వయంగా ట్రాఫిక్ మోస్తోందని నిరూపిస్తుంది. సంఖ్యతో పబ్లిక్ చిరునామాకు ping చేయండి, అది పేరు పరిష్కారం లేకుండా ఫార్వార్డింగ్ మరియు అనువాదాన్ని నిరూపిస్తుంది. తర్వాత హోస్ట్ పేరును పరిష్కరించడానికి ప్రయత్నించండి, అది DNS ఉపయోగించే ఏకైక పరీక్ష. ప్రతి ఫలితం సందేహం నుండి పూర్తి పొరను తీసివేస్తుంది.

బ్రౌజర్ వేగంగా అనిపిస్తోందని మూడవ పరీక్షకు దూకకండి. విఫలమైన పేజీ లోడ్ మూడు పొరలను ఒకేసారి కవర్ చేస్తుంది, అక్కడి నుండే ప్రారంభించి ప్రజలు తర్వాత పనిచేసిన టన్నెల్‌ను మళ్లీ నిర్మిస్తారు. విఫలమయ్యే పేజీ మూడింటిలో ఏది విరిగిందో చెప్పదు.

రెండు క్యాప్చర్లు ప్యాకెట్లు ఎక్కడ ఆగుతాయో చూపిస్తాయి

క్లయింట్ నుండి పబ్లిక్ చిరునామాకు ping నడుస్తున్నప్పుడు టన్నెల్ ఇంటర్‌ఫేస్‌పై ఒక క్యాప్చర్ మరియు ఇంటర్నెట్‌ను చేరుకోవలసిన ఎగువ లింక్‌పై మరొకటి తీసుకోండి. సమయ ముద్రలు సరిపోయేలా రెండింటినీ ఒకేసారి నడపండి.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

అభ్యర్థనలు టన్నెల్‌పై కనిపించి ఎగువ లింక్‌పై ఎప్పుడూ కనిపించకపోతే, సర్వర్ వాటిని టన్నెల్ మరియు వైరు మధ్య పడేసింది, కారణం ఫార్వార్డింగ్ లేదా ఫార్వార్డ్ ఫైర్‌వాల్ విధానం, NAT కాదు. రెండింటిలోనూ కనిపిస్తే, సర్వర్ తన భాగం చేసింది మరియు సమాధానం మరింత బయట కోల్పోయింది, ఇది అనువాదం, ఎగువ ఫిల్టర్ లేదా ప్రొవైడర్ వైపు పరిమితిని సూచిస్తుంది.

ఎగువ లింక్ పేరును ట్యుటోరియల్ నుండి కాకుండా రూటింగ్ పట్టిక నుండి తీసుకోండి. క్లౌడ్ ఇమేజీలు మరియు పేరు మార్చిన అడాప్టర్లు గైడ్‌లోని ఉదాహరణ ఇంటర్‌ఫేస్‌తో అరుదుగా సరిపోతాయి, తప్పు పరికరంలో తీసుకున్న క్యాప్చర్ ఫార్వార్డ్ చేయని సర్వర్‌లాగానే కనిపిస్తుంది:

ip -4 route get 9.9.9.9

ఆ అవుట్‌పుట్‌లోని dev ఫీల్డ్ NAT నియమానికి తర్వాత అవసరమయ్యే పేరు, కాబట్టి దాన్ని ఉంచండి.

ఫార్వార్డింగ్ అనేది కర్నెల్ స్విచ్ మరియు ఫైర్‌వాల్ విధానం

కర్నెల్ మొదట ఫార్వార్డ్ చేయడానికి అంగీకరించాలి. ప్రస్తుత విలువను చదివి, నడుస్తున్న కర్నెల్‌లో మాత్రమే రాయడం బదులు సెట్టింగ్‌ను శాశ్వతం చేయండి:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

ఫార్వార్డింగ్ సగం మాత్రమే. UFW ఉన్న హోస్ట్‌లో ఫార్వార్డ్ విధానం /etc/default/ufw లో సెట్ చేయబడుతుంది మరియు రీలోడ్ అమల్లోకి రాకముందు అది ACCEPT అయి ఉండాలి. ఫార్వార్డ్ మార్గంలో డిఫాల్ట్ డ్రాప్ హ్యాండ్‌షేక్‌ను పూర్తిగా ఆరోగ్యంగా ఉంచుతూ టన్నెల్ నుండి బయటకు వెళ్లడానికి ప్రయత్నించే ప్రతి ప్యాకెట్‌ను నిశ్శబ్దంగా పడేస్తుంది, అదే మీరు ప్రారంభించిన లక్షణం.

nftables ను నేరుగా నిర్వహించే హోస్ట్‌లకు అదే ప్రశ్న మరో సింటాక్స్‌లో వస్తుంది. క్లయింట్ పరీక్ష నడుస్తున్నప్పుడు ఫార్వార్డ్ చైన్‌లోని కౌంటర్లను చూడండి, ఎందుకంటే అడిగే చైన్ మరియు పడేసే చైన్ కాన్ఫిగరేషన్ ఫైల్‌లో ఒకేలా కనిపిస్తాయి.

NAT నియమంలో నిజమైన ఎగ్రెస్ ఇంటర్‌ఫేస్‌ను పేర్కొనండి

మూల అనువాదం హోస్ట్‌ను నిజంగా విడిచిపెట్టే ఇంటర్‌ఫేస్‌కు చెందుతుంది, సర్వర్ పంచే పూల్‌తో పాటు. ఆ నియమం యొక్క రెండు భాగాలు వాస్తవాన్ని వివరించాలి, ఏదీ ఐచ్ఛికం కాదు.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

సాంప్రదాయ వైఫల్యం అనేది గైడ్ నుండి కాపీ చేసిన నియమం, అది -o eth0 అని చెబుతుంది కానీ ఆ యంత్రం అడాప్టర్ వేరే పేరుతో ఉంది. నియమం ఎలాంటి హెచ్చరిక లేకుండా ఇన్‌స్టాల్ అవుతుంది, ఏదానితోా సరిపోదు, క్లయింట్‌కు ఇంకా ఇంటర్నెట్ లేదు. పూల్ అదే తప్పు యొక్క మరో సగం: సర్వర్ 10.44.0.0/24 పంచి, నియమం 10.8.0.0/24 ను కవర్ చేస్తే, ఏదీ ఎప్పటికీ సరిపోదు.

నియమం పాఠ్యాన్ని నమ్మడం బదులు కౌంటర్లను చూడండి. జాబితా ప్రతి నియమానికి ప్యాకెట్లను నివేదిస్తుంది, ఎప్పుడూ సరిపోని నియమం ఎంత సరిగ్గా కనిపించినా సున్నా వద్దే ఉంటుంది. ఆ సంఖ్య నుండి ఏదైనా చదవడానికి ముందు దానికి ఒక నిమిషం నిజమైన క్లయింట్ ట్రాఫిక్ ఇవ్వండి:

iptables -t nat -L POSTROUTING -v -n

నిజమైన క్లయింట్ పరీక్ష తర్వాత సున్నా ప్యాకెట్ లెక్క అంటే సరిపోలిక తప్పు, టన్నెల్ విరిగిపోలేదు. ఒకసారి సరిపోయిన తర్వాత నియమాల సమితిని సేవ్ చేయండి, అది రీబూట్‌ను తట్టుకోవాలి; మీ shell చరిత్రలో మాత్రమే జీవించే సరిచేయడం మొదటి రీస్టార్ట్‌లోనే మాయమవుతుంది.

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

DNS అనేది మొదటి వైఫల్యం వెనుక రెండవది

పేర్లు విఫలమవుతుండగా చిరునామాతో ping పనిచేయడం రిజాల్వర్ సమస్య, దానికి దాని స్వంత కారణం ఉంది. తన స్థానిక రిజాల్వర్‌ను ఉంచుకునే క్లయింట్ ఆ ప్రశ్నలను పూర్తి టన్నెల్‌లోకి పంపి ఎప్పటికీ రాని సమాధానం కోసం వేచి ఉంటుంది, ఎందుకంటే స్థానిక రిజాల్వర్ ఇప్పుడు మార్గానికి తప్పు వైపున ఉంది.

క్లయింట్ ఎక్కడ అడగాలో తెలియడానికి సర్వర్ నుండి రిజాల్వర్‌ను పుష్ చేయండి. రెండు ఎంట్రీలు మొదటిది చేరుకోకపోతే క్లయింట్‌కు ప్రత్యామ్నాయం ఇస్తాయి, రెండూ టన్నెల్ నిజంగా అనుమతించే రిజాల్వర్లు అయి ఉండాలి.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows క్లయింట్లు తర్వాత స్థానిక రిజాల్వర్‌కు తిరిగి వెళ్లవచ్చు, block-outside-dns అదే నివారించడానికి ఉంది, కానీ స్థానిక నెట్‌వర్క్ మాత్రమే పరిష్కరించగల పేర్లను కోల్పోయే ఖర్చుతో. systemd-resolved ఉపయోగించే Linux క్లయింట్లు స్క్రిప్ట్ ఇన్‌స్టాల్ చేయకపోతే పుష్ చేసిన రిజాల్వర్‌ను తరచుగా విస్మరిస్తాయి, కాబట్టి పుష్ విస్మరించబడిందని నిర్ణయించే ముందు టన్నెల్ పరికరం కోసం resolvectl status తనిఖీ చేయండి.

వినియోగదారు అనుభవించిన విధంగానే ఈ ప్రయాణాన్ని పూర్తి చేయండి. క్లయింట్ నుండి నిజమైన పేజీని లోడ్ చేయండి, అది ఏ చిరునామా నుండి బయటకు వెళ్తుందో నిర్ధారించండి, సర్వర్‌ను రీబూట్ చేయండి, మళ్లీ కనెక్ట్ అవ్వండి మరియు మూడు పరీక్షలను మళ్లీ చేయండి. ఆ రెండో రౌండ్ మాత్రమే సేవ్ చేసిన నియమాలు, ఫైర్‌వాల్ విధానం మరియు పుష్ చేసిన రిజాల్వర్ అన్నీ కలిసి నిలిచాయని నిరూపిస్తుంది.