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

keepalive உங்கள் ஹோஸ்ட் இன்னும் அனுப்பத் தயாராக இருப்பதை நிரூபிக்கிறது. ஒருபோதும் அதன் வழியாகச் செல்லாத பதிலை நிலையை வைத்திருக்கும் சாதனத்திற்குக் காட்ட முடியாது.

கட்டுக்கதை: keepalives அமைதியான துண்டிப்பைச் சரிசெய்கின்றன

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

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

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

கூடுதல் நுழைவாயில் உண்மையில் என்ன செய்கிறது

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

கீழே உள்ள முகவரிகள் அந்த ஏற்பாட்டைப் பிரதிபலிக்கின்றன:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

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

ஒரு வேண்டுமென்றே பாதையைத் தேர்ந்தெடுக்கவும்

மேலே உள்ள ஏற்பாட்டிற்கு, தொலை சப்நெட்டை நேராக VPN நுழைவாயிலுக்கு வழிமாற்றுவது பாதி இணைப்பை நீக்குகிறது:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

இரு முனைகளிலிருந்தும் சோதிக்கவும்

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

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

சமச்சீரற்ற தன்மை எப்போது சரி

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

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

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