M-a motivat să scriu acest post .
Îl citez aici:
astăzi la 18:53
Furnizorul m-a surprins astăzi. Împreună cu actualizarea sistemului de blocare a site-urilor, a fost inclus și mail.ru pe lista de restricții. Dimineața am contactat suportul tehnic, dar nu au putut face nimic. Furnizorul este mic și, se pare, blocarea este făcută de furnizorii superiori. Am observat, de asemenea, o încetinire a deschiderii tuturor site-urilor, poate că au introdus un DLP defectuos? În trecut nu au existat probleme de acces. Distrugerea Runet-ului se desfășoară chiar sub ochii mei…
Problema este că, se pare, și noi suntem acel furnizor 🙁
Și, într-adevăr, aproape am ghicit cauza problemelor cu mail.ru (deși ne-a luat mult timp să credem în așa ceva).
Următoarea parte va fi împărțită în două:
- cauzele problemelor noastre de astăzi cu mail.ru și o aventură fascinantă în căutarea lor
- existența ISP-urilor în realitățile de astăzi, stabilitatea Runet-ului suveran.
Probleme de accesibilitate la mail.ru
Oh, aceasta este o poveste destul de lungă.
Problema este că, pentru a implementa cerințele statului (mai multe detalii în partea a doua), am achiziționat, configurat și instalat anumite echipamente - atât pentru filtrarea resurselor interzise, cât și pentru abonat.
Cu ceva timp în urmă, în sfârșit am restructurat nucleul rețelei astfel încât tot traficul abonaților să treacă prin acest echipament strict în direcția corectă.
Cu câteva zile în urmă am activat filtrarea conținutului interzis pe acest echipament (menținând în funcțiune și sistemul vechi) — aparent, totul a decurs bine.
Apoi - am început treptat să activăm NAT pentru diferite grupuri de abonați pe acest echipament. La prima vedere - totul, se părea că merge bine.
Dar astăzi, activând NAT pe echipament pentru o nouă grupare de abonați - de dimineață ne-am confruntat cu un număr semnificativ de plângeri despre inaccesibilitatea sau accesibilitatea parțială și alte resurse ale Mail Ru Group.
Am început să verificăm: ceva undeva ocazional, rareori trimite ca răspuns la cererile exclusiv pentru rețelele mail.ru. Mai mult, trimite un TCP RST generat incorect (fără ACK), evident artificial. Asta arăta cam așa:
Desigur, primele gânduri au fost legate de echipamentele noi: un DPI înfricoșător, nicio încredere în el, cine știe ce ar putea face — având în vedere că TCP RST este ceva destul de comun în rândul instrumentelor de blocare.
Presupunerea că cineva de „nivel superior” filtrează a fost de asemenea înaintată — dar am abandonat imediat.
În primul rând, avem uplinkuri rezonabile, astfel încât să nu suferim din această cauză 🙂
În al doilea rând, suntem conectați la mai multe din Moscova, iar traficul către mail.ru trece prin intermediul lor — iar ei nu au nici obligații, nici alt motiv de a filtra traficul.
Următoarea jumătate de zi a fost dedicată a ceea ce se numește în mod obișnuit voodoo — împreună cu furnizorul de echipamente, căruia îi mulțumim, nu ne-au abandonat 🙂
- filtrarea a fost complet dezactivată
- NAT a fost dezactivat conform unui nou schema
- PC-ul de test a fost scos într-un pool izolat
- s-a schimbat adresarea IP
În a doua jumătate a zilei, a fost alocat un server virtual, conectat la rețea conform schemei unui utilizator obișnuit, iar accesul la acesta și la echipament a fost permis reprezentanților furnizorului. Voodoo a continuat 🙂
În cele din urmă, reprezentantul furnizorului a declarat cu încredere că echipamentul nu are nicio legătură: rst-urile vin de undeva mai sus.
NotăÎn acest moment, cineva ar putea afirma: dar ar fi fost mult mai simplu să se ia un dump nu de pe PC-ul de test, ci de pe magistrala de deasupra DPI-ului?
Nu, din păcate, a obține un dump (și chiar și doar a face un mirror) de 40+gbps nu este deloc trivial.
După aceasta, deja seara — nu a rămas altceva de făcut decât să ne întoarcem la presupunerea despre o filtrare ciudată undeva mai sus.
Am verificat prin ce IX circula acum traficul către rețelele MRG și pur și simplu am dezactivat sesiunile bgp către acesta. Și — miracol! — totul s-a normalizat imediat 🙁
Pe de o parte — este foarte trist că a fost cheltuită toată ziua pentru a găsi problema, deși a fost rezolvată în cinci minute.
Pe de altă parte:
— în amintirea mea, acesta este un lucru fără precedent. Așa cum am scris mai sus — pentru IX-uri cu adevărat nu are sens să filtreze traficul de tranzit. De obicei, au sute de gigabiți / terabiți pe secundă. Pur și simplu, până în ultimul moment, nu am putut să cred serios o astfel de presupunere.
— o coincidență incredibil de favorabilă: echipament nou și complex, care nu inspiră o încredere deosebită și de la care nu este clar ce să aștepți — conceput exact pentru a bloca resurse, inclusiv prin TCP RST-uri.
În prezent, NOC-ul acestui internet exchange caută o problemă. Conform afirmațiilor lor (și îi cred), nu au un sistem de filtrare special desfășurat. Dar, mulțumim cerului, următoarea misiune - deja nu este problema noastră 🙂
A fost o mică încercare de a ne justifica, vă rog să înțelegeți și să iertați 🙂
P.S.: intenționat nu menționez nici producătorul DPI/NAT, nici IX (nu am, de fapt, pretenții speciale față de ei, principalul este să înțeleg ce a fost)
Realitatea de astăzi (precum și cea de ieri și alaltăieri) din perspectiva unui furnizor de internet
În ultimele săptămâni, am petrecut timp semnificativ restructurând nucleul rețelei, realizând o mulțime de manipulări „live”, cu riscul de a afecta semnificativ traficul utilizatorilor activi. Având în vedere scopurile, rezultatele și consecințele acestui lucru - moral, totul este destul de greu. În special - ascultând din nou predicile despre protecția stabilității runet-ului, suveranitate, etc.
În această secțiune, voi încerca să explic „evoluția” nucleului rețelei unui furnizor tipic de internet în ultimul deceniu.
Acum un deceniu.
În acele vremuri binecuvântate, nucleul rețelei furnizorului putea fi simplu și fiabil, ca un dop:
În această imagine foarte, foarte simplificată lipsesc magistralele, inelele și rutarea ip/MPLS.
Esenta este că traficul utilizatorilor ajungea, în cele din urmă, în comutarea la nivel de nucleu - de unde mergea la , de unde, de obicei - se întorcea în comutarea nucleului, și apoi „la ieșire” - prin unul sau mai multe gate-uri de bord către internet.
Această schemă este foarte, foarte ușor de rezervat atât la L3 (rutare dinamică), cât și la L2 (MPLS).
Se poate pune N+1 din orice: servere de acces, switch-uri, gate-uri de bord - și într-un fel sau altul le putem rezerva pentru failover automat.
După câțiva ani toată lumea din Rusia a realizat că nu se mai poate trăi așa: trebuie urgent protejate copiii de influențele nocive ale rețelei.
A apărut necesitatea de a găsi urgent modalități de a filtra traficul utilizatorilor.
Există diferite abordări.
În cel mai desfavorabil caz - ceva este plasat „în felul tău”: între traficul utilizatorului și internet. Traficul care trece prin acel „ceva” este analizat și, de exemplu, se trimite un pachet fals cu redirecționare către abonat.
În cel mai bun caz — dacă volumele de trafic permit — se poate face un mic truc: a trimite la filtrare doar traficul care provine de la utilizatori către acele adrese care trebuie filtrate (pentru aceasta se pot folosi fie IP-urile specificate în registru, fie se pot rezolva suplimentar domeniile existente în registru).
Cu ani în urmă, pentru aceste scopuri am scris un simplu — deși nici măcar nu îmi vine să-l numesc așa. Este foarte simplu și nu foarte performant — totuși, atât pentru noi, cât și pentru zeci (dacă nu sute) de alți furnizori, ne-a permis să nu cheltuim milioane pe sisteme DPI industriale deodată, ci ne-a oferit câțiva ani suplimentari.
Vorbind de DPI-urile de atunci și de acumTrebuie spus că mulți dintre cei care au achiziționat sistemele DPI disponibile pe piață pe atunci — le-au aruncat deja. Nu sunt adaptate pentru a face față: sute de mii de adrese, zeci de mii de URL-uri.
Între timp, pe acest segment de piață, producătorii autohtoni au crescut foarte mult. Nu vorbesc despre partea hardware — aici e clar pentru toată lumea, însă software-ul — principalul aspect al DPI-ului — poate că, la ora actuală, dacă nu este cel mai avansat din lume, cu siguranță a) se dezvoltă într-un ritm alert, și b) ca preț, în varianta de cutie — este pur și simplu incomparabil cu concurenții străini.
Aș vrea să mă mândresc, dar e puțin trist =)
Acum totul arăta așa:
După încă doi ani toți aveau deja revisori; resursele din registru deveneau din ce în ce mai numeroase. Pentru unele echipamente mai vechi (de exemplu, cisco 7600) schema de „filtrare laterală” devenea pur și simplu ineficientă: numărul rutelor pe platformele 76 este limitat la ceva în jur de nouă sute de mii, în timp ce numărul doar de rute IPv4 este acum aproape de 800 de mii. Și dacă mai adăugăm ipv6… Și cât mai este? 900000 de adrese separate în banul rkn? =)
Cineva a trecut la schema de copiere a întregului trafic de bază către un server de filtrare, care trebuie să analizeze întreg fluxul și, în cazul în care detectează ceva suspect, să trimită în ambele direcții (către expeditor și destinatar) RST.
Însă cu cât mai mult trafic, cu atât mai puțin aplicabilă devine această schemă. La cea mai mică întârziere în procesare — traficul copiat pur și simplu va trece neobservat în neant, iar furnizorul va primi un protocol de penalizare.
Tot mai mulți furnizori sunt nevoiți să implementeze sisteme DPI de diferite grade de fiabilitate în intersecția magistralelor.
Acum un an sau doi se spune că practic toți FSB-urile au început să ceară instalarea reală a echipamentului (în trecut, majoritatea furnizorilor se descurcau cu o aprobată de la autorități planul SORM — planul de acțiuni operaționale în caz de necesitate de a găsi ceva undeva)
Pe lângă bani (nu atât de mult încât să fie complet exorbitanți, dar totuși — milioane), SORM a fost necesar pentru mulți să efectueze manevre suplimentare în rețea.
- SORM trebuie să vadă adresele «gri» ale utilizatorilor, înainte de NAT-translare
- SORM are un număr limitat de interfețe de rețea
De aceea, a fost necesar, printre altele, să restructurăm semnificativ o parte a nucleului — pur și simplu pentru a aduna undeva într-un singur loc traficul utilizatorilor către serverele de acces. Pentru a-l mirroriza în SORM prin câteva legături.
Adică, foarte simplificat, a fost (stânga) vs a devenit (dreapta):
Acum majoritatea furnizorilor sunt obligați să implementeze și SORM-3 — care include, printre altele, și logger-ul pentru NAT-translații.
În aceste scopuri, în schema de mai sus a fost necesar să adăugăm și un echipament separat pentru NAT (exact cel despre care se vorbește în prima parte). Și chiar să-l adăugăm într-o anumită ordine: deoarece SORM trebuie să «vadă» traficul înainte de translarea adreselor — traficul trebuie să meargă strict în următorul mod: utilizatori -> comutare, nucleu -> servere de acces -> SORM -> NAT -> comutare, nucleu -> internet. Pentru aceasta a fost necesar, pur și simplu, să «întoarcem» fluxurile de trafic în cealaltă direcție în timp real, ceea ce a fost de asemenea destul de complicat.
În total: în decurs de un deceniu schema nucleului unui furnizor mediu s-a complicat de câteva ori, iar punctele suplimentare de eșec (fie că este vorba de echipamente, fie de linii de comutare unice) s-au înmulțit semnificativ. De fapt, cerința de a «vedea totul» implică consolidarea acestui «tot» într-un singur punct.
Cred că acesta se poate extrapola destul de clar asupra inițiativelor actuale de suveranizare a Runet-ului, protecția lui, stabilizarea și îmbunătățirea 🙂
Și înaintea noastră este încă Yarevaya.
Sursa: habr.com
