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

பதிவைப் படிக்கும் முன் நிகழ்வுக்குப் பெயரிடுங்கள்

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

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

ரோமிங் மற்றும் மறு இணைப்பு வெவ்வேறு நெறிமுறைகள்

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

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

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

சுரங்கப்பாதை வைத்திருக்காத நிலை

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

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

சோதனைகளை வெளியிலிருந்து உள்ளே வரிசைப்படுத்துங்கள்

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

முதல் கட்டளை ஒவ்வொரு சகாவிற்கும் தற்போதைய முடிவுப் புள்ளியையும் கைக்குலுக்கலின் வயதையும் காட்டுகிறது. இரண்டாவதும் மூன்றாவதும் வெளி இடைமுகமும் முடிவுப் புள்ளிக்கான வழித்தடமும் இன்னும் அர்த்தமுள்ளதா எனக் காட்டுகின்றன. conntrack எண்ணிக்கை முந்தைய முகவரியிலிருந்து எஞ்சிய நிலைக்கான கரடுமுரடான சோதனை, ஜர்னல் மறு இணைப்பின் காரணம் பதிவாகும் இடம்.

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

எதிர்பார்க்கப்படும் நடத்தையை முடிவு செய்து எழுதுங்கள்

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

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

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