பதிலில்லாத வெளிச்செல்லும் ESP என்பது VPN இறந்துவிட்டது என்று அர்த்தமல்ல
ESP ஒவ்வொரு இணைப்புக்கும் ஒரு திசையை மட்டும் பாதுகாக்கிறது, எதையும் உறுதிப்படுத்தவில்லை. சேவையகத்தை பதிலளிக்காதது என்று சொல்வதற்கு முன் உள் உரையாடலையும் உள்வரும் SA-வையும் ஒப்பிடுங்கள்.
நீங்கள் IPsec ஹோஸ்டில் டிராஃபிக்கைப் பிடித்தீர்கள், ESP பாக்கெட்டுகள் வெளியேறுவதைப் பார்த்தீர்கள், எதுவும் திரும்பி வருவதைக் காணவில்லை, தொலை பக்கம் பழுதடைந்துள்ளது என்று முடிவு செய்தீர்கள். அந்தப் பிடிப்பு அந்த முடிவுக்கு ஆதரவு தரவில்லை. ESP உரையாடலின் ஒரு திசையை மட்டும் பாதுகாக்கிறது, IP அடுக்கில் எதையும் உறுதிப்படுத்தவில்லை, எனவே திரும்பி வரும் ESP இல்லாதது, பயன்பாட்டுக்குச் சொல்ல எதுவும் இல்லை என்றும் பொருள்படலாம், சுரங்கப்பாதை இறந்துவிட்டது என்றும் பொருள்படலாம். எந்த முனையையும் குறை கூறுவதற்கு முன் உள் பரிமாற்றத்தையும் பெறும் பக்கத்தின் நிலையையும் படியுங்கள்.
கட்டுக்கதை: ஒவ்வொரு பாதுகாக்கப்பட்ட பாக்கெட்டும் ஒரு பதிலைப் பெறுகிறது
ESP என்பது கோரிக்கை-பதில் நெறிமுறை அல்ல. கொள்கை தேர்ந்தெடுப்பதை அது மறையாக்கி அங்கீகரிக்கிறது, பெறுபவர் அந்த உள் பாக்கெட்டை தானே ஒரு பாக்கெட்டை உருவாக்காமல் சரிபார்த்து, மறைகுறியாக்கி, வழங்குகிறார். இலக்கு புறக்கணிக்கும் UDP வினவல், அல்லது உள்வரும் கொள்கை தூக்கி எறியும் ICMP எதிரொலி, இரு திசைகளிலும் அமைதியைச் சரியான விளைவாக உருவாக்குகிறது. அந்த அமைதியைப் போக்குவரத்துத் தோல்வியாகக் கருதுவது, ஒருபோதும் இல்லாத பிணையக் குறையைத் தேட உங்களை அனுப்புகிறது.
ஒரு திசைப் பிடிப்பு உண்மையில் நிரூபிப்பது, அந்தக் கண்காணிப்புப் புள்ளியில் அனுப்புநரின் ஸ்டாக் ஏதோ ஒன்றை மறையாக்கியது என்பதையே. வருகையைப் பற்றி எதுவும் இல்லை, பதிலளிக்கும் நோக்கத்தைப் பற்றியும் எதுவும் இல்லை. பயனுள்ள கேள்வி „பதில் ஏன் இல்லை“ என்பதல்ல, „உள் உரையாடல் என்ன உருவாக்கியிருக்க வேண்டும்“ என்பதே.
இரண்டு SA, இரண்டு SPI, ஒரு உரையாடல்
IPsec பாதுகாப்பு இணைப்புகள் ஒரு திசையானவை, எனவே சாதாரண பாதுகாக்கப்பட்ட பரிமாற்றம் தனித்தனி அடையாளங்களும் சுயாதீன நிலையும் கொண்ட உள்வரும் இணைப்பையும் வெளிச்செல்லும் இணைப்பையும் இயக்குகிறது. வெளிச்செல்லும் பாக்கெட்டின் SPI-க்காக திரும்பி வரும் டிராஃபிக்கைத் தேடுவது எனவே ஒரு வகைப் பிழை, ஏனெனில் எந்தப் பதிலும் துணையின் சொந்த வெளிச்செல்லும் SA-வின் கீழ் அதன் சொந்த SPI-யுடன் பயணிக்கிறது. அதற்குப் பதிலாக டிராஃபிக் தேர்விகளும் துணையின் முகவரிகளும் மூலம் இணையைப் பொருத்துங்கள்.
விசை புதுப்பித்தல் சில வினாடிகளுக்கு படத்தைச் சிக்கலாக்குகிறது, ஏனெனில் பழைய மற்றும் மாற்று நிலை ஒன்றுடன் ஒன்று மேற்பொருந்தலாம். அறிகுறி விசை மாற்றத்தைச் சுற்றி தொடங்கியிருந்தால், இணைப்பின் பெயரை மட்டுமல்ல, இணைப்பு அடையாளங்களையும் நேர முத்திரைகளையும் ஒன்றாகச் சேகரியுங்கள்.
எதுவும் பதிலளிக்கும் முன் பெறுபவர் செய்ய வேண்டியது
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ஒவ்வொரு வரிசையும் தனித்தனியாகத் தோல்வியடைகிறது, ஒவ்வொரு தோல்விக்கும் வேறு உரிமையாளர் உள்ளார், அதனால் ஒரு பிடிப்பு அவற்றை வேறுபடுத்த முடியாது. உள்வரும் எண்ணி மட்டுமே வருகையின் நேரடிச் சான்று, ஏனெனில் அங்கீகாரம் அல்லது மறுநிகழ்வுச் சோதனையில் தோல்வியடையும் பாக்கெட் எந்தப் பதிலும் இல்லாமல் தூக்கி எறியப்படுகிறது. எனவே உள்வரும் எண்ணி நகராத துணை தனது கொள்கையைப் பற்றி உங்களுக்கு எந்தத் தகவலும் தரவில்லை.
வழங்குதல் மறைகுறியாக்கத்திலிருந்து தனி படி. நிலை செல்லுபடியாக இருக்கலாம், பாக்கெட் பின்னர் உள்வரும் கொள்கையால் அல்லது உள் இலக்கை உள்ளடக்காத பாதையால் தூக்கி எறியப்படலாம், எனவே சுத்தமான எண்ணி என்பது பாக்கெட் நீங்கள் விரும்பிய இடத்துக்குச் சென்றது என்று கருதுவதற்குப் பதிலாக இலக்கு ஹோஸ்ட் தெளிவான உரையைப் பார்த்ததா எனச் சரிபாருங்கள்.
இயல்பான ESP என்பது UDP அல்ல
இயல்பான ESP என்பது IP நெறிமுறை 50, இது TCP-யும் அல்ல UDP-யும் அல்ல, அதற்கு போர்ட்டுகள் எதுவும் இல்லை. எனவே UDP 500-ல் IKE-ஐ அனுமதிக்கும் ஃபயர்வால் விதி தரவுப் பாதையைப் பற்றி எதுவும் சொல்லவில்லை, போர்ட்டுகளைச் சுற்றி எழுதப்பட்ட வடிகட்டி சுரங்கப்பாதை பேச்சுவார்த்தை நடத்த அனுமதித்து பின்னர் அதற்குள் எடுத்துச் செல்லப்படும் அனைத்தையும் தூக்கி எறியலாம். தரவுப் பாதையை நீங்கள் உண்மையில் கவனித்த பயன்முறையில் தனியாகச் சோதியுங்கள்.
NAT-க்குப் பின்னால் வடிவம் மாறுகிறது: பாதுகாக்கப்பட்ட சுமை UDP-க்குள் பயணிக்கிறது, பொதுவாக 4500 போர்ட்டில், RFC 3948 வரையறுப்பது போல. எந்த விதியையும் எழுதுவதற்கு முன் செயலில் உள்ள பயன்முறையைப் பதிவு செய்யுங்கள், ஏனெனில் பாதையில் உள்ள சாதனம் இயல்பான ESP-ஐயும் UDP-வில் மூடப்பட்ட ESP-ஐயும் முற்றிலும் வேறுவிதமாகக் கையாளலாம், சில இடைச் சாதனங்கள் ஒன்றை அனுமதித்து மற்றொன்றைத் தூக்கி எறிகின்றன.
இந்தச் சம்பவத்துக்குரிய எண்ணிகளைப் படியுங்கள்
strongSwan ஹோஸ்டில் swanctl --list-sas இரு திசைகளிலும் ஒவ்வொரு இணைப்பின் பாக்கெட் மற்றும் பைட் எண்ணிகளைப் பதிவு செய்கிறது, இது „ஒருபோதும் வரவில்லை“ என்பதை „வந்தது, பதிலளிக்கவில்லை“ என்பதிலிருந்து பிரிக்க போதுமானது. Linux-ல் /proc/net/xfrm_stat இல்லாத நிலை, இல்லாத கொள்கை மற்றும் நெறிமுறை பிழைகள் போன்ற ஒருங்கிணைந்த தோல்விகளை எண்ணுகிறது. அந்த மொத்தங்கள் துவக்கத்திலிருந்து குவிகின்றன, ஒரு பிணையப் பெயர்வெளிக்கு மட்டுமே உரியவை, எனவே பெரிய எண் ஒரு காரணமல்ல.
சரியான பெயர்வெளியில் சம்பவச் சாளரத்தைச் சுற்றி இரண்டு அளவீடுகளை எடுத்து வேறுபாடுகளை ஒப்பிடுங்கள், இல்லையெனில் கடந்த வாரப் பிழைகளை இன்று பிற்பகல் டிக்கெட்டில் சேர்த்துவீர்கள். பெயர்வெளியையும் இரண்டு நேர முத்திரைகளையும் டிக்கெட்டில் இடுங்கள், அடுத்த வாசகர் மொத்தத்தை நம்புவதற்குப் பதிலாக ஒப்பீட்டை மீண்டும் உருவாக்க முடியும்.
நிலையைப் பெயரிடுங்கள், சந்தேக நபரை அல்ல
பயனுள்ள முடிவு பாக்கெட் எங்கு நின்றது என்று சொல்கிறது: ஒருபோதும் பெறப்படவில்லை, பெறப்பட்டுத் தூக்கி எறியப்பட்டது, வழங்கப்பட்டது ஆனால் பதில் இல்லை, அல்லது பதிலளிக்கப்பட்டு திரும்பும் வழியில் தொலைந்தது. இவை ஒவ்வொன்றும் வேறு உரிமையாளரையும் வேறு அடுத்த கட்டளையையும் சுட்டுகின்றன. „VPN சேவையகத்திலிருந்து பதில் இல்லை“ என்பது நான்கு வேறுபட்ட குறைகளை பிடிப்பு ஒருபோதும் நியாயப்படுத்தாத ஒரு வாக்கியமாகச் சுருக்குகிறது.
பிடிப்புகளைக் குறுகலாக வைத்திருங்கள், கர்னலின் மூல நிலையை டிக்கெட்டுகளில் வைக்காதீர்கள், ஏனெனில் அது ஹோஸ்ட்டை விட்டு வெளியேறக்கூடாத விசைப் பொருளைக் கொண்டிருக்கலாம். எண்ணி வேறுபாடுகளும் நேர முத்திரைகளும் அடுத்த நபரிடம் ஒப்படைக்கத் தகுந்த பகுதிகள்.