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

குழுவை உருவாக்கும் முன் தோல்வியைப் பெயரிடுங்கள்

இடையூறின் போது உண்மையாக இருக்க வேண்டிய வாக்கியத்தை எழுதுங்கள். „சுரங்கப்பாதை காப்பு WAN வழியாக மீண்டும் இணைகிறது“ மற்றும் „கிளை இன்னும் மற்ற சுரங்கப்பாதை வழியாகப் பயன்பாட்டை அடைகிறது“ வெவ்வேறு வாக்கியங்கள். முதலில் மட்டுமே போக்குவரத்தைப் பற்றியது.

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

உள்ளூர் WAN: போக்குவரத்தை நகர்த்துங்கள்

pfSense OpenVPN வாடிக்கையாளருக்கு ஆதரவளிக்கப்படும் பல-WAN ஏற்பாடு பொருத்தமான கேட்வே குழுவை வாடிக்கையாளர் இணையும் இடைமுகமாகத் தேர்ந்தெடுக்கிறது. முதன்மையானது தோல்வியுறும்போது வெளிப்புற இணைப்பு காப்பு இணைப்பு வழியாக வெளியேற இது அனுமதிக்கிறது. தானாகவே இது உள்போக்குவரத்து எவ்வாறு வழியமைக்கப்படுகிறது என்பதை மாற்றாது.

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

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

தொலை முனை: வேறு சேவையகம்

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

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

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

சுரங்கப்பாதையின் பாதை: வேறு வெளியேற்றத்தைத் தேர்ந்தெடுங்கள்

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

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

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

கண்காணிப்பிகள், NAT மற்றும் fail-closed விதி

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

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

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

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

தொடர்புடைய கட்டுரைகள்