VPN வாடிக்கையாளர்களும் LAN-ம்: எப்போது தனி மண்டலம் பயன்படுத்த வேண்டும்

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

மண்டலத்தின் பெயர் எதையும் மறையாக்காது, பயனரை அங்கீகரிக்காது. ஃபயர்வால் கொள்கை மாதிரிக்காக இடைமுகங்களை மட்டும் தொகுக்கிறது.

மண்டல உறுப்பினர் நிலை உண்மையில் கட்டுப்படுத்துவது

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

VPN மண்டலத்திலிருந்து LAN மண்டலத்திற்கான அனுமதி தானாகவே எதிர் அனுமதி அல்ல. அனுப்புதல் விதிகள் திசை சார்ந்தவை, வாடிக்கையாளரிலிருந்து சேவையகத்திற்கான போக்குவரத்தை அனுமதிக்கும் விதி சேவையகத்திலிருந்து வாடிக்கையாளருக்கான அமர்வுகளை அனுமதிக்காது. சேவையகத்திற்கு இணைப்பைத் திறக்கக்கூடிய வாடிக்கையாளர், சேவையகம் திரும்ப இணைப்பைத் திறக்கக்கூடிய வாடிக்கையாளர் அல்ல.

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

முதல் முடிவு: உள்ளீடு, அனுப்புதல் அல்லது இரண்டும்

தொலை வாடிக்கையாளர்களுக்கு திசைவியிலிருந்து DNS தேவைப்பட்டால், அந்தச் சேவைக்கு மட்டும் உள்ளீட்டை அனுமதியுங்கள். கோப்பு சேவையகத்தை அடைய வேண்டுமெனில், அந்த இலக்கை நோக்கி அனுப்புதலை அனுமதியுங்கள். பெரும்பாலான VPN வடிவமைப்புகளுக்கு இரண்டும் தேவை, ஆனால் வெவ்வேறு சேவைகளுக்கு.

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

இரண்டாம் முடிவு: தொலை வாடிக்கையாளர்களுக்குத் தேவையான வளங்கள்

விதிகளை எழுதும் முன் வாடிக்கையாளர் வரம்புகள், இலக்குகள், VPN வழங்க வேண்டிய சேவைகளைப் பட்டியலிடுங்கள். இலக்குப் பட்டியல் நம்பிக்கை லேபிளை விடப் பயனுள்ளது, ஏனெனில் அது ஃபயர்வால் இடம்பெயர்வைத் தாண்டி நிற்கும்.

நிர்வாக இடைமுகங்களை சாதாரண பயன்பாட்டு அணுகலிலிருந்து தனியே வையுங்கள். விக்கியை அடையும் தொலை வாடிக்கையாளருக்கு அதனால் திசைவியின் நிர்வாகப் பக்கம் அல்லது ஹைப்பர்வைசர் பணியகம் தேவைப்படாது.

அனுமதிக்கப்பட்ட இலக்கு மேலும் அனுப்ப முடிந்தால், மண்டல எல்லை ஃபயர்வாலிலேயே நிற்கிறது, இலக்கு பிறகு என்ன செய்கிறது என்பதில் அல்ல.

மூன்றாம் முடிவு: எல்லையை எப்படி நிரூபிப்பீர்கள்

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

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

வலையமைப்பு வளரும்போது உறுப்பினர் நிலையையும் விதிகளின் நோக்கத்தையும் ஆவணப்படுத்துங்கள். யாரோ வசதியான மண்டலப் பெயரைக் கொடுத்ததால் மட்டும் புதிதாக இணைக்கப்பட்ட இடைமுகம் சிறப்புரிமைகளை வாரிசாகப் பெறக்கூடாது.