WireGuard క్లయింట్ OpenVPN క్లయింట్‌ను చేరుకోలేకపోతున్నారా?

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

లక్షణంలో ఒకసారికి ఒక భాగమే లోపిస్తుంది

ఈ నిర్మాణం wg1 పై 10.71.0.0/24 యొక్క WireGuard పూల్ మరియు tun1 పై 10.72.0.0/24 యొక్క OpenVPN పూల్‌ను ఉపయోగిస్తుంది, రెండూ ఒకే గేట్‌వే వద్ద ముగుస్తాయి. పరీక్షలో ఉన్న అభ్యర్థన 10.71.0.5 నుండి 10.72.0.30 లోని HTTPS కి వెళ్తుంది. క్రింది ప్రతి దశ ఆ ఒకే ప్రవాహానికి సంబంధించినది. ప్రతి తనిఖీకి వేరే వైఫల్య సంతకం ఉన్నా వినియోగదారు వాటిని ఒకేలా అనుభవిస్తారు, సాధారణంగా ఒకసారికి మూడింటిలో ఒకటి మాత్రమే లోపిస్తుంది.

రెండు పూల్‌లూ నిజంగా ఈ గేట్‌వేపై ఉన్నాయని, సొరంగాలు నివసించే namespace లో ఫార్వార్డింగ్ ఆన్‌లో ఉందని నిర్ధారించి ప్రారంభించండి. రెండు ప్రోటోకాల్‌లను వేరే namespace లలో ముగించే గేట్‌వే వాటి మధ్య ఏమీ ఫార్వార్డ్ చేయదు, ఏదైనా peer కాన్ఫిగరేషన్ చదవకముందే దీన్ని మినహాయించడం విలువైనది.

స్పోక్ యొక్క గమ్య కవరేజీని విస్తరించండి

WireGuard క్లయింట్‌లో, ఉన్న peer నమోదు OpenVPN గమ్యం కోసం గేట్‌వేను ఎంచుకోవాలి, అంటే గమ్య ఉపసర్గ ఆ peer యొక్క అనుమతించిన జాబితాలో ఉండాలి. దాన్ని జోడించడం రెండవ సొరంగాన్ని సృష్టించదు; ఆ చిరునామాను వెతికేటప్పుడు క్లయింట్ ఏ peer ను ఎంచుకుంటుందో మారుస్తుంది, wg-quick తో మార్గం సాధారణంగా జాబితాను స్వయంచాలకంగా అనుసరిస్తుంది.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

నిజమైన కీ మరియు endpoint పంక్తులను తాకకుండా ఉంచండి, Table = off ఉపయోగించే నిర్వాహకుడు ఈ జాబితా నుండి ఎలాంటి మార్గాన్ని తీసుకోరని గుర్తుంచుకోండి. అలాంటి సందర్భంలో అదే ఉపసర్గను సిస్టమ్ మార్గ పట్టికలో దాని యజమాని ఇన్‌స్టాల్ చేయాలి, అక్కడ లేని మార్గం లేని అనుమతించిన ఉపసర్గలా కనిపిస్తుంది.

గేట్‌వేపై మూల యాజమాన్యాన్ని ఉంచండి

ఈ క్లయింట్ యొక్క peer నమోదు గేట్‌వేపై ఆ క్లయింట్ మూల చిరునామానే కొనసాగించాలి. అనుమతించిన చిరునామాలు రెండు దిశల్లోనూ తనిఖీ చేయబడతాయి: బయటకు వెళ్లే ట్రాఫిక్ కోసం peer ను ఎంచుకుంటాయి మరియు లోపలికి వచ్చే ప్యాకెట్ మూలం దాన్ని పంపిన peer కే చెందుతుందని నిర్ధారిస్తాయి. స్పోక్ ఆ పూల్‌ను చేరుకోవాలని కోరుకుంటున్నందున OpenVPN పూల్‌ను స్పోక్ నమోదులో పెట్టడమే ట్రాఫిక్‌ను తప్పు భాగస్వామి వైపు నెట్టే తప్పు.

AllowedIPs = 10.71.0.5/32

ఆ నమోదును మార్గ సౌలభ్యంగా కాక యాజమాన్య ప్రకటనగా చదవండి. క్లయింట్ చేరుకోవాల్సిన మిగతావన్నీ క్లయింట్ గమ్య జాబితాలో ఉంటాయి, ఈ peer ఏమి పంపవచ్చన్న గేట్‌వే ఊహలో కాదు.

OpenVPN వైపుకు తిరిగి వచ్చే మార్గం ఇవ్వండి

గమ్యానికి ఇప్పుడు WireGuard మూలానికి తిరిగి వెళ్లే మార్గం కావాలి, పూల్ క్లయింట్లకు అది సాధారణంగా OpenVPN సర్వర్ నుండి నెట్టబడిన మార్గంగా వస్తుంది. ఉండాల్సిన క్లయింట్లకు మాత్రమే దాన్ని నెట్టండి, ఆదేశం వర్తించిందని ఊహించకుండా క్లయింట్‌పై అది అంగీకరించబడిందని నిర్ధారించండి.

push "route 10.71.0.0 255.255.255.0"

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

మీరు అనుమతించాలని భావించిన ఆ ఒకే సేవను మాత్రమే అనుమతించండి

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

ఇవి ఫార్వార్డ్ చేయబడిన ట్రాఫిక్ కోసం నియమాలు, గేట్‌వే యొక్క రెండు VPN సేవలకు సంబంధించిన వినడం నియమాలకు భిన్నంగా. బయటి UDP పోర్టులను తెరవడం లోపలి అభ్యర్థనను అధికారపరచదు, లోపలి అభ్యర్థనను అధికారపరచడానికి గేట్‌వేకు అపరిమిత SSH లేదా ఫార్వార్డింగ్‌పై డిఫాల్ట్ అనుమతి అవసరం లేదు. గమ్యం సొంత firewall మరియు వినడం చిరునామా కూడా సరిపోలాలి, ఎందుకంటే loopback కు కట్టబడిన సేవ అత్యంత జాగ్రత్తగా మార్గనిర్దేశం చేయబడిన ప్యాకెట్‌నూ తిరస్కరిస్తుంది. సంభాషణలో ఒక దిశను మాత్రమే కవర్ చేసే విధానం సాధారణంగా విజయవంతమైన అభ్యర్థన మరియు నిశ్శబ్ద ప్రత్యుత్తరంతో విఫలమవుతుంది, ఇది మూడింటిలో అత్యంత గందరగోళకరమైన ఫలితం.

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