IPsec மேல் தரவுத்தள வினவல் தொங்குகிறது: UDP மறுவரிசை அல்லது TCP?
தூய்மையான handshake-க்குப் பின் தொங்கும் வினவல் சுரங்கப்பாதையின் உள்ளே சுட்டிக்காட்டுகிறது. பாதையைச் சரிசெய்வதா அல்லது 443 இல் TCP-க்குத் திரும்புவதா என்பதை மூன்று நிபந்தனைகள் தீர்மானிக்கின்றன.
TCP handshake-க்குப் பின் தொங்கும் வினவல் வழித்தடப் பிரச்சினை அல்ல. பாதைக் கோளாறுகள் handshake-ஐ தோல்வியாக்கும், எனவே நிறுவப்பட்டு பின்னர் அமைதியாகும் அமர்வு பாதையின் உள்ளே சுட்டிக்காட்டுகிறது: ஆய்வு, MTU, அல்லது சுரங்கப்பாதையின் UDP பாக்கெட்டுகள் வரும் விதம். உங்கள் முன் உள்ள முடிவு அந்தப் பாதையைச் சரிசெய்வதா அல்லது சுரங்கப்பாதையை TCP-க்கு மாற்றுவதா. மூன்று நிபந்தனைகள் அதைத் தீர்மானிக்கின்றன, அவற்றில் ஒன்றும் தரவுத்தளம் பற்றியது அல்ல.
சுரங்கப்பாதையைக் குறை கூறுவதற்கு முன் தொங்கலை வகைப்படுத்துங்கள்
நான்கு முடிவுகள் பயனருக்கு ஒரே மாதிரி தெரிகின்றன, பொறியாளருக்கு முற்றிலும் வேறு பொருள் தருகின்றன.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
கடைசி இரண்டு வரிகளை மட்டுமே சுரங்கப்பாதையில் நேரம் செலவிடுவதை நியாயப்படுத்துகிறது. VPN வழியாக மறுக்கப்பட்ட இணைப்பு பொதுவாக தரவுத்தளம் loopback-ல் மட்டும் கேட்பதாகும், இது கேட்பவர் பிரச்சினை, மேலும் handshake-க்கு முன் நேரம் முடிவது வடிகட்டி அல்லது பாதை. இரண்டும் காப்சுலேஷனை மாற்றுவதால் மேம்படாது.
வகைப்படுத்தலை முதலில் டிக்கெட்டில் எழுதுங்கள். இது மலிவான படி, தேடல் இடத்தின் பெரும்பகுதியை நீக்குகிறது.
UDP மற்றும் TCP இடையே தீர்மானிக்கும் மூன்று நிபந்தனைகள்
காப்சுலேட் செய்யப்பட்ட IPsec போக்குவரத்து UDP-ல் செல்கிறது, UDP பாதைக்கு யாருக்கும் சொல்லாமல் மறுவரிசைப்படுத்தவும் கைவிடவும் சுதந்திரம் தருகிறது. மறுவரிசைப்படுத்தல் பாக்கெட்டுகளை சுரங்கப்பாதையின் மறுதொடர் தடுப்பு சாளரத்திற்கு வெளியே தள்ளும்போது, அவை அமைதியாக நீக்கப்படுகின்றன, உள்ளேயுள்ள TCP அமர்வு வெறுமனே காத்திருக்கிறது. வெற்றிகரமான handshake மற்றும் ஒருபோதும் திரும்பாத வினவலுக்குப் பின்னால் உள்ள பொறிமுறை இதுவே.
பாதையைச் சரிசெய்வது அல்லது TCP-க்குத் திரும்புவது மூன்று விஷயங்களைப் பொறுத்தது. முதலில், பாதையில் உண்மையான பாக்கெட் இழப்பு உள்ளதா அல்லது மறுவரிசை மட்டுமா? இரண்டாவது, ஆய்வு நடக்கும் இடத்தை மாற்ற முடியுமா, அல்லது இந்தச் சுரங்கப்பாதையை மறுவரிசைப்படுத்தும் கூறிலிருந்து விலக்க முடியுமா? மூன்றாவது, பணிச்சுமை தொங்கல் முறைக்கு உணர்திறன் உள்ளதா, உதாரணமாக ஒரு இணைப்பைப் பகிரும் பல மல்டிபிளக்ஸ் அமர்வுகள்?
முதல் பதில் இழப்பாகவும் இரண்டாவது இல்லை என்றும் இருந்தால்,443 இல் TCP நடைமுறை மாற்று. இரண்டாவது பதில் ஆம் என்றால், பாதையைச் சரிசெய்து UDP-ஐ வைத்திருங்கள்.
பயன்பாட்டு பிழையை அல்ல, ஃபயர்வால் பதிவைப் படியுங்கள்
பயன்பாடு நேரம் முடிவதைத் தெரிவிக்கிறது, அது காரணம் பற்றி எதுவும் சொல்லாது. ஃபயர்வாலின் சொந்த பதிவே கைவிடல் அல்லது தடுப்பு தோன்றும் இடம், எனவே தரவுத்தளம் மற்றும் பயன்பாட்டு முகவரிகளால் வடிகட்டி ஏற்புகளுடன் கைவிடல்களையும் தேடுங்கள்.அச்சுறுத்தல் தடுப்பு பிளேடுகள் பயன்பாட்டு நிலையில் பிழையை உருவாக்காமல் பாக்கெட்டுகளைக் கைவிடலாம், அதுவே தொங்கும் வினவலின் சரியான வடிவம். பதிவில் அமைதியும் தகவலே: அது பதிவு செய்யாத ஒன்றை, உதாரணமாக மறுவரிசையைச் சுட்டிக்காட்டுகிறது.
கிளஸ்டரையும் சரிபார்க்கவும். தவறாக உள்ளமைக்கப்பட்ட கிளஸ்டர் ஒரு உறுப்பினரின் நிலை அட்டவணையில் அமர்வை வைத்திருக்க முடியும், பாக்கெட்டுகள் மற்றொரு உறுப்பினரின் பாதையில் செல்லும், எனவே நிலை இல்லாத இடத்திற்கு பதில்கள் வரும். அத்தகைய தொங்கல்கள் சீரற்றதாகத் தெரிகின்றன, சுமையுடன் தொடர்பில்லை.
எதையும் மாற்றுவதற்கு முன் இரு முனைகளையும் ஒப்பிடுங்கள், பாக்கெட் எண்ணிக்கையல்ல வருகை வரிசையை ஒப்பிடுங்கள்:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap443 இல் TCP உண்மையில் உங்களுக்கு எதைச் செலவாக்குகிறது
சுரங்கப்பாதையை TCP-க்கு மாற்றுவது மறுவரிசை அறிகுறியை நீக்குகிறது, ஏனெனில் இடைநிலைப் பெட்டி இப்போது ஒழுங்கான ஓட்டத்தைப் பார்க்கிறது. அது TCP-over-TCP-ஐயும் உருவாக்குகிறது. வெளி இணைப்பு உள் இணைப்பு ஏற்கனவே மீண்டும் அனுப்பியதை மீண்டும் அனுப்புகிறது, ஒரு இழப்பு ஒரே நேரத்தில் அனைத்து மல்டிபிளக்ஸ் அமர்வுகளையும் நிறுத்தலாம். தூய்மையான பாதையில் இது கண்ணுக்குத் தெரியாது. இழப்புள்ள பாதையில் மருந்து அறிகுறியை விட மோசம்.
மாற்று வழி இணைப்பின்மையாக இருக்கும்போது இந்தப் பரிமாற்றம் ஏற்கத்தக்கது, அதை இயல்பாக உள்வாங்குவதற்குப் பதிலாக உரிமையாளருடன் விதிவிலக்காகப் பதிவு செய்ய வேண்டும்.
போக்குவரத்து, துறைமுகம், மாதிரி வினவல் மற்றும் அளந்த முடிவு, மேலும் தேதியைப் பதிவு செய்யுங்கள். அந்தப் பதிவு இல்லாமல் அடுத்த பொறியாளர் பரிசோதனையை மீண்டும் செய்கிறார், விதிவிலக்கு அமைதியாகக் கட்டமைப்பாகிறது.
முடிவை மறுபரிசீலனை செய்யக்கூடியதாக வைத்திருங்கள்
பாதை நோயறிதல் விரைவில் பழையதாகிறது. இடைநிலைப் பெட்டி மாற்றப்படுகிறது, பிளேடு உள்ளமைவு மாறுகிறது, இணைப்பு மேம்படுத்தப்படுகிறது, 443 இல் TCP-க்கான காரணம் மறைந்துவிடுகிறது ஆனால் உள்ளமைவு நிலைத்திருக்கிறது. விதிவிலக்குக்கு மறுபரிசீலனை தேதி வையுங்கள், UDP-க்குத் திரும்ப அனுமதிக்கும் நிபந்தனையைப் பெயரிடுங்கள்.
சிறிய வினவல் மற்றும் பெரிய முடிவுத் தொகுப்புடன் இரண்டு போக்குவரத்துகளையும் சோதியுங்கள். மறுவரிசை அளவைச் சார்ந்த தொங்கல்களாகத் தெரிகிறது, கேட்பவர் கோளாறு இரு அளவுகளையும் சமமாக நிறுத்துகிறது.