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

ஒரு வழித்தடத்தைத் தொடுவதற்கு முன் இரண்டு தாவல்களையும் வரையவும்

ஒரு எடுத்துக்காட்டு அமைப்பை எடுத்துக்கொள்ளுங்கள்: LAN புரவலர்கள் 192.168.50.0/24 இல், சாதாரண திசைவி 192.168.50.1 இல், தனி வாடிக்கையாளர் 192.168.50.15 இல், மற்றும் தொலை LAN 10.60.0.0/24 இல், அது அந்த வாடிக்கையாளர் வைத்திருக்கும் சுரங்கப்பாதை வழியாக மட்டுமே அணுகக்கூடியது. இரண்டு தனியார் வரம்புகளில் ஒன்றும் மற்றொன்றுடன் ஒன்றிணைவதில்லை, மற்றும் சுரங்கப்பாதைக்கு அதன் சொந்த முகவரித் திட்டம் உள்ளது.

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

படி 1: திசைவியை சுரங்கப்பாதைக்கு அல்ல, வாடிக்கையாளரை நோக்கித் திருப்பவும்

LAN திசைவியில், அடுத்த தாவல் வாடிக்கையாளரின் LAN முகவரியாக இருக்கும் ஒரு இலக்கு வழித்தடத்தைச் சேர்க்கவும்:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

அந்தப் பதிவு “சுரங்கப்பாதை செய்யக்கூடிய இயந்திரத்திற்கு அதை ஒப்படை” என்று கூறுகிறது. சுரங்கப்பாதை எவ்வாறு கட்டப்படுகிறது என்பதைப் பற்றி எதுவும் கூறவில்லை, மேலும் அது வாடிக்கையாளரின் சொந்த வழித்தடத்திற்கு மாற்றாகாது. நிர்வகிக்கப்பட்ட திசைவியில் சமமானது சாதனத்தின் நிலையான வழித்தடப் பக்கத்தில் வாழ்கிறது; Linux திசைவியில் அது LAN ஐக் கொண்ட இடைமுகத்தின் உள்ளமைவுக்குச் சொந்தமானது, நீங்கள் மூடப்போகும் ஷெல்லுக்கு அல்ல.

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

படி 2: சுரங்கப்பாதைப் பக்கத்தில் வாடிக்கையாளருக்கு அதன் சொந்த வழித்தடத்தைக் கொடுக்கவும்

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

எதையும் சேர்ப்பதற்கு முன் பாருங்கள்:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

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

படி 3: முன்னனுப்பலை அனுமதித்து திரும்பும் பாதையைத் தேர்ந்தெடுக்கவும்

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

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

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

படி 4: இரண்டு முடிவுகளையும் நிலையானதாக்கி, பின்னர் உண்மையான பாதையைச் சோதிக்கவும்

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

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

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

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