రిమోట్ వినియోగదారులు VPN హబ్ ద్వారా రెండవ సైట్కు చేరుకోలేరు

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

ప్రయాణానికి మూడు లుకప్లు అవసరం, ఒక టన్నెల్ కాదు

ప్రతి పరికరం తన స్వంత పొడవైన ప్రిఫిక్స్ సరిపోలికను చేసి దానిని మరచిపోతుంది. ల్యాప్టాప్ 10.20.0.50ను తన స్థానిక రూటర్కు కాకుండా టన్నెల్లోకి పంపాలి. హబ్ రిమోట్-యాక్సెస్ ఇంటర్ఫేస్పై వచ్చిన ప్యాకెట్ను తీసుకుని సైట్-టు-సైట్ ఇంటర్ఫేస్కు అప్పగించాలి. ప్రధాన కార్యాలయం వినియోగదారు చిరునామాకు ప్రత్యుత్తరాన్ని టన్నెల్ ద్వారా తిరిగి పంపాలి. మూడింటిలో ఏదైనా ఒకటి విఫలమైనా బ్రౌజర్లో ఒకేలా కనిపిస్తుంది: నిశ్శబ్దం.

అందుకే ప్రతి టన్నెల్ను విడిగా పరీక్షించడం చాలా తక్కువ రుజువు చేస్తుంది. హబ్ యొక్క LAN చిరునామాకు పింగ్ చేయడం మొదటి నిర్ణయాన్ని పరీక్షిస్తుంది, ప్రధాన కార్యాలయం నుండి హబ్కు పింగ్ చేయడం మూడవదాన్ని పరీక్షిస్తుంది. విఫలమయ్యే ప్యాకెట్ మూలం వినియోగదారు పూల్ మరియు గమ్యం రెండవ సైట్, కాబట్టి మొదట ఆ ప్రిఫిక్స్లను రాయండి. ఇక్కడ పూల్ 10.80.0.0/24, హబ్ యొక్క LAN 10.10.0.0/24 మరియు ప్రధాన కార్యాలయం 10.20.0.0/24.

దూరపు ప్రిఫిక్స్ను రిమోట్ క్లయింట్కు నెట్టండి

ఒక OpenVPN రిమోట్-యాక్సెస్ సర్వర్పై క్లయింట్ కనెక్ట్ అయ్యే సమయంలో రూట్లను నేర్చుకుంటాడు. push లేకుండా, స్ప్లిట్-టన్నెల్ క్లయింట్ 10.20.0.50ను తన స్వంత గేట్వేకు పంపుతుంది మరియు ప్యాకెట్ ఎప్పుడూ టన్నెల్లోకి ప్రవేశించదు.

push "route 10.20.0.0 255.255.255.0"

నెట్టిన రూట్ క్లయింట్ కనెక్ట్ అయినప్పుడు అమలులోకి వస్తుంది, కాబట్టి ఆన్లైన్లో ఉండే వినియోగదారు మళ్లీ కనెక్ట్ అయ్యే వరకు ఏమీ చూడడు. క్లయింట్పై తనిఖీ చేయండి: Linuxలో ip route get 10.20.0.50, Windowsలో route print. అవుట్పుట్ టన్నెల్ ఇంటర్ఫేస్ను పేర్కొనాలి.

push హబ్కు సహాయపడదు. ఇది క్లయింట్కు సందేశం, సర్వర్పై రూట్ కాదు మరియు ఫార్వార్డ్ చేయడానికి అనుమతి కాదు, కాబట్టి పరిపూర్ణ push లైన్ ఉన్న హబ్ కూడా ఒక హాప్ తర్వాత ప్రవాహాన్ని వదిలివేస్తుంది. push విఫలమైందని ప్రజలు నిర్ణయించడానికి ఇదే సాధారణ కారణం.

హబ్కు నిజమైన ఎగ్రెస్ రూట్ ఇవ్వండి

హబ్కు ప్రధాన కార్యాలయ ప్రిఫిక్స్ కోసం తన స్వంత తదుపరి హాప్ అవసరం. రూటెడ్ టన్నెల్లో అది సైట్-టు-సైట్ ఇంటర్ఫేస్ ద్వారా వెళ్లే సాధారణ రూట్, మరియు ఒక ఆదేశం ఎంచుకున్న రూట్ మరియు ఎంచుకున్న మూలం రెండింటినీ చూపుతుంది:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

సైట్-టు-సైట్ కాలు స్వయంగా OpenVPN అయితే, రూట్ అదే కాన్ఫిగరేషన్లో పీర్ యొక్క టన్నెల్ చిరునామాను గేట్వేగా పెట్టుకుని నివసించవచ్చు: route 10.20.0.0 255.255.255.0 172.30.0.2. గేట్వే ఐచ్ఛికం కాదు. దాన్ని వదిలేస్తే తదుపరి హాప్ అమలు యొక్క డిఫాల్ట్కు పడిపోతుంది, అది ఒకే-రిమోట్ క్లయింట్ మరియు బహు-పీర్ హబ్ మధ్య భిన్నంగా ఉంటుంది.

విధాన-ఆధారిత IPsec భిన్నంగా ఉంటుంది: హబ్ యొక్క కెర్నల్ ప్యాకెట్ను తన సాధారణ LAN గేట్వేకు పంపుతుంది మరియు విధానం దాన్ని బయటకు వెళ్లే దారిలో పట్టుకుంటుంది, కాబట్టి టన్నెల్ రూట్ ఏమీ చేయదు లేదా విధానాన్ని దాటి ట్రాఫిక్ను తీసుకువెళుతుంది. పైన ఉన్న ఆదేశంలో మూలాన్ని గమనించండి, ఎందుకంటే పూల్ చిరునామా బదులు 10.10.0.1 అంటే కెర్నల్ దూరపు వైపు తిరస్కరించే చిరునామాను ఎంచుకుంది. iroute కూడా సమాధానం కాదు; ఇది సర్వర్కు ఏ క్లయింట్ తన టన్నెల్ వెనుక ఉన్న సబ్నెట్ను కలిగి ఉందో చెబుతుంది, మూడవ సైట్ కోసం ట్రాఫిక్ ఎక్కడికి పంపాలో కాదు.

దూరపు వైపును వినియోగదారు పూల్ వరకు విస్తరించండి

ప్రధాన కార్యాలయం ఇప్పటికే హబ్ యొక్క LAN, 10.10.0.0/24ను కవర్ చేస్తుంది. వినియోగదారు పూల్ రెండవ ప్రిఫిక్స్ మరియు అది సెలెక్టర్లలో కూడా ఉండాలి, లేకపోతే 10.80.0.25కు పంపిన ప్రత్యుత్తరాన్ని ఏ విధానం కవర్ చేయదు. ప్రతి పీర్ తన వైపు నుండి అదే జత ప్రిఫిక్స్ సెట్లను పేర్కొంటుంది:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ఒక పరికరం యొక్క local_ts మరొకదాని remote_ts. హబ్ యొక్క బ్లాక్ను ప్రధాన కార్యాలయానికి కాపీ చేయండి, జత తిరుగుతుంది, కాబట్టి చైల్డ్ SA ఎప్పుడూ పైకి రాదు.

పాత ipsec.conf సింటాక్స్ కామాతో వేరు చేసిన leftsubnet ఉపయోగిస్తుంది. నడుస్తున్న భద్రతా సంఘం తాను చర్చించిన సెలెక్టర్లను ఉంచుకుంటుంది, కాబట్టి సవరణ తర్వాత టన్నెల్ను తిరిగి ఏర్పాటు చేయండి. 10:00కి మార్చిన సెలెక్టర్ 09:40కి పైకి వచ్చిన SAకు వ్యతిరేకంగా పరీక్షించినా విఫలమవుతుంది, అయితే కాన్ఫిగ్ ఫైల్ అన్ని సమయాల్లో సరిగ్గా కనిపిస్తుంది.

తర్వాత చివరి హాప్ను తనిఖీ చేయండి. దూరపు చివరలో ip route get 10.80.0.25 టన్నెల్లోకి సూచించాలి. సేవ LAN రూటర్ను తన డిఫాల్ట్ గేట్వేగా ఉపయోగిస్తే, ఆ రూటర్కు కూడా రిటర్న్ రూట్ అవసరం, లేకపోతే ప్రత్యుత్తరం అక్కడే చనిపోతుంది. ఆ సెగ్మెంట్పై tcpdump -ni eth1 host 10.80.0.25 నడపడం ప్రత్యుత్తరం చివర నుండి బయటకు వెళ్లిందా అని చూపుతుంది.

హబ్పై ప్రవాహాన్ని అనుమతించండి

ఫార్వార్డింగ్ ప్రారంభించబడి మార్గం అనుమతించబడాలి. ఇంటర్ఫేస్ల మధ్య ప్రతిదీ అంగీకరించడం బదులు నియమాలను రెండు ప్రిఫిక్స్లకు పరిమితం చేయండి.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

రివర్స్-పాత్ ఫిల్టరింగ్ దాని పక్కన ఉన్న నిశ్శబ్ద వైఫల్యం: రెండు కాళ్లు వేర్వేరు ఇంటర్ఫేస్లపై ఉన్నప్పుడు, rp_filter=1 ప్రత్యుత్తరాన్ని వదిలేయవచ్చు, అయితే అంగీకార నియమం యొక్క కౌంటర్ అసలు కదలదు. ఒక ప్రయత్నానికి ముందు మరియు తర్వాత iptables -vnL FORWARD ఫలితాన్ని పోల్చండి. ఎప్పుడూ పెరగని నియమం చేరుకోబడదు, కాబట్టి దాన్ని తిరిగి రాయడం బదులు ఒక పొర కిందకు చూడండి.

ఒకే సమూహానికి ప్రయాణం అవసరమైతే, ప్రపంచ pushను విస్తరించడం బదులు client-config-dir కింద ప్రతి-క్లయింట్ ఫైల్లో రూట్ను ఉంచండి. హబ్పై Source NAT కూడా దూరపు వైపు రిటర్న్ రూట్ అవసరాన్ని తొలగిస్తుంది, కానీ అది వినియోగదారు చిరునామాను దాచుతుంది, కాబట్టి దూరపు సైట్ లాగ్లు మరియు చిరునామా-ఆధారిత నియమాలు వినియోగదారులను వేరు చేయడం ఆపేస్తాయి.

క్లయింట్ నుండి ధృవీకరించండి, తర్వాత వ్యతిరేక క్రమంలో రోల్బ్యాక్ చేయండి

ICMP మాత్రమే కాకుండా TCP పోర్ట్ను పరీక్షించండి, ఎందుకంటే సేవ నిరోధించబడి ఉన్నప్పుడు పింగ్ దాటవచ్చు. క్లయింట్ నుండి nc -vz 10.20.0.50 445 మరియు traceroute -n 10.20.0.50 రెండవ హాప్ హబ్ యొక్క టన్నెల్ చిరునామా అని చూపుతాయి. హబ్పై, tcpdump -ni tun0 host 10.20.0.50 మరియు సైట్-టు-సైట్ ఇంటర్ఫేస్పై అదే ఫిల్టర్: రెండింటిపై అభ్యర్థన కానీ ఏదానిపైనూ ప్రత్యుత్తరం లేకపోతే సమస్య దూరపు వైపుకు మారుతుంది.

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

రోల్బ్యాక్ జాబితాను ఉంచండి, ఎందుకంటే నాలుగు వస్తువులు మారాయి మరియు మూడు మరచిపోవడం సులభం: నెట్టిన రూట్, హబ్ యొక్క రూట్, సెలెక్టర్లు మరియు ఫైర్వాల్ నియమాలు. వాటిని వ్యతిరేక క్రమంలో ఉపసంహరించండి, SAను తిరిగి ఏర్పాటు చేయండి, మరియు ఒక వినియోగదారు మళ్లీ కనెక్ట్ కావడానికి అనుమతించండి. పాక్షిక రోల్బ్యాక్ ఇకపై సరిపోలని టన్నెల్కు సూచించే రూట్ను వదిలివేస్తుంది, దాన్ని చదవడం అసలు నిశ్శబ్దం కంటే కష్టం. OpenVPN 2.6 మాన్యువల్ మీ వెర్షన్ కోసం push, route మరియు iroute డాక్యుమెంట్ చేస్తుంది.