हम शाखाओं को एक नेटवर्क में जोड़ते हैं। इंटरनेट की लागत कम करें

मैं आपका स्वागत करता हूं habrazhitel, इतनी देर पहले मैंने साइबेरिया में बिखरी हुई एक बड़ी कंपनी की शाखाओं को एक ही नेटवर्क में जोड़ने के काम का सामना नहीं किया। मुख्य समस्या यह थी कि ओपनवीपीएन को अस्थिर पीपीपीओई के शीर्ष पर काम करने के लिए मजबूर होना पड़ा, जबकि एक साथ सभी ओपनवीपीएन को ट्रैफिक की अनुमति देता है





प्रारंभिक लक्ष्य तब से शाखाओं में इंटरनेट ट्रैफ़िक पर पैसे बचाने का था दूरदराज के क्षेत्रों में, 256 AD / s की चौड़ाई के साथ असीमित ADSL की कीमत लगभग 7-10t.r है। प्रति माह, और इंटरनेट महत्वपूर्ण था।

सभी खुशी यह थी कि लगभग सभी शाखाओं में एक प्रदाता के कनेक्शन थे, जिसमें स्थानीय और पीयर-टू-पीयर ट्रैफ़िक की अवधारणा थी, और हेड ऑफ़िस में एक समर्पित व्यापक इंटरनेट (एक अन्य प्रदाता) था, लेकिन संयोग से वह शाखा प्रदाता के प्रति वफादार था और उसने " सहकर्मी से सहकर्मी यातायात "मेगाबाइट प्रति 6 kopecks की कीमत के साथ)।

1. छद्म

सबसे तेज़ समाधान प्रॉक्सी सर्वर का सामान्य कैस्केड था, और यह इसलिए किया गया था इससे पहले कि सभी शाखाओं ने इंटरनेट को सीधे अपने मॉडेम को सौंप दिया, सभी के लिए 1 सिस्टम यूनिट आवंटित करना आवश्यक था जो गेटवे के रूप में काम करेगा, सिस्टम इंजीनियर उपहार नहीं थे, जो 800 वें स्टंप देगा, जो सामान्य रूप से 233 देगा, जिनके पास सामान्य रूप से ... हालांकि आज 4- के लिए 7 ट्र आप एक सभ्य प्रवेश द्वार इकट्ठा कर सकते हैं, लेकिन गुरु एक मास्टर है, मैं बिना लागत के कहना चाहता हूं!



इन गेटवे पर Ubuntu 8.04 स्थापित किया गया था। LTS को गेटवे के रूप में कॉन्फ़िगर किया गया है ताकि इसे स्थानीय नेटवर्क में, मॉडेम में और आउटलेट में प्लग किया जाए, और सब कुछ तुरंत काम किया। कई शाखाओं में, उपयोगकर्ता के कीबोर्ड पर प्रवेश केवल "कोई भी कुंजी" दबा सकता है, लेकिन इससे कोई फर्क नहीं पड़ता है, चीजें चली गईं, धीरे-धीरे 7 शाखाओं ने अपने मॉडेम को पुन: कॉन्फ़िगर किया, और अटक गेटवे :)



उन्होंने तुरंत कैस्केड में प्रॉक्सी को उठाया, http ट्रैफ़िक को वहां कर दिया गया था, लेकिन जैसा कि हम सभी जानते हैं, https ट्रैफ़िक कुल ट्रैफ़िक का केवल एक निश्चित% है, सरल टैरिफ पर स्विच करना एक बचत थी, लेकिन सशर्त, क्योंकि लापरवाह व्यवस्थापक या उपयोगकर्ता, उदाहरण के लिए, धार के माध्यम से खींच सकते हैं कुछ महत्वपूर्ण, जिसने पैसे के लिए एक शाखा प्राप्त करने का वादा किया ...



जिस तरह से, केंद्रीय कार्यालय में अन्य कार्य दिखाई दिए - तुलनात्मक डाकिया, प्रवेश द्वार, पोर्टल को वर्ष 2002 में कॉन्फ़िगर किया गया और तब से छुआ नहीं गया, लेकिन यह एक अलग लेख के योग्य है ...

इस बीच, हम सिर्फ नेटवर्क में रुचि रखते हैं ...

2. ओपनवीपीएन

मैंने पहली बार इस चीज को देखा, पहले परिचित का एक निश्चित डर था, फिर मैनुअल और इंटरनेट पढ़ना, मेरी आस्तीन ऊपर लुढ़का, मैं डालने के लिए चढ़ गया :)



2.1 सर्वर

2 नेटवर्क एडेप्टर eth1 (192.168.5.x) - एक विस्तृत चैनल के साथ स्थानीय क्षेत्र नेटवर्क और eth0 (असली आईपी 111.111.111.111) इंटरनेट है।



apt-get install openvpn







इसके बाद, सर्वर कॉन्फ़िगरेशन फ़ाइल बनाएं

touch /etc/openvpn/server.conf







जब सिस्टम बूट होता है, तो सभी वीपीएन कनेक्शन स्वचालित रूप से उठाए जाते हैं जिसके लिए एक्सटेंशन .conf / the / openppn फोल्डर के साथ संबंधित फाइलें होती हैं।



मैं इसे इस तरह मिला।



port 1194 #

proto udp #

dev tun #

ca /etc/openvpn/ca.crt

cert /etc/openvpn/server.crt

key /etc/openvpn/server.key # This file should be kept secret

dh /etc/openvpn/dh1024.pem

server 10.10.10.0 255.255.255.0 # vpn subnet

ifconfig-pool-persist ipp.txt # ip

push "route 192.168.5.0 255.255.255.0" # home

keepalive 10 120

comp-lzo

user nobody

group nogroup

persist-key

persist-tun

status openvpn-status.log

log-append openvpn.log

verb 4

mute 20

client-to-client

client-config-dir /etc/openvpn/ccd #

route 192.168.0.0 255.255.255.0 # 1

route 192.168.1.0 255.255.255.0 # 2









हम एक निर्देशिका बनाते हैं जिसमें व्यक्तिगत क्लाइंट सेटिंग्स संग्रहीत की जाएंगी:



mkdir /etc/openvpn/ccd







अब आपको एन्क्रिप्शन और प्राधिकरण के लिए कुंजी और प्रमाण पत्र बनाने की आवश्यकता है



cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

source ./vars

./clean-all

./build-ca







अब सर्वर के लिए एक प्रमाणपत्र और एक निजी कुंजी बनाएं:



./build-key-server server







हम क्लाइंट के लिए एक कुंजी बनाते हैं (यदि कई क्लाइंट हैं, तो प्रक्रिया को दोहराना होगा):



./build-key client1







प्रत्येक ग्राहक का अपना विशिष्ट नाम (इस मामले में client1) होना चाहिए।



यदि कुछ समय बाद एक नया क्लाइंट बनाया जाता है, तो प्रक्रिया इस तरह दिखाई देगी:



cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

source ./vars

./build-key client2









जनरेट डिफी-हेलमैन पैरामीटर:



./build-dh







हम निर्देशिका / etc / openvpn / में निम्नलिखित फाइलें डालते हैं



* ca.crt

* server.crt

* dh1024.pem

* server.key







फ़ाइल /etc/openvpn/ipp.txt बनाएँ



क्लाइंट मशीन कॉन्फ़िगरेशन फ़ाइल /etc/openvpn/client.conf मुझे कुछ इस तरह मिला



remote 111.111.111.111 1194

client

dev tun

proto udp

resolv-retry infinite # this is necessary for DynDNS

nobind

user nobody

group nogroup

persist-key

persist-tun

ca /etc/openvpn/ca.crt

cert /etc/openvpn/client1.crt

key /etc/openvpn/client1.key

comp-lzo

verb 4

mute 20

redirect-gateway

#show-net-up

verb 4







अब आपको जनरेट की गई क्लाइंट कुंजियों और सर्वर से सर्वर प्राधिकृत प्रमाणपत्र को / etc / openvpn / फ़ोल्डर में कॉपी करने की आवश्यकता है:

* ca.crt

* client1.crt

* client1.key







यदि क्लाइंट 192.168.1.x नेटवर्क छिपा रहा है, तो सर्वर के लिए यह देखने के लिए आपको सर्वर पर इसके लिए एक मार्ग जोड़ने की आवश्यकता है।



सर्वर पर, निम्न सामग्री के साथ फ़ाइल / etc / openvpn / ccd / client1 बनाएँ:



iroute 192.168.1.0 255.255.255.0

# 2, 2

#push "route 192.168.100.0 255.255.255.0"

# OpenVPN

push "redirect-gateway def1"







यहाँ, वास्तव में, सबसे बुरी समस्या मेरे साथ हुई।



OpenVPN निर्देश प्राप्त

push "redirect-gateway def1"





(यदि इसके विन्यास में एक 'पुल' है), ग्राहक पुराने मार्ग को नहीं हटाता है, लेकिन रूटिंग टेबल में प्रविष्टियाँ जोड़ता है:

0.0.0.0/1 via 192.168.231.5 dev tun0

128.0.0.0/1 via 192.168.231.5 dev tun0





और अगर ओपनवॉप ईथरनेट पर चला जाता है तो सब कुछ काम करता है और व्यवस्थापक और उपयोगकर्ताओं को प्रसन्न करता है, लेकिन महान पीपीपी इस तरह के मार्ग को लेना पसंद करता है।

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0







और ओपनवीपीएन इस तरह शपथ लेता है

Jul 2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system







इस समस्या का समाधान लंबे और थकाऊ होने की मांग की गई थी, हालांकि यह सतह पर है। यदि इस "घुमावदार" ppp मार्ग में आप 0.0.0.0 के बजाय एक वास्तविक प्रवेश द्वार का प्रवेश द्वार निर्दिष्ट करते हैं, तो OpenVPN इस मार्ग को देखता है और बिना किसी समस्या के अपना जोड़ता है।



इसलिए मैंने एक फाइल बनाई

/etc/ppp/ip-up.d/routing





जिसमें मैंने एक छोटी स्क्रिप्ट दर्ज की। (मैं आपको अपने पैरों से नहीं मारने के लिए कहता हूं, मैं बहुत आलसी हूं, और गेटवे और संपादन मार्गों को निर्धारित करने के लिए एक पूर्ण स्क्रिप्ट नहीं लिखी, लेकिन इसे एक साधारण बैसाखी की तरह बनाया)

मुझे बहुत खुशी होगी अगर कोई मक्खी पर मार्गों को संपादित करने के लिए अधिक तार्किक, विश्वसनीय और सार्वभौमिक विधि प्रदान करता है।

अब तक, कोई निश्चितता नहीं है कि सब कुछ 100% ppp ब्रेक के साथ काम करेगा, लेकिन जीवन दिखाएगा, अगर कुछ भी, मैं इस विषय को ठीक कर दूंगा।



#! /bin/sh

# 222...

gw1=`ip route show | grep 222 | awk '{print $1}'`

# 0.0.0.0 0.0.0.0

route del default

#

route add -net default gw ${gw1} dev ppp0







हम इसे निष्पादन योग्य बनाते हैं

chmod ug+x /etc/ppp/ip-up.d/routing







जिसके बाद रिबूट, कुछ समय बाद सर्वर ने बाहरी आईपी पर पिंग करना बंद कर दिया, लेकिन आंतरिक पर जवाब देना शुरू किया - 10.10.10.26



PS मैं आपसे यह ध्यान रखने के लिए कहता हूं कि गेटवे और सर्वर और क्लाइंट के फ़ायरवॉल को ठीक किया जाना चाहिए ताकि उपयोगकर्ताओं के पास एक महत्वपूर्ण इंटरनेट हो।

उदाहरण के लिए, मैंने इसे इस तरह किया:

-A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE





बाहरी इंटरफ़ेस या आईपी के लिए कोई बंधन नहीं है :)

जब विभिन्न कारणों से हमारे पास ओपनवॉप नहीं होगा तब उपयोगकर्ताओं के पास एक सीधा इंटरनेट होगा, और जब यह दिखाई देगा, तब सभी ट्रैफ़िक इसके साथ उड़ान भरेंगे।

निष्कर्ष

जीवन में, इस प्रणाली को चरणों में इकट्ठा किया जाता है, पहले वीपीएन सर्वर और वीपीएन क्लाइंट लॉन्च किए जाते हैं, पते 10.10.10.x पर एक दूसरे को पिंग करते हैं फिर सर्वर और क्लाइंट के पीछे आने वाले नेटवर्क के मार्गों को जोड़ा जाता है, पिंग्स की जांच की जाती है जब सब कुछ स्थिर और विश्वसनीय होता है जब हम निर्देश जोड़ते हैं

push "redirect-gateway def1"





और फिर से हम काम और जीवन को प्राप्त करते हैं, सब कुछ कार्यालय छोड़ने के बिना किया गया था, शाखा गेटवे पर, नेटवर्क इंटरफेस पर हस्ताक्षर किए गए थे, ताकि व्यवस्थापक बस नेटवर्क केबलों और पावर में प्लग हो जाए, मुझे फोन किया, और फिर मैंने काम करने के लिए ssh कॉन्फ़िगर किया।

अरे हाँ, मैं लगभग सबसे महत्वपूर्ण बात भूल गया - लाभ

इस तथ्य के अलावा कि अब पूरा नेटवर्क आंतरिक आईपी पते द्वारा शाखाओं और केंद्र के सर्वर और सेवाओं तक पहुंच बना रहा है, वित्तीय बचत भी है।



पहले, प्रत्येक शाखा ने इंटरनेट पर औसतन 7,000 रूबल खर्च किए। प्रति माह, अब प्रति माह उनमें से प्रत्येक 550 रूबल का भुगतान करता है। पियरिंग तक पहुंच के लिए, इंटरनेट का सेवन नहीं किया जाता है (केंद्रीय एक को छोड़कर), शुरुआत के लिए, 7 शाखाएं लॉन्च की गईं, फिर और भी कुछ होगा।

यह पता चला है कि पुरानी योजना के तहत एक वर्ष के लिए, कंपनी इंटरनेट पर 588,000 रूबल खर्च करेगी। , और वर्तमान योजना के साथ, प्रति वर्ष 46,200 रूबल खर्च किए जाएंगे ।

आगे क्या है?

और अब, इस पूरे हे पर ... हम दूर करने की कोशिश करेंगे! मैं शाखाओं के बीच लंबी दूरी की टेलीफोन कॉल की लागत को कम करने के लिए आईपी टेलीफोनी को तैनात करने की कोशिश करूंगा, जिससे सॉफ्टएएस को शाखाओं में हार्डवेयर के साथ जोड़ा जा सके, जिसके बारे में मैं लिखूंगा। सौभाग्य है



अपडेट 1 "बड़ी कंपनी" शब्द के बारे में कई सवाल उठे हैं जिन्हें मैं स्पष्ट करने की कोशिश करूंगा।



यह साइबेरिया में बड़ा है, केंद्र में 200 कर्मचारियों का एक कर्मचारी है, 20 से 60 तक शाखाएं हैं, 10-20 वस्तुएं अभी भी प्रत्येक शाखा से जुड़ी हुई हैं। 5-15 लोग प्रत्येक। शाखाएँ 30 से कम।



कंपनी बहुत चुस्त नहीं है, मुख्य नियंत्रण राज्य से आता है, उपकरण, कंपनी आईटी विकास की दिशा में कुछ कदम उठाती है :)



Update2

और इसलिए, परीक्षण के बाद यह पता चला कि यदि आप लंबे समय तक प्रशासन सर्वर को कम करते हैं, तो क्लाइंट ओपेनवोन के लिए तैयार नहीं हैं और ट्रैफिक सीधे एक महंगे इंटरनेट पर जा सकता है।

इसके अलावा, अगर ADSL चैनल को जबरन फाड़ दिया जाता है, तो खुले सर्वर को फिर से शुरू करने की कोशिश की जा रही है, लेकिन ऐसा कुछ काम नहीं करता है, यह मंडलियों में घूमता है।

मैंने सभी प्रकार के विकल्पों और प्रयत्नशील और पिंग-रिस्टार्ट वगैरह की कोशिश की ... मदद नहीं की ...



इसलिए, हम एक छोटी स्क्रिप्ट लिखते हैं जो मामलों की स्थिति की जांच करेगी।

touch /usr/bin/vpn_keepalive.sh







सामग्री के साथ।



#! /bin/sh

# ,

#debug_out=/dev/null

debug_out=/dev/stdout

#NEXTHOP

# OpenVPN

NEXTHOP=192.168.5.1

#

OPEN_VPN_CMD="sudo /etc/init.d/openvpn restart"

PING=/bin/ping



logger_opts="-t $0"

if [ "$debug_out" = "/dev/stdout" ]

then

logger_opts="$logger_opts -s"

fi

pckts_rcvd=`$PING -c 8 -q -W 2 $NEXTHOP | grep transm | awk '{print $4}'`

echo "host: $NEXTHOP, pckts_rcvd: $pckts_rcvd" >$debug_out

if [ $pckts_rcvd -eq 0 ]

then

echo "Connection with $NEXTHOP lost, resetting" | logger $logopts

$OPEN_VPN_CMD > $debug_out

else

echo "Connection with $NEXTHOP up, no action" | logger $logopts

fi







इसे अमल में लाना

chmod ug+x /usr/bin/vpn_keepalive.sh







स्क्रिप्ट होस्ट को पिंग करता है, और यदि 0 पैकेट वापस किए जाते हैं, तो यह रीस्टार्ट कमांड को निष्पादित करेगा।

जिसके बाद सब कुछ बढ़ने की गारंटी दी जाती है, सही मार्ग प्रवाहित होते हैं और ट्रैफ़िक वीपीएन ट्रैफ़िक से होकर जाता है



हम इस लिपि को मुकुट में पिरोते हैं

crontab -e







उदाहरण के लिए हर 2 मिनट में।

0-59/2 * * * * /usr/bin/vpn_keepalive.sh







और सभी यदि डिबग सक्षम है, तो लॉग (syslog) में इसे इस तरह चिह्नित किया जाएगा।

logger: Connection with 192.168.5.1 up, no action







सौभाग्य है