OpenVPN క్లయింట్ సర్వర్కు చేరుతుంది కానీ LAN హోస్ట్లకు చేరదు: తనిఖీ జాబితా

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

మొదటి దశ: క్లయింట్ రూటింగ్ నిర్ణయాన్ని గమనించండి

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

ip route get 192.168.50.10

సమాధానం మీ భౌతిక అడాప్టర్ మరియు ఆఫీసు గేట్వేను పేర్కొంటే, సర్వర్ వైపు ఎలాంటి మార్పు సహాయపడదు. OpenVPN సర్వర్ వాటిని నెట్టినప్పుడే మార్గాలను పంచుతుంది, కాబట్టి సర్వర్ కాన్ఫిగరేషన్లో push "route 192.168.50.0 255.255.255.0" వెతకండి, తర్వాత క్లయింట్ను మళ్లీ కనెక్ట్ చేయండి. చాలా క్లయింట్లు నెట్టిన మార్గాలను కనెక్ట్ అయ్యే సమయంలో వర్తింపజేస్తాయి, ప్రొఫైల్ను మళ్లీ లోడ్ చేసినప్పుడు కాదు.

Windowsలో అదే ప్రశ్నకు వేరే ఆదేశం ఉంది. Find-NetRoute -RemoteIPAddress 192.168.50.10 స్టాక్ ఎంచుకునే ఇంటర్ఫేస్ మరియు తదుపరి హాప్ను ముద్రిస్తుంది, route print -4 నెట్టిన ప్రిఫిక్స్ అసలు ఉందో లేదో చూపిస్తుంది.

రెండవ దశ: సర్వర్ ప్యాకెట్ను ఫార్వార్డ్ చేస్తుందని నిర్ధారించండి

క్లయింట్ మార్గం సరిగ్గా ఉంటే, ప్యాకెట్ సర్వర్కు చేరుతుంది, సర్వర్ దాన్ని ఫార్వార్డ్ చేయడానికి అంగీకరించాలి. కెర్నల్ స్విచ్ మొదటి ద్వారం, sysctl net.ipv4.ip_forward 1ని తిరిగి ఇవ్వాలి. echo 1 > /proc/sys/net/ipv4/ip_forward ఉపయోగించి దాన్ని సెట్ చేయడం తదుపరి రీబూట్ వరకు పనిచేస్తుంది, అందుకే అదే ఫిర్యాదు వారాల తర్వాత తిరిగి వస్తుంది.

రీస్టార్ట్ను దాటి నిలిచే చోట దాన్ని రాయండి:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

రెండవ ద్వారం ఫిల్టర్ పట్టిక. Docker ఇన్స్టాల్ ఉన్న హోస్ట్ తరచుగా FORWARD విధానాన్ని DROPగా కలిగి ఉంటుంది, టన్నెల్ ఆ నిర్ణయాన్ని వారసత్వంగా పొందుతుంది. iptables -L FORWARD -v -n విధానాన్ని మరియు ప్యాకెట్ కౌంటర్లను రెండింటినీ చూపిస్తుంది; విధానం DROP అయితే, ఫార్వార్డింగ్కు టన్నెల్ నుండి LAN దిశకు ఒక స్పష్టమైన అనుమతి మరియు ప్రతిస్పందనకు మరొకటి అవసరం.

మూడవ దశ: ప్యాకెట్ను LAN వరకు అనుసరించి ప్రతిస్పందనను వెతకండి

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 మీద, తర్వాత మళ్లీ eth0 మీద 10.8.0.x మూలంతో కనిపించి, ఆ తర్వాత నిశ్శబ్దం ఏర్పడే అభ్యర్థనలు, ప్యాకెట్ వచ్చిందని మరియు ప్రతిస్పందన వేరే చోటికి వెళ్లిందని అర్థం. LAN హోస్ట్ తన డిఫాల్ట్ గేట్వేకు ప్రతిస్పందిస్తుంది, ఆ గేట్వేకు VPN పూల్ కోసం మార్గం లేదు, ప్రతిస్పందన LAN రౌటర్లో మరణిస్తుంది. సర్వర్ నుండి LAN హోస్ట్కు ping చేయడం ఈ మార్గం గురించి ఏమీ నిరూపించదు, ఎందుకంటే ఆ ట్రాఫిక్ ఎప్పుడూ టన్నెల్ను దాటదు.

నాల్గవ దశ: అనువాదం మరియు తిరిగి వచ్చే మార్గం మధ్య ఎంచుకోండి

రెండు మరమ్మతులు రంధ్రాన్ని మూస్తాయి, ping పనిచేస్తుందా అన్నదానికి మించిన పరిణామాలు ఈ ఎంపికకు ఉన్నాయి. మూల అనువాదం సర్వర్ను కనిపించే పంపినవాడిగా చేస్తుంది:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

నియమాన్ని పూల్ మరియు LAN ఇంటర్ఫేస్కు పరిమితం చేయండి, తర్వాత దాన్ని శాశ్వతం చేయండి, లేకపోతే తదుపరి ఫైర్వాల్ రీలోడ్ మీ మరమ్మతును నిశ్శబ్దంగా తొలగిస్తుంది. ధర గుర్తింపు: LAN లాగ్లలో మరియు యాక్సెస్ నియమాలలో ప్రతి క్లయింట్ VPN సర్వర్లా కనిపిస్తుంది, మరియు per-client policy becomes guesswork.

LAN రౌటర్లో VPN సర్వర్ వైపు చూపే 10.8.0.0/24 కోసం స్థిర మార్గం క్లయింట్ చిరునామాలను కనిపించేలా ఉంచుతుంది మరియు ఆ రౌటర్ మీదైతే ఇది మంచి దీర్ఘకాలిక సమాధానం. చాలా సైట్లు కొంతకాలం రెండింటినీ నడుపుతాయి, తక్షణ మరమ్మతుకు NAT మరియు ఫైర్వాల్ విధానం రాసిన తర్వాత మార్గం. సర్వర్ పూల్ కాకుండా సైట్-టు-సైట్ పీర్ అయితే, సర్వర్ వైపు కూడా రిమోట్ సబ్నెట్ కోసం iroute అవసరం, లేకపోతే పీర్ మార్గం ఉంటుంది కానీ క్లయింట్ ట్రాఫిక్ ఎప్పుడూ దానితో అనుబంధించబడదు.

ఐదవ దశ: క్లయింట్ నుండి ధృవీకరించి ఏమి మారిందో నమోదు చేయండి

లూప్ను సర్వర్ నుండి కాదు, క్లయింట్ నుండి మూసివేయండి. LAN హోస్ట్లోని నిజమైన సేవకు కనెక్ట్ అయ్యి, తర్వాత iptables -t nat -L POSTROUTING -v -n ఉపయోగించి అనువాద కౌంటర్లు కదిలాయని నిర్ధారించండి, ఎందుకంటే సున్నా ప్యాకెట్ల నియమం ఎప్పుడూ సరిపోలని నియమం. తిరిగి వచ్చే దిశ ట్రాక్ అవుతోందని రుజువు కావాల్సినప్పుడు conntrack -L -s 10.8.0.5 ప్రవాహాన్ని మరియు దాని స్థితిని చూపిస్తుంది.

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