LAN சேவையகத்தில் VPN வாடிக்கையாளர்: பதில்கள் தவறான வழியில் செல்வது ஏன்

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

பதில் ஒரு புதிய பொதி, வழியின் தலைகீழ் பயணம் அல்ல

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

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

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

பதிவு மற்றும் தேடல் மூலம் அதை நிரூபியுங்கள்

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

சுரங்கப்பாதையை மிஞ்சும் மிகக் குறுகிய வழியை நிறுவுங்கள்

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

இரண்டாவது add க்குப் பதிலாக replace ஐப் பயன்படுத்துங்கள், ஏனெனில் மீண்டும் இணையும் வாடிக்கையாளர் ஏற்கனவே தன் உள்ளீட்டை நிறுவியிருப்பார், இரண்டாவது add அனுமதிப் பிரச்சினை போலப் படிக்கப்படும் ஏற்கனவே உள்ள வழிப் பிழையால் தோல்வியடைகிறது. Windows புரவலனில் சமமானது route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, அங்கு -p மீள் இயக்கங்களுக்கிடையே உள்ளீட்டை வைத்திருக்கிறது, சுரங்கப்பாதை மீண்டும் எழும்போது வாடிக்கையாளர் அட்டவணையை மீண்டும் கட்டலாம். தற்கால Windows புரவலனில் ஆதரிக்கப்படும் சமமானது New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, பழைய route கட்டளை பழைய வடிவமாக வைக்கப்படுகிறது.

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

மீண்டும் இணைந்த பிறகும் பதிலை வைத்திருங்கள்

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

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

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