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 માટે જે લોગ કર્યું તેની સાથે સરખામણી કરો.

એક પ્રવાહના બે વિરોધાભાસી દૃશ્યો દરેક એકલા કરતાં વધુ માહિતી આપે છે.

ક્યારે એસ્કલેટ કરવું યોગ્ય છે

જ્યારે તમે એવી સેવા દેખાડી શકો જે પહોંચમાં છે અને ન હોવી જોઈએ, સાથે પ્રવાહ, તેને મંજૂરી આપનારી નીતિ અને બંને છેડાના પુરાવા, ત્યારે એસ્કલેટ કરો. એક સ્ટેટ લેબલ કે એક આંશિક કૅપ્ચરના આધારે પ્રોવાઇડરની ખામીની જાણ કરશો નહીં, કારણ કે તે જાણ તમે હમણાં વાંચેલી સમજૂતીથી બંધ કરવામાં આવશે. જો સેવા ખરેખર ખુલ્લી હોય, તો તે સીમાનો માલિક જ તેને સુધારવાનો યોગ્ય વ્યક્તિ છે, અને બગ કરતાં સોંપાયેલ પોર્ટ મેપિંગ કે અનિચ્છિત શ્રોતા વધુ સંભવિત કારણ છે.

પછી તે દૃશ્યતાની ખાલી જગ્યા બંધ કરો જેને કારણે એક પેકેટ આખા સેશન જેવું લાગ્યું.

સંબંધિત લેખો