సైట్-టు-సైట్ VPN లేదా రిమోట్ యాక్సెస్: ప్రతి ఒకటి ఏమి కలుపుతుంది
ఒకటి గేట్‌వేలను కలుపుతుంది, మరొకటి పరికరాలను కలుపుతుంది. ట్రాఫిక్ సెలెక్టర్లను మార్గాలతో పోల్చండి, చిరునామాలను ప్లాన్ చేయండి, ఆపై నిజమైన హోస్ట్ నుండి ఫార్వార్డింగ్ మరియు విధానాన్ని పరీక్షించండి.
రెండు డిజైన్లను VPN అని పిలుస్తారు మరియు అవి వేర్వేరు సమస్యలను పరిష్కరిస్తాయి. సైట్-టు-సైట్ టన్నెల్ రెండు గేట్‌వేలను కలుపుతుంది, కాబట్టి వాటి వెనుక ఉన్న ప్రతి హోస్ట్ ఏమీ ఇన్‌స్టాల్ చేయకుండా మరొక వైపు అనుమతించిన చిరునామాలను చేరుకోగలదు. రిమోట్ యాక్సెస్ టన్నెల్ వ్యక్తిగత పరికరాలను నెట్‌వర్క్‌కు కలుపుతుంది, ఒక సమయంలో ఒక క్లయింట్. ఈ పోలిక ముఖ్యం ఎందుకంటే చాలా డిప్లాయ్‌మెంట్ తప్పులు ఒకదాన్ని కాన్ఫిగర్ చేసి మరొకదాని ప్రవర్తనను ఆశించడం వల్ల జరుగుతాయి, మరియు లక్షణం సాధారణంగా టన్నెల్ నిజంగా చేరుకున్న సేవలో సమయం ముగియడం.
రెండు డిజైన్లు, రెండు హద్దులు
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
ఏ డిజైన్ LAN ప్రసార డొమైన్‌ను విస్తరించదు. దూరం వైపు పరికరాలు స్థానిక ఆవిష్కరణ జాబితాలో కనిపించవు, అలా ఆశించడం విడిచిపెట్టాల్సిన మొదటి ఊహ. మీరు ఉద్దేశపూర్వకంగా ప్రచురించే ప్రైవేట్ DNS పేర్లు ఏ ఆవిష్కరణ ప్రోటోకాల్ కంటే ఎక్కువ అంచనా వేయదగినవి, సరఫరాదారు మారినా అవి నిలిచి ఉంటాయి.
ఒక సైట్‌లో 10.10.0.0/24 మరియు మరొకదానిలో 10.20.0.0/24 తీసుకోండి. గేట్‌వే A కు 10.20.0.0/24 ప్రిఫిక్స్‌ను టన్నెల్‌లోకి పంపే మార్గం లేదా ట్రాఫిక్ సెలెక్టర్ అవసరం, గేట్‌వే B కు దాని అద్దం ప్రతిబింబం అవసరం. ఆ తర్వాత రెండు వైపుల హోస్ట్‌లు సాధారణ IP కనెక్టివిటీని ఉపయోగిస్తాయి మరియు టన్నెల్ ఉందని ఎప్పటికీ తెలియదు. ఆ అదృశ్యత్వమే లక్షణం, వైఫల్యాలు టన్నెల్ లోపాలుగా కాకుండా సాధారణ నెట్‌వర్క్ లోపాలుగా కనిపించడానికి కూడా అదే కారణం.
విధాన ఆధారిత మరియు మార్గ ఆధారిత ఒకే టన్నెల్ కాదు
విధాన ఆధారిత IPsec డిప్లాయ్‌మెంట్‌లో, చర్చించిన ట్రాఫిక్ సెలెక్టర్లు ఏ మూలం మరియు గమ్యం జంటలు రక్షించబడుతున్నాయో ఖచ్చితంగా నిర్వచిస్తాయి. ఒక గేట్‌వే వెనుక కొత్త సబ్‌నెట్ కనిపించి ఏ సెలెక్టర్ దానిని కవర్ చేయకపోతే, టన్నెల్ నడుస్తూనే ఉంటుంది మరియు కొత్త సబ్‌నెట్ కేవలం తరలించబడదు. మార్గ ఆధారిత డిజైన్‌లో ఇంటర్‌ఫేస్ ట్రాఫిక్‌ను స్వీకరిస్తుంది మరియు రూటింగ్ పట్టిక నిర్ణయిస్తుంది, ఇది ప్రిఫిక్స్ జోడించడాన్ని టన్నెల్ పునఃచర్చ కాకుండా మార్గ మార్పుగా మారుస్తుంది.
StrongSwan రెండు వీక్షణలను నేరుగా చూపుతుంది, వాటిని కలిసి చదవడమే మీరు నిజంగా ఏ మాదిరిని డిప్లాయ్ చేశారో తెలుసుకునే మార్గం.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'మీకు అవసరమైన ప్రిఫిక్స్‌ను విడిచిపెట్టిన సెలెక్టర్ జాబితా ఎలాంటి ప్యాకెట్ క్యాప్చర్ లేకుండా వైఫల్యాన్ని వివరిస్తుంది, తప్పు ఇంటర్‌ఫేస్‌ను సూచించే మార్గం తిరిగి వచ్చే మార్గంలో అద్దం వైఫల్యాన్ని వివరిస్తుంది. ఏదైనా మళ్లీ చర్చించే ముందు రెండింటినీ చదవండి, ఎందుకంటే కీ పునరుద్ధరణ మీరు ఎప్పుడూ కాన్ఫిగర్ చేయని సెలెక్టర్‌ను జోడించదు.
టన్నెల్ ముందు చిరునామాలను ప్లాన్ చేయండి
అతివ్యాప్తి చెందే పరిధులు కాన్ఫిగరేషన్‌తో సరిచేయలేని డిజైన్ తప్పు. రెండు సైట్‌లు 192.168.1.0/24 ఉపయోగిస్తే, 192.168.1.50 అవసరమైన హోస్ట్‌కు ఇద్దరు అభ్యర్థులు ఉంటారు, ఎంచుకోవడానికి మార్గం ఉండదు. టన్నెల్ ప్రామాణీకరణ చేస్తుంది, భద్రతా సంఘాలు ఏర్పడతాయి, మార్గ నిర్ణయం అయినా తప్పుగా లేదా అస్పష్టంగా ఉంటుంది.
మూడు నిజాయితీ ఎంపికలలో ఒకటి ఎంచుకోండి: ఒక సైట్‌ను మళ్లీ నంబర్ చేయండి, గేట్‌వేలో అతివ్యాప్తి పరిధిని అనువదించి ప్రతి వైపు వేరే ప్రిఫిక్స్ చూసేలా చేయండి, లేదా ఆ హోస్ట్‌లకు ప్రత్యక్ష మార్గాన్ని వదిలి సేవను మరొక విధంగా ప్రచురించండి. ప్రతి దానికి ఖర్చు ఉంది, రెండేళ్ల హారిజన్‌లో మొదటిదే సాధారణంగా చవకైనది. టన్నెల్ ఏర్పడక ముందే నిర్ణయించండి, ఎందుకంటే తర్వాత ఆ మార్పు పాత చిరునామా ఉన్న ప్రతి పరికరాన్ని తాకుతుంది.
MTU సమస్యను కూడా ముందుగానే పరిష్కరించండి. టన్నెల్ ఉపయోగకరమైన భారాన్ని తగ్గిస్తుంది, ఫ్రాగ్మెంటేషన్‌పై ఆధారపడే డిజైన్ గేట్‌వేలలో MSS స్థిరీకరించే డిజైన్ కంటే భిన్నంగా ప్రవర్తిస్తుంది.
ఫార్వార్డింగ్ మరియు విధానం టన్నెల్ వెలుపల ఉంటాయి
గేట్‌వే టన్నెల్ ఇంటర్‌ఫేస్ మరియు LAN ఇంటర్‌ఫేస్ మధ్య ప్యాకెట్లను ఫార్వార్డ్ చేయడానికి సిద్ధంగా ఉండాలి, రెండు దిశలకూ సేవను అనుమతించే విధానం అవసరం. Linux లో ఇవి రెండు వేర్వేరు సెట్టింగ్‌లు, అదనంగా ఫార్వార్డ్ చేసిన ప్రవాహం అసలు అనుమతించబడిందా అని నిర్ణయించే ఫైర్‌వాల్ నియమాలు.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTస్వీకరించే హోస్ట్ మూడవ పొరను జోడిస్తుంది: దాని స్వంత ఫైర్‌వాల్ ఇంకా దూర సబ్‌నెట్ నుండి క్లయింట్‌ను అంగీకరించాలి. తన స్థానిక /24 ను మాత్రమే అనుమతించే ఫైల్ సర్వర్, టన్నెల్ ఎంత ఆరోగ్యంగా కనిపించినా 10.20.0.7 నుండి ఫార్వార్డ్ చేసిన ట్రాఫిక్‌ను తిరస్కరిస్తుంది, ఆ తిరస్కారాన్ని మార్గ వైఫల్యంగా చదవడం సులభం.
గేట్‌వే నుండి కాదు, హోస్ట్ నుండి పరీక్షించండి
గేట్‌వే స్వయంగా పంపే ping ఫార్వార్డ్ చేసిన వినియోగదారు ట్రాఫిక్ కంటే వేరే మూల చిరునామా మరియు వేరే విధానాన్ని అనుసరించవచ్చు. ఇది దానిని బలహీన పరీక్షగా చేస్తుంది మరియు కొన్నిసార్లు తప్పుదారి పట్టించేదిగా కూడా: యాప్ విఫలమైనప్పుడు అది విజయవంతమవుతుంది, లేదా యాప్ పని చేస్తున్నప్పుడు అది విఫలమవుతుంది.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullనిజమైన హోస్ట్, నిజమైన మూల చిరునామా మరియు యాప్ ఉపయోగించే నిజమైన ప్రోటోకాల్ ఉపయోగించండి. తర్వాత తిరిగి వచ్చే మార్గాన్ని విడిగా చదవండి, ఎందుకంటే తిరిగి వచ్చే మార్గం లేకుండా పని చేసే ముందు దిశ, నిరోధించిన సేవకు సమానంగా కనిపించే సమయ ముగింపును ఉత్పత్తి చేస్తుంది.
మీరు సమాధానం ఇస్తున్న ప్రశ్న ప్రకారం డిజైన్ ఎంచుకోండి: మీరు నెట్‌వర్క్‌లను కలుపుతున్నారా లేదా పరికరాలను అంగీకరిస్తున్నారా? మిగతావన్నీ, ఏ సరఫరాదారును కాన్ఫిగర్ చేస్తారు అనేది కూడా, ఆ సమాధానం నుండే వస్తాయి.