ટિપ્પણીનો વિગતવાર પ્રતિસાદ, તેમજ રશિયન ફેડરેશનમાં પ્રદાતાઓના જીવન વિશે થોડું

મને આ પોસ્ટ માટે પ્રોમ્પ્ટ આ ટિપ્પણી છે.

હું તેને અહીં ટાંકું છું:

કાલેમેન આજે 18:53 વાગ્યે

હું આજે પ્રદાતાથી ખુશ હતો. સાઇટ બ્લોકિંગ સિસ્ટમના અપડેટ સાથે, તેના મેઇલર mail.ru પર પ્રતિબંધ મૂકવામાં આવ્યો હતો. હું સવારથી તકનીકી સપોર્ટને કૉલ કરું છું, પરંતુ તેઓ કંઈપણ કરી શકતા નથી. પ્રદાતા નાના છે, અને દેખીતી રીતે ઉચ્ચ-ક્રમાંકિત પ્રદાતાઓ તેને અવરોધિત કરે છે. મેં બધી સાઇટ્સના ઉદઘાટનમાં મંદી પણ નોંધ્યું છે, કદાચ તેઓએ અમુક પ્રકારની કુટિલ ડીએલપી ઇન્સ્ટોલ કરી છે? પહેલાં ઍક્સેસ સાથે કોઈ સમસ્યા ન હતી. રુનેટનો વિનાશ મારી નજર સામે જ થઈ રહ્યો છે...

હકીકત એ છે કે એવું લાગે છે કે આપણે તે જ પ્રદાતા છીએ :)

અને ખરેખર, કાલેમેન મેં લગભગ mail.ru સાથે સમસ્યાઓના કારણનો અંદાજ લગાવ્યો હતો (જોકે અમે લાંબા સમયથી આવી વસ્તુમાં વિશ્વાસ કરવાનો ઇનકાર કર્યો હતો).

નીચેનાને બે ભાગમાં વહેંચવામાં આવશે:

1. mail.ru સાથેની અમારી વર્તમાન સમસ્યાઓના કારણો અને તેમને શોધવાની આકર્ષક શોધ
2. આજની વાસ્તવિકતાઓમાં ISP નું અસ્તિત્વ, સાર્વભૌમ રુનેટની સ્થિરતા.

mail.ru સાથે સુલભતા સમસ્યાઓ

ઓહ, તે ખૂબ લાંબી વાર્તા છે.

હકીકત એ છે કે રાજ્યની આવશ્યકતાઓને અમલમાં મૂકવા માટે (બીજા ભાગમાં વધુ વિગતો), અમે પ્રતિબંધિત સંસાધનોને ફિલ્ટર કરવા અને અમલીકરણ માટે બંને - કેટલાક સાધનો ખરીદ્યા, ગોઠવ્યા અને ઇન્સ્ટોલ કર્યા. NAT અનુવાદો સબ્સ્ક્રાઇબર્સ

થોડા સમય પહેલા, અમે આખરે નેટવર્ક કોરને એવી રીતે પુનઃબીલ્ડ કર્યું કે તમામ સબ્સ્ક્રાઇબર ટ્રાફિક આ સાધનોમાંથી સખત રીતે યોગ્ય દિશામાં પસાર થાય.

થોડા દિવસો પહેલા અમે તેના પર પ્રતિબંધિત ફિલ્ટરિંગ ચાલુ કર્યું (જૂની સિસ્ટમ કામ કરતી વખતે) - બધું બરાબર થઈ રહ્યું હોય તેવું લાગતું હતું.

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

પરંતુ આજે, સબ્સ્ક્રાઇબર્સના આગળના ભાગ માટે સાધનો પર NAT સક્ષમ કર્યા પછી, સવારથી જ અમને અનુપલબ્ધતા અથવા આંશિક ઉપલબ્ધતા વિશે યોગ્ય સંખ્યામાં ફરિયાદોનો સામનો કરવો પડ્યો. mail.ru અને અન્ય મેઇલ Ru જૂથ સંસાધનો.

તેઓએ તપાસ કરવાનું શરૂ કર્યું: ક્યાંક કંઈક ક્યારેક, ક્યારેક ક્યારેક મોકલે છે TCP RST ફક્ત mail.ru નેટવર્ક્સની વિનંતીઓના જવાબમાં. વધુમાં, તે ખોટી રીતે જનરેટ થયેલ (ACK વગર), દેખીતી રીતે કૃત્રિમ TCP RST મોકલે છે. તે આના જેવું દેખાતું હતું:

સ્વાભાવિક રીતે, પ્રથમ વિચારો નવા સાધનો વિશે હતા: ભયંકર DPI, તેના પર કોઈ વિશ્વાસ નથી, તમે ક્યારેય જાણતા નથી કે તે શું કરી શકે છે - છેવટે, TCP RST એ અવરોધિત સાધનોમાં એકદમ સામાન્ય બાબત છે.

ધારણા કાલેમેન અમે એ વિચારને પણ આગળ ધપાવ્યો કે કોઈ "ઉચ્ચ" ફિલ્ટર કરી રહ્યું છે, પરંતુ તરત જ તેને કાઢી નાખ્યું.

સૌપ્રથમ, અમારી પાસે પૂરતી સમજદાર અપલિંક છે જેથી અમારે આ પ્રકારનો ભોગ બનવું ન પડે :)

બીજું, આપણે અનેક સાથે જોડાયેલા છીએ IX મોસ્કોમાં, અને mail.ru પરનો ટ્રાફિક તેમાંથી પસાર થાય છે - અને તેમની પાસે ન તો જવાબદારીઓ છે કે ન તો ટ્રાફિકને ફિલ્ટર કરવાનો અન્ય કોઈ હેતુ છે.

દિવસનો આગલો અડધો ભાગ જેને સામાન્ય રીતે શામનિઝમ કહેવામાં આવે છે તેના પર વિતાવ્યો - સાધનસામગ્રીના વિક્રેતા સાથે, જેના માટે અમે તેમનો આભાર માનીએ છીએ, તેઓએ હાર માની નહીં :)

• ફિલ્ટરિંગ સંપૂર્ણપણે અક્ષમ હતું
• નવી યોજનાનો ઉપયોગ કરીને NAT ને અક્ષમ કરવામાં આવ્યું હતું
• ટેસ્ટ પીસી એક અલગ અલગ પૂલમાં મૂકવામાં આવ્યો હતો
• IP સરનામું બદલાયું

બપોરે, એક વર્ચ્યુઅલ મશીન ફાળવવામાં આવ્યું હતું જે નિયમિત વપરાશકર્તાની યોજના અનુસાર નેટવર્ક સાથે જોડાયેલ હતું, અને વિક્રેતાના પ્રતિનિધિઓને તેની અને સાધનોની ઍક્સેસ આપવામાં આવી હતી. શામનવાદ ચાલુ રહ્યો :)

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

નોંધણીઆ બિંદુએ, કોઈ કહી શકે છે: પરંતુ ટેસ્ટ પીસીથી નહીં, પરંતુ ડીપીઆઈની ઉપરના હાઇવે પરથી ડમ્પ લેવો તે ખૂબ સરળ હતું?

ના, કમનસીબે, 40+gbps ડમ્પ (અને માત્ર મિરરિંગ પણ) લેવો બિલકુલ તુચ્છ નથી.

આ પછી, સાંજે, ઉપર ક્યાંક વિચિત્ર ગાળણની ધારણા પર પાછા ફરવા સિવાય બીજું કંઈ બચ્યું ન હતું.

મેં જોયું કે IX દ્વારા MRG નેટવર્ક્સનો ટ્રાફિક હવે પસાર થઈ રહ્યો છે અને તેના માટેના bgp સત્રો ખાલી રદ કર્યા. અને - જુઓ અને જુઓ! - બધું તરત જ સામાન્ય થઈ ગયું 🙁

એક તરફ, તે શરમજનક છે કે આખો દિવસ સમસ્યાની શોધમાં વિતાવ્યો હતો, જો કે તે પાંચ મિનિટમાં હલ થઈ ગઈ હતી.

બીજી બાજુ:

- મારી યાદમાં આ એક અભૂતપૂર્વ વસ્તુ છે. જેમ મેં ઉપર લખ્યું છે - IX ખરેખર ટ્રાન્ઝિટ ટ્રાફિકને ફિલ્ટર કરવાનો કોઈ અર્થ નથી. તેમની પાસે સામાન્ય રીતે સેંકડો ગીગાબિટ્સ/ટેરાબિટ્સ પ્રતિ સેકન્ડ હોય છે. હું હમણાં સુધી આના જેવું કંઈક ગંભીરતાથી કલ્પના કરી શક્યો નથી.

— સંજોગોનો અવિશ્વસનીય ભાગ્યશાળી સંયોગ: એક નવું જટિલ હાર્ડવેર કે જે ખાસ કરીને વિશ્વસનીય નથી અને જેમાંથી શું અપેક્ષા રાખી શકાય તે સ્પષ્ટ નથી — TCP RST સહિત સંસાધનોને અવરોધિત કરવા માટે ખાસ તૈયાર કરવામાં આવ્યું છે.

આ ઈન્ટરનેટ એક્સચેન્જની એનઓસી હાલમાં સમસ્યા શોધી રહી છે. તેમના મતે (અને હું તેમને માનું છું), તેમની પાસે કોઈ ખાસ જમાવટ કરેલ ફિલ્ટરેશન સિસ્ટમ નથી. પરંતુ, સ્વર્ગનો આભાર, આગળની શોધ હવે આપણી સમસ્યા નથી :)

મારી જાતને ન્યાયી ઠેરવવાનો આ એક નાનકડો પ્રયાસ હતો, કૃપા કરીને સમજો અને માફ કરો :)

PS: હું જાણીજોઈને DPI/NAT અથવા IX ના ઉત્પાદકનું નામ લેતો નથી (હકીકતમાં, મને તેમના વિશે કોઈ ખાસ ફરિયાદ પણ નથી, મુખ્ય વસ્તુ તે શું હતું તે સમજવું છે)

ઈન્ટરનેટ પ્રદાતાના દૃષ્ટિકોણથી આજની (તેમજ ગઈ કાલની અને ગઈકાલના આગલા દિવસની) વાસ્તવિકતા

લાઇવ યુઝર ટ્રાફિકને નોંધપાત્ર રીતે પ્રભાવિત કરવાના જોખમ સાથે, “નફા માટે” મેનિપ્યુલેશન્સનો સમૂહ કરીને, મેં નેટવર્કના કોરને નોંધપાત્ર રીતે પુનઃનિર્માણ કરવામાં છેલ્લા અઠવાડિયા ગાળ્યા છે. આ બધાના ધ્યેયો, પરિણામો અને પરિણામોને ધ્યાનમાં લેતા, નૈતિક રીતે આ બધું ખૂબ મુશ્કેલ છે. ખાસ કરીને - રુનેટ, સાર્વભૌમત્વ, વગેરેની સ્થિરતાના રક્ષણ વિશે ફરી એકવાર સુંદર ભાષણો સાંભળવા. અને તેથી વધુ.

આ વિભાગમાં, હું છેલ્લા દસ વર્ષમાં લાક્ષણિક ISP ના નેટવર્ક કોરના "ઉત્ક્રાંતિ"નું વર્ણન કરવાનો પ્રયાસ કરીશ.

દસ વર્ષ પહેલા.

તે ધન્ય સમયમાં, પ્રદાતા નેટવર્કનો મુખ્ય ભાગ ટ્રાફિક જામ જેટલો સરળ અને વિશ્વસનીય હોઈ શકે છે:

આ ખૂબ જ સરળ ચિત્રમાં, કોઈ થડ, રિંગ્સ, ip/mpls રૂટીંગ નથી.

તેનો સાર એ છે કે વપરાશકર્તા ટ્રાફિક આખરે કર્નલ લેવલ સ્વિચિંગ પર આવ્યો - જ્યાંથી તે ગયો બી.એન.જી., જ્યાંથી, એક નિયમ તરીકે, કોર સ્વિચિંગ પર પાછા જાઓ, અને પછી "આઉટ" - ઇન્ટરનેટના એક અથવા વધુ બોર્ડર ગેટવે દ્વારા.

આવી યોજના L3 (ડાયનેમિક રૂટીંગ) અને L2 (MPLS) બંને પર આરક્ષિત કરવા માટે ખૂબ જ સરળ છે.

તમે કોઈપણ વસ્તુનું N+1 ઇન્સ્ટોલ કરી શકો છો: સર્વર ઍક્સેસ, સ્વીચો, બોર્ડર્સ - અને એક રીતે અથવા બીજી રીતે તેમને સ્વચાલિત નિષ્ફળતા માટે અનામત રાખો.

થોડા વર્ષો પછી તે રશિયામાં દરેકને સ્પષ્ટ થઈ ગયું છે કે હવે આના જેવું જીવવું અશક્ય છે: બાળકોને ઇન્ટરનેટના નુકસાનકારક પ્રભાવથી બચાવવા તે તાકીદનું હતું.

વપરાશકર્તા ટ્રાફિકને ફિલ્ટર કરવાની રીતો શોધવાની તાત્કાલિક જરૂર હતી.

અહીં વિવિધ અભિગમો છે.

ખૂબ સારા કિસ્સામાં, કંઈક "ગેપમાં" મૂકવામાં આવે છે: વપરાશકર્તા ટ્રાફિક અને ઇન્ટરનેટ વચ્ચે. આ "કંઈક" દ્વારા પસાર થતા ટ્રાફિકનું વિશ્લેષણ કરવામાં આવે છે અને, ઉદાહરણ તરીકે, રીડાયરેક્ટ સાથેનું નકલી પેકેટ સબસ્ક્રાઇબર તરફ મોકલવામાં આવે છે.

સહેજ વધુ સારા કિસ્સામાં - જો ટ્રાફિક વોલ્યુમ પરવાનગી આપે છે - તો તમે તમારા કાનથી એક નાની યુક્તિ કરી શકો છો: ફક્ત વપરાશકર્તાઓ તરફથી ઉદ્ભવતા ટ્રાફિકને ફિલ્ટર કરવા માટે ફક્ત તે સરનામાં પર મોકલો કે જેને ફિલ્ટર કરવાની જરૂર છે (આ કરવા માટે, તમે ક્યાં તો IP સરનામાં લઈ શકો છો. રજિસ્ટ્રીમાંથી ત્યાં ઉલ્લેખિત, અથવા વધુમાં રજિસ્ટ્રીમાં હાલના ડોમેન્સનું નિરાકરણ કરો).

એક સમયે, આ હેતુઓ માટે, મેં એક સરળ લખ્યું મીની ડીપીઆઈ - જો કે હું તેને બોલાવવાની હિંમત પણ કરતો નથી. તે ખૂબ જ સરળ છે અને ખૂબ ઉત્પાદક નથી - જો કે, તે અમને અને અન્ય પ્રદાતાઓને ડઝનેક (જો સેંકડો નહીં) ઔદ્યોગિક DPI સિસ્ટમો પર તરત જ લાખો ખર્ચ ન કરવાની મંજૂરી આપે છે, પરંતુ કેટલાક વધારાના વર્ષોનો સમય આપે છે.

માર્ગ દ્વારા, તે સમયના અને વર્તમાન DPI વિશેમાર્ગ દ્વારા, તે સમયે બજારમાં ઉપલબ્ધ DPI સિસ્ટમ્સ ખરીદનારા ઘણા લોકોએ તેમને પહેલેથી જ ફેંકી દીધા હતા. ઠીક છે, તેઓ આ માટે રચાયેલ નથી: સેંકડો હજારો સરનામાં, હજારો URLs.

અને તે જ સમયે, સ્થાનિક ઉત્પાદકો આ બજારમાં ખૂબ જ મજબૂત રીતે ઉછળ્યા છે. હું હાર્ડવેર ઘટક વિશે વાત કરી રહ્યો નથી - અહીં દરેકને બધું સ્પષ્ટ છે, પરંતુ સોફ્ટવેર - મુખ્ય વસ્તુ જે DPI પાસે છે - કદાચ આજે છે, જો વિશ્વમાં સૌથી અદ્યતન નથી, તો ચોક્કસપણે a) કૂદકે ને ભૂસકે વિકાસ કરી રહ્યો છે, અને b) બોક્સવાળી પ્રોડક્ટની કિંમતે - વિદેશી સ્પર્ધકો સાથે અજોડ.

હું ગર્વ કરવા માંગુ છું, પરંતુ થોડો ઉદાસી =)

હવે બધું આના જેવું દેખાતું હતું:

થોડા વધુ વર્ષોમાં દરેક પાસે પહેલેથી જ ઓડિટર હતા; રજિસ્ટ્રીમાં વધુ અને વધુ સંસાધનો હતા. કેટલાક જૂના સાધનો માટે (ઉદાહરણ તરીકે, સિસ્કો 7600), "સાઇડ-ફિલ્ટરિંગ" યોજના ફક્ત લાગુ પડતી નથી: 76 પ્લેટફોર્મ પરના રૂટની સંખ્યા નવ લાખ જેટલી મર્યાદિત છે, જ્યારે આજે એકલા IPv4 રૂટની સંખ્યા 800ની નજીક પહોંચી રહી છે. હજાર અને જો તે ipv6 પણ છે... અને એ પણ... ત્યાં કેટલું છે? RKN પ્રતિબંધમાં 900000 વ્યક્તિગત સરનામાં? =)

કોઈ વ્યક્તિએ ફિલ્ટરિંગ સર્વર પર તમામ બેકબોન ટ્રાફિકને મિરરિંગ સાથેની સ્કીમ પર સ્વિચ કર્યું છે, જેમાં સમગ્ર પ્રવાહનું વિશ્લેષણ કરવું જોઈએ અને જો કંઈક ખરાબ જણાય તો, બંને દિશામાં (પ્રેષક અને પ્રાપ્તકર્તા) RST મોકલો.

જો કે, જેટલો વધુ ટ્રાફિક, તેટલી ઓછી આ સ્કીમ લાગુ પડશે. જો પ્રક્રિયામાં સહેજ પણ વિલંબ થાય છે, તો પ્રતિબિંબિત ટ્રાફિક કોઈના ધ્યાને ન આવે તે રીતે ઉડી જશે, અને પ્રદાતાને દંડનો અહેવાલ પ્રાપ્ત થશે.

વધુ અને વધુ પ્રદાતાઓને સમગ્ર હાઇવે પર વિવિધ ડિગ્રીની વિશ્વસનીયતાની DPI સિસ્ટમ્સ ઇન્સ્ટોલ કરવાની ફરજ પાડવામાં આવે છે.

એક-બે વર્ષ પહેલા અફવાઓ અનુસાર, લગભગ તમામ એફએસબીએ સાધનોની વાસ્તવિક સ્થાપનાની માંગ કરવાનું શરૂ કર્યું SORM (અગાઉ, મોટાભાગના પ્રદાતાઓ સત્તાવાળાઓની મંજૂરી સાથે સંચાલિત હતા SORM યોજના - ક્યાંક કંઈક શોધવાની જરૂર હોય તો ઓપરેશનલ પગલાંની યોજના)

પૈસા ઉપરાંત (ચોક્કસપણે અતિશય નથી, પરંતુ લાખો), SORM ને નેટવર્ક સાથે ઘણી વધુ હેરફેરની જરૂર હતી.

• SORM ને nat અનુવાદ પહેલાં "ગ્રે" વપરાશકર્તા સરનામાં જોવાની જરૂર છે
• SORM પાસે મર્યાદિત સંખ્યામાં નેટવર્ક ઇન્ટરફેસ છે

તેથી, ખાસ કરીને, અમારે કર્નલનો એક ભાગ પુનઃબીલ્ડ કરવો પડ્યો હતો - ફક્ત એક જ જગ્યાએ ક્યાંક એક્સેસ સર્વર્સ પર વપરાશકર્તા ટ્રાફિક એકત્રિત કરવા માટે. તેને ઘણી લિંક્સ સાથે SORM માં પ્રતિબિંબિત કરવા માટે.

એટલે કે, ખૂબ જ સરળ, તે હતું (ડાબે) વિ બન્યા (જમણે):

હવે મોટા ભાગના પ્રદાતાઓને SORM-3 ના અમલીકરણની પણ જરૂર પડે છે - જેમાં અન્ય વસ્તુઓની સાથે, નેટ બ્રોડકાસ્ટનું લોગીંગ પણ સામેલ છે.

આ હેતુઓ માટે, અમારે ઉપરના આકૃતિમાં NAT માટે અલગ સાધનો પણ ઉમેરવા પડ્યા (પહેલા ભાગમાં જેની ચર્ચા કરવામાં આવી છે તે બરાબર). વધુમાં, ચોક્કસ ક્રમમાં ઉમેરો: SORM એ સરનામાંનો અનુવાદ કરતા પહેલા ટ્રાફિકને "જોવો" આવશ્યક છે, તેથી ટ્રાફિક નીચે પ્રમાણે સખત રીતે જવો જોઈએ: વપરાશકર્તાઓ -> સ્વિચિંગ, કર્નલ -> ઍક્સેસ સર્વર્સ -> SORM -> NAT -> સ્વિચિંગ, કર્નલ - > ઇન્ટરનેટ. આ કરવા માટે, અમારે નફા માટે બીજી દિશામાં ટ્રાફિકના પ્રવાહને શાબ્દિક રીતે "ટર્ન" કરવું પડ્યું, જે ખૂબ મુશ્કેલ પણ હતું.

સારાંશમાં: છેલ્લાં દસ વર્ષોમાં, સરેરાશ પ્રદાતાની મુખ્ય ડિઝાઇન અનેક ગણી વધુ જટિલ બની ગઈ છે, અને નિષ્ફળતાના વધારાના મુદ્દાઓ (ઉપકરણોના સ્વરૂપમાં અને સિંગલ સ્વિચિંગ લાઇનના સ્વરૂપમાં) નોંધપાત્ર રીતે વધ્યા છે. વાસ્તવમાં, "બધું જોવા" માટેની ખૂબ જ આવશ્યકતા આ "બધું" ને એક બિંદુ સુધી ઘટાડવાનો અર્થ સૂચવે છે.

મને લાગે છે કે રુનેટને સાર્વભૌમ બનાવવા, તેને સુરક્ષિત કરવા, તેને સ્થિર કરવા અને તેને સુધારવા માટે વર્તમાન પહેલો માટે આ એકદમ પારદર્શક રીતે એક્સ્ટ્રાપોલેટેડ થઈ શકે છે :)

અને યારોવાયા હજી આગળ છે.

સોર્સ: www.habr.com