ACK பாக்கெட்டில் conntrack NEW: அது எதை நிரூபிக்காது

NEW என லேபிளிடப்பட்ட ACK என்பது டிராக்கருக்கு பொருந்தும் நிலை இல்லை என்பதே, VPN ஒரு அமர்வைத் திறந்தது என்று அல்ல. hook, tuple மற்றும் பிடிப்பு சாளரத்தைப் படியுங்கள்.

ஃபயர்வால் பதிவில் நீங்கள் எதிர்பார்க்காத ஒரு வரி உள்ளது: ஒரு ACK பாக்கெட், conntrack நிலை NEW, உங்களுடையது அல்லாத மூல முகவரி, இலக்கு துறைமுகம் திறந்துள்ளது. யாரும் அனுமதிக்காத புதிய உள்வரும் இணைப்பாக இதைப் படிக்கத் தூண்டுகிறது. வரி உண்மையில் சொல்வது மிகவும் குறுகியது: அந்த பாக்கெட் இந்த hook ஐ அடைந்தபோது டிராக்கருக்கு பொருந்தும் எந்த நிலையும் இல்லை, மேலும் பாக்கெட் ACK ஐ எடுத்துச் சென்றது. இவை இரண்டு வெவ்வேறு விஷயங்களைப் பற்றிய இரண்டு உண்மைகள், எதுவும் முழுமையான கைக்குலுக்கல் பதிவு அல்ல. முடிவுக்கு வரும் முன் நான் பின்பற்றும் வரிசை இதுவே.

தீர்ப்பில் இருந்து அல்ல, பாக்கெட்டில் இருந்து தொடங்குங்கள்

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

இந்த மூன்றையும் கலப்பதே ACK “வழங்குநர் யாரையோ உள்ளே விடுத்தார்” ஆக மாறும் வழி.

hook இல் NEW உண்மையில் எதைக் குறிக்கிறது

iptables conntrack பொருத்தம் NEW ஐ இணைப்பைத் தொடங்கும் பாக்கெட்டாகவோ, இரு திசைகளிலும் போக்குவரத்தை இன்னும் காணாத இணைப்புடன் தொடர்புடைய பாக்கெட்டாகவோ ஆவணப்படுத்துகிறது. ESTABLISHED என்பது டிராக்கர் இரு திசைகளிலும் பாக்கெட்டுகளைக் கண்டுள்ளது என்பதாகும். எந்த வரையறையும் பாக்கெட் SYN என்பதையோ, அது வரலாறு இல்லாமல் வந்ததையோ கூறவில்லை.

ஓட்டத்தை நடுவில் இருந்து கவனிக்கத் தொடங்கும் டிராக்கர் அடுத்த பாக்கெட்டைத் தனக்குத் தெரிந்தவற்றின் அடிப்படையில் வகைப்படுத்தும், அது எதுவும் இல்லாமலும் இருக்கலாம். இது டிராக்கரின் நினைவகத்தைப் பற்றிய கூற்று, தொலைவில் உள்ள ஹோஸ்டின் நோக்கம் பற்றியது அல்ல.

தளர்வான கண்காணிப்பு பெரும்பாலான ACK ஆச்சரியங்களை விளக்குகிறது

கர்னல் ஆவணப்படுத்துகிறது nf_conntrack_tcp_loose, இது டிராக்கருக்குத் தொடக்கத்தைக் காணாத TCP இணைப்புகளை எடுத்துக்கொள்ள அனுமதிக்கிறது. அமைப்பு அதன் இயல்புநிலை மதிப்பில் இருக்கும்போது, ஓட்டத்தின் நடுவிலிருந்து வரும் ACK நிறுவப்பட்ட ஓட்டமாக ஏற்கப்படலாம். அதை அணைத்தால் அதே பாக்கெட் NEW க்கு பதிலாக INVALID என வகைப்படுத்தப்படும் வாய்ப்பு அதிகம். இரண்டு முடிவுகளும் டிராக்கரின் விதிகளை விவரிக்கின்றன, பயன்பாட்டின் வரலாற்றை அல்ல.

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

சலிப்பான காரணங்களை இந்த வரிசையில் விலக்குங்கள்

நான் பின்தொடர்ந்த NEW-on-ACK நிகழ்வுகளில் பெரும்பாலானவை இவற்றில் ஒன்றில் முடிந்தன, அனைத்தையும் சரிபார்ப்பது மலிவானது:

  • conntrack அட்டவணை காலி செய்யப்பட்டது, அல்லது டிராக்கர் மீண்டும் தொடங்கப்பட்டது.
  • ஹோஸ்ட் மீண்டும் இயக்கப்பட்டது, அல்லது ஓட்டம் வேறு namespace அல்லது சாதனத்திற்கு மாறியது.
  • சமச்சீரற்ற வழிமாற்றம் SYN ஐ நீங்கள் பிடிக்காத பாதையில் அனுப்பியது.
  • NAT tuple ஐ மீண்டும் எழுதியது, எனவே பதிவு இனி நீங்கள் படித்ததுடன் பொருந்தாது.
  • பிடிப்பு தாமதமாகத் தொடங்கியது, தொடக்கத்தை ஒருபோதும் காணவில்லை.

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

தொடர்வதற்கு முன் இவற்றில் எதை விலக்கினீர்கள், எப்படி என்பதை எழுதுங்கள்.

tuple, இடைமுகம் மற்றும் hook ஐப் படியுங்கள்

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

ஒரே ஓட்டத்தின் இரண்டு முரணான பார்வைகள் எதையும் விட அதிக தகவலைத் தருகின்றன.

எப்போது மேலெழுப்புவது மதிப்புள்ளது

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

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

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