OpenVPN క్లయింట్లు గేట్వే యొక్క IPsec ఎంపికదారులను ఎందుకు తప్పిస్తాయి

గేట్వే నుండి దూరపు IPsec సొరంగం వెనుక ఉన్న హోస్ట్కు ping పంపండి, అది శుభ్రంగా ప్రత్యుత్తరం ఇస్తుంది, కాబట్టి సొరంగం ఆరోగ్యంగా కనిపిస్తుంది, టికెట్ ముందుకు సాగుతుంది. తర్వాత కనెక్ట్ అయిన క్లయింట్ అదే హోస్ట్ను ప్రయత్నిస్తుంది, ఏదీ తిరిగి రాదు. ఆ ping ఎప్పుడూ క్లయింట్ ప్రవాహానికి సాక్ష్యం కాదు, ఎందుకంటే అది గేట్వే యొక్క స్వంత మూల చిరునామాతో బయలుదేరి మరొక IPsec ఎంపికదారుతో సరిపోలింది. ఈ రెండు సందర్భాలు ఎందుకు భిన్నమవుతాయో అర్థం చేసుకోవడమే పరిష్కారంలో పెద్ద భాగం.

గేట్వే యొక్క ping మీ క్లయింట్ ఎప్పుడూ ఉపయోగించని ప్రవాహాన్ని పరీక్షిస్తుంది

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

అందుకే వైఫల్యం రూటింగ్ సమస్యలా కనిపిస్తుంది, నిజానికి అది విధాన పరిధి సమస్య. గేట్వే నుండి చేరుకోవడం పీర్ సక్రియంగా ఉందని, ప్రతిపాదనలు చర్చించబడ్డాయని నిరూపిస్తుంది, పూల్ రక్షితమా అనే దానిపై ఏమీ నిరూపించదు.

అప్లికేషన్కు నిజంగా అవసరమైన దూరపు ప్రిఫిక్స్ను నెట్టండి

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

నెట్టిన మార్గాలను అంగీకరించే Community సర్వర్లో, ఆదేశం నిజమైన మాస్క్ను తీసుకుంటుంది: push "route 172.30.239.0 255.255.255.128". Access Server అదే గమ్యాన్ని ఇన్స్టాల్ చేసిన సంస్కరణ యొక్క ప్రైవేట్-నెట్వర్క్ లేదా యాక్సెస్-రూల్ సెట్టింగ్ల ద్వారా కాన్ఫిగర్ చేస్తుంది, రూటెడ్ లేదా అనువదిత మోడ్ను ఉద్దేశపూర్వకంగా ఎంచుకుంటారు. యజమాని కాన్ఫిగరేషన్కు బదులు ఉత్పత్తి చేసిన ఫైర్వాల్ గొలుసులను సవరించడమే పనిచేసే సెటప్ను తిరిగి ఉత్పత్తి చేయలేనిదిగా మార్చే మార్గం.

కనెక్ట్ అయిన తర్వాత సర్వర్ ఉద్దేశాన్ని కాదు, క్లయింట్ రూటింగ్ పట్టికను చదవండి. పూల్ను మాత్రమే కవర్ చేసే మార్గం అంటే నెట్టడం ఎప్పుడూ రాలేదు, సొరంగం ద్వారా డిఫాల్ట్ మార్గం ఈ అవసరం కంటే విస్తృతం, తర్వాత మీకు ఆశ్చర్యం కలిగిస్తుంది. మాస్క్ మరియు ప్రిఫిక్స్ రెండింటినీ తనిఖీ చేయండి, ఎందుకంటే /25 ను /24 గా నెట్టడం పొరుగు చిరునామాల ట్రాఫిక్ను దానిని మోయలేని మార్గంలోకి పంపుతుంది. తర్వాత క్లయింట్ ఆ గమ్యానికి సొరంగ ఇంటర్ఫేస్ను ఎంచుకుందని నిర్ధారించండి.

ఎంపికదారుల్లో క్లయింట్ పూల్ చేర్చండి

క్లయింట్ చిరునామాలను కాపాడే రూటెడ్ యాక్సెస్ కోసం, IPsec విధానం పూల్ మరియు దూరపు ప్రిఫిక్స్ మధ్య ట్రాఫిక్ను రక్షించాలి. గేట్వే స్వంత LAN కోసం రాసిన ఎంపికదారులు ping ను అనుమతించి క్లయింట్ అభ్యర్థనను పారేస్తాయి, ఈ పరిశీలనను ప్రారంభించిన అసమానత అదే.

కాన్ఫిగర్ చేసిన ప్రతిపాదనలతో పాటు చర్చించిన విధానాన్ని కూడా పరిశీలించండి, ఉదాహరణకు strongSwan లో ipsec statusall లేదా మీ అమలుకు సమానమైన స్థితి ఆదేశం. విధాన ఆధారిత IPsec లో సాధారణ మార్గం భౌతిక ఇంటర్ఫేస్ను సూచించవచ్చు, కానీ సరిపోలే ట్రాఫిక్ ఇంకా ఎన్క్రిప్ట్ అవుతుంది, కాబట్టి సొరంగ పరికరం లేకపోవడం ఏమీ నిరూపించదు. ఎంపికదారు జంటలను మీరు రాసుకున్న పూల్ మరియు ప్రిఫిక్స్తో పోల్చండి.

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

ఉద్దేశపూర్వకంగా రూటింగ్ లేదా అనువాదాన్ని ఎంచుకోండి

రూటింగ్ క్లయింట్ చిరునామాను దూరపు వైపుకు కనిపించేలా ఉంచుతుంది, కాబట్టి దూరపు లాగ్లు మరియు మూలం వారీగా నియమాలు అర్థవంతంగా ఉంటాయి, దూరపు గేట్వే పూల్కు తిరిగి వెళ్లే మార్గాన్ని తెలుసుకోవాలి. అనువాదం పూల్ను ఒక చిరునామా వెనుక దాచుతుంది, ఇది తిరిగి వెళ్లే మార్గ సమస్యను తొలగించి ప్రతి క్లయింట్ గుర్తింపును నాశనం చేస్తుంది.

ఒక డిజైన్ను ఎంచుకుని రాసి ఉంచండి, ఎందుకంటే రెండింటికీ వేరే ఎంపికదారులు, వేరే ఫైర్వాల్ క్రమం కావాలి. సగం అమలు చేసిన masquerade వాటి మధ్య పడి ఏదీ సంతృప్తిపరచదు. రాసిన ఎంపికే తదుపరి ఇంజనీర్కు బగ్ మరియు ఉద్దేశపూర్వక నిర్ణయాన్ని వేరు చేయడానికి అవకాశం ఇస్తుంది.

ఫార్వర్డింగ్ మరియు ప్రత్యుత్తరంపై లూప్ మూసివేయండి

గేట్వే మీరు ఉద్దేశించిన ప్రోటోకాల్ మరియు గమ్యాన్ని ఫార్వర్డ్ చేయాలి, అంటే IP ఫార్వర్డింగ్ ఆన్లో ఉండాలి, జంటను అనుమతించే ఫార్వర్డ్ గొలుసు ఉండాలి. తర్వాత దూరపు వైపు IPsec మార్గం ద్వారా ప్రత్యుత్తరాలను తిరిగి పంపాలి, అది వారి గేట్వేపై రూటింగ్ నిర్ణయం, మీది కాదు. రెండు భాగాలూ సాధారణ కాన్ఫిగరేషన్, రెండింటినీ సగానికి వదిలేయడం సులభం. వాటిని విడివిడిగా పరీక్షించండి, తప్పిపోయిన ఫార్వర్డ్ నియమాన్ని పగిలిన సొరంగంగా భావించకుండా.

క్లయింట్ నుండి అప్లికేషన్కు ఒక నిజమైన అభ్యర్థనతో ధృవీకరించండి, అది OpenVPN ఇంటర్ఫేస్, IPsec నిర్ణయం మరియు దూరపు హోస్ట్ గుండా వెళ్లడాన్ని గమనించండి. ప్రత్యుత్తరాన్ని ప్రత్యేక పరిశీలనగా చూడండి, ఎందుకంటే చేరుకునే అభ్యర్థన, ఎప్పటికీ తిరిగి రాని ప్రత్యుత్తరం క్లయింట్ స్థానం నుండి ఒకేలా కనిపిస్తాయి. ఒక ట్రేస్ చేసిన అభ్యర్థన ఎన్ని గేట్వే ping ల కంటే ఎక్కువ విలువైనది.

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