రెండు OpenVPN సర్వర్లపై ఉన్న క్లయింట్లు ఒకరినొకరు చేరుకోగలరా?

రెండవ OpenVPN సర్వర్ను నెలకొల్పడం క్లయింట్లు కనెక్ట్ కావడానికి రెండవ స్థలాన్ని ఇస్తుంది, అంతే. అది ఆ క్లయింట్లను మొదటి సర్వర్ నెట్వర్క్లో ఉంచదు, client-to-client అనే ఎంపిక ఒక సర్వర్ ప్రాసెస్ లోపల ఫార్వార్డింగ్ను మాత్రమే మారుస్తుంది. మీరు ఉద్దేశపూర్వకంగా వాటి మధ్య రూటింగ్ చేసినప్పుడు ఆ రెండు పూల్లు ఒక నెట్వర్క్ అవుతాయి, ప్రతి దిశకు ఒక యజమానితో. క్రింద ఉన్నవన్నీ యూజర్-స్పేస్ TUN మోడ్ను ఊహిస్తాయి, అందులో ఆ అంతర్గత ఫార్వార్డింగ్ ఆఫ్ చేయబడి ఉంటుంది, కాబట్టి నిర్ణయం కెర్నల్ తీసుకుంటుంది.

అపోహ: ఒక ఖాతా జాబితా, ఒక నెట్వర్క్

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

అందువల్ల రెండవ సర్వర్ను జోడించడం రిడండెన్సీ, డిస్కవరీ లేదా పంచుకున్న బ్రాడ్కాస్ట్ డొమైన్ను జోడించదు. ప్రణాళిక అవసరమయ్యే రూటెడ్ నెట్వర్క్ను జోడిస్తుంది, ఆ ప్రణాళిక చిరునామా కేటాయింపుతో మొదలవుతుంది.

ప్రతి గేట్వేకు దాని సొంత పూల్ మరియు ట్రాన్సిట్ చిరునామా ఇవ్వండి

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

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

రెండు వైపులా మార్గాన్ని ఇన్స్టాల్ చేయండి

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

యాజమాన్యాన్ని నటించకుండా క్లయింట్ మార్గాన్ని నెట్టండి

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

push "route 10.64.20.0 255.255.255.0"

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

ఒక అభ్యర్థనను నిరూపించి మరొకదాన్ని తిరస్కరించండి

నిజమైన ఆపరేషన్ను ఎంచుకోండి, ఉదాహరణకు 10.64.10.21లోని క్లయింట్ నుండి 10.64.20.37లోని సేవకు HTTPS, మరియు రెండు హోస్ట్లపై సరిగ్గా దాన్నే అనుమతించండి. ప్రతి ఫైర్వాల్ తన ఇన్బౌండ్ వైపు అభ్యర్థనను మరియు రిటర్న్ వైపు ట్రాక్ చేసిన ప్రతిస్పందనను అంగీకరిస్తుంది; గమ్యం సొంత సేవా విధానం ఇంకా దాన్ని అంగీకరించాలి.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

పరస్పర మార్గాలు ఉన్నప్పుడు సోర్స్ NAT అనవసరం మరియు ఇక్కడ చురుకుగా హానికరం: సోర్స్ను అనువదించడం అభ్యర్థన ఏ క్లయింట్ చేసిందో దాస్తుంది మరియు గమ్యం వైపు సోర్స్ ఆధారిత విధానాన్ని భంగం చేస్తుంది. ఇంటర్నెట్ బయటకు వెళ్లడానికి ఉన్న మాస్కరేడ్ నియమం ఈ మార్గాన్ని కూడా పట్టుకోదని తనిఖీ చేయండి. తర్వాత తిరస్కరణను పరీక్షించండి. పూల్ Bలో స్థానికంగా ఉండాల్సిన సేవ పూల్ A నుండి చేరుకోలేనిదిగా ఉండాలి, మరియు ఒకే గేట్వేపై క్లయింట్ జంటలను కూడా పరీక్షించాలి, ఎందుకంటే మీరు ఇప్పుడే మార్చిన ఫార్వార్డింగ్ విధానం వాటికీ వర్తిస్తుంది.

మానసిక నమూనాకు మరో సవరణ: ట్రాన్సిట్ లింక్ డీక్రిప్ట్ చేసిన అంతర్గత ప్యాకెట్లను మోసుకుపోతుంది, కాబట్టి అది ప్రైవేట్ హామీ కాదు, విశ్వాస సరిహద్దు. అది మీరు నియంత్రించని నెట్వర్క్ను దాటితే, ఆ హాప్ను ఆమోదిత ఎన్‌క్రిప్టెడ్ టన్నెల్తో రక్షించి దాని నిజమైన టోపాలజీ ద్వారా రూట్ చేయండి. ఎండ్-టు-ఎండ్ TLS ఇంకా అప్లికేషన్ను తనే ప్రామాణీకరిస్తుంది, అందుకే అంతర్గత సేవ దాన్ని కొనసాగించాలి.