ஒரு OpenVPN ஹப், மூன்று LAN: முகவரி திட்டம் மற்றும் iroute கோப்புகள்

மூன்று தனியார் LAN-கள் எந்தத் தளமும் மற்றவற்றின் உள் கட்டமைப்பை அறியத் தேவையில்லாமல் ஒரு ஹப்பில் சந்திக்க முடியும், மேலும் முழு வடிவமைப்பும் நான்கு சிறிய கட்டமைப்பு முடிவுகளில் நிற்கிறது. இதைச் செயல்படுத்துவது ஒரு அசாதாரண நெறிமுறை அம்சம் அல்ல, மாறாக யாரும் ஊகிக்கத் தேவையில்லாத முகவரி திட்டமும், எந்தக் கிளை எந்த முன்னொட்டைக் கொண்டுள்ளது என்று ஹப்புக்குச் சொல்லும் வாடிக்கையாளர் வாரியான பாதைகளும் ஆகும். இவற்றில் ஒன்று தவறாக இருந்தாலும் சுரங்கப்பாதை இன்னும் எழும், அதுவே தோல்வியைக் குழப்பமாக்குகிறது.

படிகளை வரிசையாகச் செய்யுங்கள். ஒவ்வொரு படியும் முந்தைய படியின் திட்டத்தைச் சார்ந்துள்ளது, எதற்கும் புதிய சான்றிதழ் அதிகாரம் தேவையில்லை.

யாரும் ஊகிக்கத் தேவையில்லாத திட்டத்தில் தொடங்குங்கள்

கட்டமைப்பு கோப்பைத் தொடுவதற்கு முன் நான்கு பிரிக்கப்பட்ட முன்னொட்டுகளை எழுதுங்கள்: ஹப்பின் சொந்த LAN, ஒவ்வொரு கிளையின் LAN, மற்றும் அலைந்து திரியும் வாடிக்கையாளர்களுக்கு வழங்கப்படும் குளம். பிரிப்பே மற்ற அனைத்தையும் எளிமையாக வைத்திருக்கிறது, ஏனெனில் ஒன்றோடொன்று மேலெழும் வரம்புகள் வழிமாற்றத்தை நீண்ட பொருத்தத்தின் புதிராக மாற்றும், அதை எந்த வாடிக்கையாளர் வாரியான கட்டமைப்பும் சரிசெய்யாது. பின்னர் ஒவ்வொரு LAN-க்கும் எந்த இயந்திரம் இயல்புநிலை நுழைவாயில் என்பதை உறுதிசெய்யுங்கள், ஏனெனில் தன் LAN-இன் நுழைவாயில் இல்லாத கிளை ரவுட்டர் தொலை பாதைகளை முற்றிலும் வேறு இடத்தில் நிறுவ வேண்டும். இறுதியாக, ஒவ்வொரு கிளையையும் அடையாளம் காட்டும் அங்கீகரிக்கப்பட்ட பெயர்களை நிர்ணயியுங்கள், ஏனெனில் அந்தப் பெயர்களே வாடிக்கையாளர் வாரியான கோப்புகள் தேடப்படும் சாவிகள்.

ஒரு எடுத்துக்காட்டு திட்டம் குளத்தை மூன்று LAN-களிலிருந்து வெகு தொலைவில் வைத்திருக்கிறது. உங்களுடையது வேறுபடும், ஒரே கடினமான விதி எந்த இரண்டு வரம்புகளும் மேலெழக்கூடாது என்பதே.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

கிளைகள் எங்கே உள்ளன என்று ஹப்பின் கர்னலுக்குச் சொல்லுங்கள்

ஹப்புக்கு ஒவ்வொரு கிளைக்கும் இரண்டு தகவல்கள் தேவை: முன்னொட்டைச் சுரங்க சாதனத்திற்கு அனுப்பும் கர்னல் பாதை, மற்றும் iroute பதிவு, அதாவது எந்த வாடிக்கையாளர் அதைக் கொண்டுள்ளது என்று OpenVPN செயல்முறைக்குச் சொல்லும் பதிவு. கர்னல் பாதை மட்டும் பாக்கெட்டுகளைச் சுரங்கப்பாதைக்குக் கொண்டு சென்று அங்கேயே நிற்கிறது, ஏனெனில் டீமன் எந்தப் பியர் அவற்றைப் பெற வேண்டும் என்று இன்னும் முடிவு செய்ய வேண்டும். iroute பதிவு மட்டும் அந்தப் பாக்கெட்டுகளைப் பின்பற்ற எந்தப் பாதையும் இல்லாமல் கர்னலிலேயே விட்டுவிடுகிறது. இரண்டு வரிகளும் டீமன் உண்மையில் ஏற்றும் கட்டமைப்பிற்குச் சொந்தமானவை, வேறு எதையும் பிழைதிருத்துவதற்கு முன் அதைச் சரிபார்ப்பது மதிப்புள்ளது.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

கர்னல் விதிகளைச் செயல்படுத்தும் இடமாக இருக்க வேண்டியிருக்கும் போது client-to-client-ஐ அணைத்து வைத்திருங்கள். அந்த விருப்பம் பியர்களுக்கு இடையிலான போக்குவரத்தை டீமனுக்குள் அனுப்புகிறது, இது வசதியானது மேலும் உங்கள் அனுப்பல் விதிகள் அந்த ஓட்டத்தை ஒருபோதும் காணாது என்பதையும் குறிக்கிறது. கீழேயுள்ள அனைத்தும் கர்னல் ஒவ்வொரு கிளை இடை பாக்கெட்டையும் காண்கிறது என்று கருதுகிறது.

ஒவ்வொரு கிளைக்கும் தேவையான பாதைகளைக் கொடுங்கள்

ஒவ்வொரு கிளைக்கும் மற்ற கிளைகளுக்கும் ஹப்பின் LAN-க்கும் பாதைகள் தேவை, தன் இணைக்கப்பட்ட LAN-க்கு பாதை தேவையில்லை. தொலை முன்னொட்டுகளை ஒவ்வொரு ரவுட்டரிலும் ஒட்டுவதற்குப் பதிலாக ஹப்பிலிருந்து தள்ளுங்கள், அப்போது நான்காவது தளம் பின்னர் நான்கு திருத்தங்களுக்குப் பதிலாக ஒரு புதிய வாடிக்கையாளர் வாரியான கோப்பாக இருக்கும். வாடிக்கையாளர் வாரியான கோப்பில் iroute வரியும் உள்ளது, இது உரிமையையும் விளம்பரத்தையும் ஒரே இடத்தில் வைத்திருக்கிறது. சேவையகத்தின் சிறப்புரிமை மாதிரியின்படி அடைவையும் அதன் கோப்புகளையும் படிக்கக்கூடியதாக்குங்கள், இல்லையெனில் தேடல் செய்தி இல்லாமல் தோல்வியடையும்.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

நான்காவது தளமும் அதே முறையைப் பின்பற்றுகிறது: தனி அங்கீகரிக்கப்பட்ட பெயர், சொந்தமான முன்னொட்டு, ஹப்பில் கர்னல் பாதை, iroute பதிவு, மற்றும் அதை அடைய அனுமதிக்கப்பட்ட தளங்களுக்கு மட்டுமே விளம்பரங்கள்.

முடிந்தது எனச் சொல்வதற்கு முன் இரு திசைகளிலும் சோதியுங்கள்

மூன்று ரவுட்டர்களிலும் IPv4 அனுப்பலை இயக்கி, பின்னர் ஃபயர்வால் நோக்கமான ஓட்டங்களை இரு திசைகளிலும் அனுமதிக்கிறதா என்பதை உறுதிசெய்யுங்கள், ஏனெனில் ஒரு-திசைச் சோதனை உடைந்த திரும்பும் பாதையுடன் யாரும் எதிர்பார்ப்பதை விட அதிகமாகத் தேர்ச்சி பெறுகிறது. தளங்களுக்கு இடையே மூல முகவரி மொழிபெயர்ப்பு தேவையில்லை, அசல் மூலத்தைப் பாதுகாப்பதே ஒவ்வொரு கிளையும் ஒரு கோரிக்கைக்கு அதன் சொந்தக் கொள்கையைப் பயன்படுத்த அனுமதிக்கிறது.

ஒரு கிளை LAN-இன் ஹோஸ்ட்டிலிருந்து இன்னொன்றின் சேவைக்குச் சோதியுங்கள், பின்னர் திசையைத் திருப்புங்கள், பின்னர் கிளையிலிருந்து ஹப்பின் LAN-க்குச் சோதியுங்கள். அந்த மூன்று முடிவுகளும் வெவ்வேறு சான்றுகள், எதுவும் மற்றவற்றைக் குறிக்கவில்லை. கிளை ரவுட்டர் தன் LAN-இன் இயல்புநிலை நுழைவாயில் இல்லையெனில், உண்மையான நுழைவாயிலில் தொலை முன்னொட்டுகளை நிறுவி, சுரங்க வாடிக்கையாளர்கள் அந்த LAN-க்குள் இணைப்புகளைத் தொடங்க வேண்டியிருக்கும் போது குளத்தையும் சேர்க்கவும்.

திட்டம், வாடிக்கையாளர் வாரியான கோப்புகள் மற்றும் ஃபயர்வால் விதிகளை ஒரே ஆவணமாகப் பதிவு செய்யுங்கள், ஏனெனில் அடுத்த தளச் சேர்ப்பு அவற்றின் அடிப்படையில் மதிப்பிடப்படும்.

ஒவ்வொரு அடுக்குக்கும் ஒரே வேலை இருப்பதால் வடிவமைப்பு ஒன்றாக நிற்கிறது: திட்டம் முன்னொட்டுகளைத் தனித்துவமாக வைத்திருக்கிறது, கர்னல் பாதை பாக்கெட்டுகளை நகர்த்துகிறது, iroute உரிமையாளரைப் பெயரிடுகிறது, ஃபயர்வால் எது அனுமதிக்கப்படுகிறது என்பதை முடிவு செய்கிறது. ஏதாவது உடைந்தால், அந்தப் பட்டியலே சரிபார்ப்பு வரிசையாகவும் இருக்கும்.