Access Server గేట్వే వినియోగదారు: క్లయింట్ శాఖ LAN రౌటింగ్

OpenVPN క్లయింట్ యొక్క టన్నెల్ చిరునామాకు ping చేయవచ్చు, కానీ దాని వెనుక ఉన్న LAN లో ఏ హోస్ట్కూ చేరలేరు. Access Server VPN పూల్ నుండి చిరునామా ఇస్తుంది; పూల్ చిరునామా మాత్రమే సర్వర్ తనదిగా తెలిసినది. శాఖ ప్రిఫిక్స్ విడిగా ప్రకటించాల్సిన విషయం; ఆ తర్వాత కూడా శాఖకు ఫార్వర్డర్, ప్రధాన కార్యాలయానికి తిరుగు మార్గం అవసరం. తప్పు చోట రాసిన మార్గం ఏమీ మార్చదు.

రెండు చిరునామాలు, రెండు యాజమాన్య వాదనలు

క్లయింట్ కనెక్ట్ అయినప్పుడు Access Server కాన్ఫిగర్ చేసిన పూల్ నుండి 10.90.0.0/24 వంటి చిరునామా ఇస్తుంది. అది ఒక హోస్ట్కు లీజు. అదే క్లయింట్ 10.60.0.0/24 ముందు కూడా ఉందని కనెక్షన్ చెప్పదు: నిర్వాహకుడు ప్రకటిస్తే మాత్రమే నిర్దిష్ట క్లయింట్ ద్వారా ప్రిఫిక్స్ చేరుకోగలరు.

అందుకే మరో మెషీన్లో స్థిర మార్గం పనిచేయదు. మార్గం 10.60.0.0/24 ను ఈ చిరునామాకు పంపమని చెబుతుంది; చిరునామా గేట్వేగా గుర్తించబడని క్లయింట్ది అయితే ఆ ప్యాకెట్లను అక్కడికి చేర్చడానికి కారణం లేదు. ప్రకటన, మార్గం ఒకే యంత్రాంగంలోని రెండు భాగాలు.

గేట్వే సెట్టింగ్ ఇన్స్టాల్ చేసేది

Admin Web UI లో ప్రకటన వినియోగదారు లక్షణం: connector వినియోగదారుపై Configure VPN gateway ప్రారంభించి నిజమైన ప్రిఫిక్స్ను Network on the VPN client side లో ఇవ్వండి. అతను ఇతరుల్లాగే ధృవీకరించబడతాడు, కాబట్టి పర్యవేక్షణ లేని పరికరానికి సరిపోయే విధానం కావాలి.

సర్వర్ ప్రిఫిక్స్ను ఆ క్లయింట్ పూల్ చిరునామా ద్వారా చేరుకోగలదిగా భావిస్తుంది; Access Controls కింద రౌటింగ్ కాన్ఫిగరేషన్ ఇతరులకు ఏమి చెప్పాలో నిర్ణయిస్తుంది: సాధారణ క్లయింట్లకు పంపే మార్గాలు, ప్రధాన కార్యాలయ నెట్వర్క్ల నుండి క్లయింట్ చిరునామాలకు అనుమతులు. శాఖను చేరుకోవాల్సిన నెట్వర్క్లకు రౌటింగ్ ప్రారంభించండి.

సృష్టించిన ఫైల్లో అతికించిన Community శైలి సూచన ఈ నమూనాలో పాల్గొనదు. ఉత్పత్తి పంపే రౌటింగ్ పట్టిక దాని సొంతం; చేతితో సవరించిన పంక్తి భర్తీ చేయబడుతుంది.

రెండు నెట్వర్క్ల తిరుగు మార్గాలు

ప్రణాళిక: ప్రధాన కార్యాలయం 10.40.0.0/24, శాఖ 10.60.0.0/24, VPN పూల్ 10.90.0.0/24, Access Server ప్రైవేట్ చిరునామాలో. రౌటర్కు శాఖ ప్రిఫిక్స్, పూల్ మార్గాలు కావాలి. లేకపోతే సమాధానం డిఫాల్ట్ గేట్వే ద్వారా బయటకు వెళ్తుంది.

శాఖలో connector తనకు చిరునామా కాని ప్యాకెట్లను పంపాలి: OS లో IP ఫార్వర్డింగ్ మరియు టన్నెల్, LAN ఇంటర్ఫేస్లకు పరిమిత అనుమతి; Linux లో net.ipv4.ip_forward=1 forward చైన్ నియమాలతో, Windows లో routing and remote access. తర్వాత హోస్ట్లకు తిరుగు మార్గం కావాలి: connector వాటి డిఫాల్ట్ గేట్వే, లేదా ఉన్న గేట్వే ప్రత్యేక మార్గాలను మోస్తుంది.

connector రౌటింగ్ పట్టిక శాఖ LAN లోని ప్రతి హోస్ట్ను మళ్లీ కాన్ఫిగర్ చేయదు. హోస్ట్లు మరో రౌటర్ను చూపితే తిరుగు మార్గాలు అక్కడే, మరియు అది చూసే మూల చిరునామా స్థానిక సబ్నెట్ పొరుగు కాదని అంగీకరించాలి.

వైఫల్యాన్ని మార్గంగా చదవండి

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

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

రెండు డిజైన్లకు ఎక్కువ కావాలి. అతివ్యాప్తి ప్రిఫిక్స్లు గమ్యాన్ని అస్పష్టం చేస్తాయి; క్లస్టర్ Access Server లో ప్రతి నోడ్కు connector వరకు పనిచేసే మార్గం ఉండాలి. మార్పులను సాధారణ సేవ్ మార్గంలో అమలు చేసి connector ను మళ్లీ కనెక్ట్ చేసి రెండు వైపులా నిర్ధారించుకోండి.

Access Server site-to-site ట్యుటోరియల్ అదే సెట్టింగ్లను ఉత్పత్తి క్రమంలో జాబితా చేస్తుంది.