M-a îndemnat la această postare .
O citez aici:
azi la 18:53
Am fost mulțumit de furnizor azi. Odată cu actualizarea sistemului de blocare a site-ului i s-a interzis mailer-ul mail.ru.De dimineață sun la asistență tehnică, dar nu pot face nimic. Furnizorul este mic și, aparent, furnizorii de rang superior îl blochează. Am observat și o încetinire în deschiderea tuturor site-urilor, poate au instalat un fel de DLP strâmb? Anterior nu au existat probleme cu accesul. Distrugerea RuNet-ului are loc chiar în fața ochilor mei...
Cert este că se pare că suntem același furnizor :)
Și într-adevăr Aproape că am ghicit cauza problemelor cu mail.ru (deși am refuzat mult timp să credem în așa ceva).
Ceea ce urmează va fi împărțit în două părți:
- motivele problemelor noastre actuale cu mail.ru și căutarea interesantă de a le găsi
- existența ISP-ului în realitățile de astăzi, stabilitatea suveranului RuNet.
Probleme de accesibilitate cu mail.ru
Oh, este o poveste destul de lungă.
Cert este că, pentru a implementa cerințele statului (mai multe detalii în a doua parte), am achiziționat, configurat și instalat unele echipamente - atât pentru filtrarea resurselor interzise, cât și pentru implementarea abonati.
Cu ceva timp în urmă, am reconstruit în sfârșit nucleul rețelei în așa fel încât tot traficul de abonați să treacă prin acest echipament strict în direcția corectă.
Acum câteva zile am activat filtrarea interzisă pe el (în timp ce lăsam vechiul sistem să funcționeze) - totul părea să meargă bine.
Apoi, au început treptat să activeze NAT pe acest echipament pentru diferite părți ale abonaților. După cum arată, totul părea să meargă bine.
Dar astăzi, după ce am activat NAT pe echipament pentru următoarea parte a abonaților, chiar de dimineață ne-am confruntat cu un număr decent de plângeri privind indisponibilitatea sau disponibilitatea parțială și alte resurse Mail Ru Group.
Au început să verifice: ceva undeva uneori, din cand in cand trimite ca răspuns la solicitări exclusiv către rețelele mail.ru. Mai mult, trimite un TCP RST generat incorect (fără ACK), evident artificial. Cam așa arăta:
Desigur, primele gânduri au fost despre noul echipament: DPI groaznic, nu aveți încredere în el, nu știți niciodată ce poate face - la urma urmei, TCP RST este un lucru destul de comun printre instrumentele de blocare.
Presupunere De asemenea, am prezentat ideea că cineva „superior” filtrează, dar am renunțat imediat.
În primul rând, avem uplink-uri suficient de sănătoase pentru a nu trebui să suferim așa :)
În al doilea rând, suntem conectați la mai multe la Moscova, iar traficul către mail.ru trece prin ei - și nu au nici responsabilități și nici alt motiv pentru a filtra traficul.
Următoarea jumătate a zilei a fost petrecută pe ceea ce se numește de obicei șamanism - împreună cu vânzătorul de echipamente, pentru care le mulțumim, nu au renunțat :)
- filtrarea a fost complet dezactivată
- NAT a fost dezactivat folosind noua schemă
- PC-ul de testare a fost plasat într-un bazin izolat separat
- Adresa IP a fost schimbată
După-amiaza, a fost alocată o mașină virtuală care se conectează la rețea după schema unui utilizator obișnuit, iar reprezentanților vânzătorului li s-a dat acces la ea și la echipament. Samanismul a continuat :)
În final, reprezentantul vânzătorului a declarat cu încredere că hardware-ul nu are absolut nimic de-a face cu el: primele vin de undeva mai sus.
NotaÎn acest moment, cineva poate spune: dar a fost mult mai ușor să faci o gunoială nu de pe PC-ul de test, ci de pe autostradă deasupra DPI-ului?
Nu, din păcate, a face un dump (și chiar oglindirea) 40+gbps nu este deloc banal.
După aceasta, seara, nu a mai rămas nimic de făcut decât să revenim la presupunerea unei filtrări ciudate undeva mai sus.
M-am uitat prin care IX trece acum traficul către rețelele MRG și am anulat pur și simplu sesiunile bgp către acesta. Și - iată și iată! - totul a revenit imediat la normal 🙁
Pe de o parte, este păcat că toată ziua a fost petrecută căutând problema, deși a fost rezolvată în cinci minute.
Pe de altă parte:
— în memoria mea, acesta este un lucru fără precedent. După cum am scris deja mai sus - IX într-adevăr nu are rost să filtrezi traficul de tranzit. De obicei, au sute de gigabiți/terabiți pe secundă. Nu mi-am putut imagina serios așa ceva până de curând.
— o coincidență incredibil de norocoasă a circumstanțelor: un nou hardware complex care nu este deosebit de de încredere și de la care nu este clar la ce se poate aștepta — adaptat special pentru blocarea resurselor, inclusiv RST-urile TCP
NOC-ul acestui schimb de internet caută în prezent o problemă. Potrivit lor (și le cred), nu au niciun sistem de filtrare special desfășurat. Dar, mulțumesc cerului, căutarea ulterioară nu mai este problema noastră :)
Aceasta a fost o mică încercare de a mă justifica, vă rog să înțelegeți și să iertați :)
PS: Nu numesc în mod deliberat producătorul DPI/NAT sau IX (de fapt, nici măcar nu am plângeri speciale despre ele, principalul lucru este să înțeleg ce a fost)
Realitatea de azi (ca și de ieri și de alaltăieri) din punctul de vedere al unui furnizor de internet
Am petrecut ultimele săptămâni reconstruind în mod semnificativ nucleul rețelei, efectuând o grămadă de manipulări „pentru profit”, cu riscul de a afecta semnificativ traficul de utilizatori live. Având în vedere scopurile, rezultatele și consecințele tuturor acestor lucruri, din punct de vedere moral, totul este destul de dificil. Mai ales - ascultând încă o dată discursuri frumoase despre protejarea stabilității Runetului, a suveranității etc. și așa mai departe.
În această secțiune, voi încerca să descriu „evoluția” nucleului de rețea al unui ISP tipic în ultimii zece ani.
Acum zece ani.
În acele vremuri binecuvântate, nucleul unei rețele de furnizori ar putea fi la fel de simplu și de fiabil ca un blocaj de trafic:
În această imagine foarte, foarte simplificată, nu există trunchiuri, inele, rutare ip/mpls.
Esența sa este că traficul de utilizatori a ajuns în cele din urmă la comutarea la nivel de kernel - de unde a mers , de unde, de regulă, înapoi la comutarea de bază, apoi „ieșiți” - printr-una sau mai multe porți de frontieră către Internet.
O astfel de schemă este foarte, foarte ușor de rezervat atât pe L3 (routing dinamic), cât și pe L2 (MPLS).
Puteți instala N+1 din orice: accesați servere, comutatoare, frontiere - și într-un fel sau altul le rezervați pentru failover automat.
După câțiva ani A devenit clar pentru toată lumea din Rusia că este imposibil să mai trăiești așa: era urgent să protejăm copiii de influența pernicioasă a internetului.
Era nevoie urgentă de a găsi modalități de filtrare a traficului utilizatorilor.
Există abordări diferite aici.
Într-un caz nu foarte bun, ceva este pus „în decalaj”: între traficul utilizatorilor și internet. Traficul care trece prin acest „ceva” este analizat și, de exemplu, un pachet fals cu redirecționare este trimis către abonat.
Într-un caz ceva mai bun - dacă volumele de trafic vă permit - puteți face un mic truc cu urechile: trimiteți pentru filtrare numai traficul care provine de la utilizatori numai către acele adrese care trebuie filtrate (pentru a face acest lucru, puteți fie să luați adresele IP specificate acolo din registru, sau rezolvarea suplimentară a domeniilor existente în registru).
La un moment dat, în aceste scopuri, am scris un simplu - deși nici nu îndrăznesc să-i spun așa. Este foarte simplu și nu foarte productiv - cu toate acestea, ne-a permis nouă și zeci (dacă nu sute) de alți furnizori să nu plătim imediat milioane de sisteme DPI industriale, dar ne-a oferit câțiva ani suplimentari.
Apropo, despre DPI-ul de atunci și actualApropo, mulți dintre cei care au achiziționat sistemele DPI disponibile pe piață la acea vreme le aruncaseră deja. Ei bine, nu sunt concepute pentru asta: sute de mii de adrese, zeci de mii de URL-uri.
Și, în același timp, producătorii autohtoni au urcat foarte puternic pe această piață. Nu vorbesc despre componenta hardware - totul este clar pentru toată lumea aici, dar software-ul - principalul lucru pe care îl are DPI - este poate astăzi, dacă nu cel mai avansat din lume, atunci cu siguranță a) se dezvoltă treptat, și b) la prețul unui produs în cutie - pur și simplu incomparabil cu concurenții străini.
Aș vrea să fiu mândru, dar puțin trist =)
Acum totul arăta așa:
Peste câțiva ani toată lumea avea deja auditori; În registru erau tot mai multe resurse. Pentru unele echipamente mai vechi (de exemplu, Cisco 7600), schema de „filtrare laterală” a devenit pur și simplu inaplicabilă: numărul de rute pe 76 de platforme este limitat la aproximativ nouă sute de mii, în timp ce numărul de rute IPv4 în prezent se apropie de 800. mie. Și dacă este și ipv6... Și de asemenea... cât este? 900000 de adrese individuale în interdicția RKN? =)
Cineva a trecut la o schemă cu oglindirea întregului trafic backbone către un server de filtrare, care ar trebui să analizeze întregul flux și, dacă se găsește ceva rău, să trimită RST în ambele direcții (expeditor și destinatar).
Cu toate acestea, cu cât traficul este mai mare, cu atât această schemă este mai puțin aplicabilă. Dacă există cea mai mică întârziere în procesare, traficul în oglindă va trece pur și simplu neobservat, iar furnizorul va primi un raport de amendă.
Din ce în ce mai mulți furnizori sunt nevoiți să instaleze sisteme DPI cu diferite grade de fiabilitate pe autostrăzi.
Acum un an sau doi conform zvonurilor, aproape tot FSB-ul a început să ceară instalarea efectivă a echipamentelor (anterior, majoritatea furnizorilor se gestionau cu aprobarea autorităților planul SORM - un plan de măsuri operaționale în caz de nevoie de a găsi ceva undeva)
Pe lângă bani (nu tocmai exorbitanți, dar totuși milioane), SORM a necesitat mult mai multe manipulări cu rețeaua.
- SORM trebuie să vadă adresele utilizatorilor „gri” înainte de traducerea nat
- SORM are un număr limitat de interfețe de rețea
Prin urmare, în special, a trebuit să reconstruim foarte mult o bucată din kernel - pur și simplu pentru a colecta traficul utilizatorilor către serverele de acces undeva într-un singur loc. Pentru a-l oglindi în SORM cu mai multe link-uri.
Adică, foarte simplificat, a fost (stânga) vs devenit (dreapta):
Acum Majoritatea furnizorilor necesită, de asemenea, implementarea SORM-3 - care include, printre altele, înregistrarea transmisiunilor nat.
În aceste scopuri, a trebuit să adăugăm și echipamente separate pentru NAT diagramei de mai sus (exact ceea ce este discutat în prima parte). Mai mult, adaugă într-o anumită ordine: întrucât SORM trebuie să „vadă” traficul înainte de a traduce adrese, traficul trebuie să meargă strict după cum urmează: utilizatori -> comutare, nucleu -> servere de acces -> SORM -> NAT -> comutare, nucleu - > Internet. Pentru a face acest lucru, a trebuit să „întoarcem” fluxurile de trafic în cealaltă direcție pentru profit, ceea ce a fost și destul de dificil.
În rezumat: în ultimii zece ani, designul de bază al unui furnizor mediu a devenit de multe ori mai complex, iar punctele suplimentare de defecțiune (atât sub formă de echipamente, cât și sub formă de linii de comutare unice) au crescut semnificativ. De fapt, însăși cerința de a „vedea totul” implică reducerea acestui „totul” la un punct.
Cred că acest lucru poate fi extrapolat destul de transparent la inițiativele actuale de suveranizare a Runetului, de a-l proteja, de a-l stabiliza și de a-l îmbunătăți :)
Și Yarovaya este încă înainte.
Sursa: www.habr.com