Principes van routering en conversie van IP-verkeer in een VPN-netwerk gemaakt met behulp van ViPNet-technologie. Algemene principes van interactie tussen ViPNet-knooppunten in een virtueel netwerk

Elke beheerder krijgt vroeg of laat instructies van het management: “tel wie er online gaat en hoeveel ze downloaden.” Voor aanbieders wordt het aangevuld met de taken van “het binnenlaten van iedereen die het nodig heeft, het aannemen van betalingen, het beperken van de toegang.” Wat te tellen? Hoe? Waar? Er is veel fragmentarische informatie, deze is niet gestructureerd. We zullen de beginnende beheerder behoeden voor vervelende zoekopdrachten door hem algemene kennis te geven, en nuttige links voor materieel.
In dit artikel zal ik proberen de principes te beschrijven van het organiseren van de verzameling, boekhouding en controle van verkeer op het netwerk. We zullen de problemen van het probleem en de lijst overwegen mogelijke manieren Informatie ophalen van netwerkapparaten.

Dit is het eerste theoretische artikel in een reeks artikelen gewijd aan het verzamelen, boekhouden, beheren en factureren van verkeer en IT-middelen.

Structuur van internettoegang

IN algemeen geval, is de netwerktoegangsstructuur als volgt:

Externe bronnen - het internet, met alle sites, servers, adressen en andere zaken die niet tot het netwerk behoren dat u beheert.
Toegangsapparaat – router (hardware of pc-gebaseerd), switch, VPN-server of concentrator.
Interne bronnen zijn een reeks computers, subnetten en abonnees waarvan de werking op het netwerk in aanmerking moet worden genomen of gecontroleerd.
Een beheer- of boekhoudserver is een apparaat waarop een gespecialiseerd apparaat is geïnstalleerd software. Functioneel te combineren met een softwarerouter.

In deze structuur gaat netwerkverkeer van externe bronnen naar interne bronnen, en terug, via het toegangsapparaat. Het verzendt verkeersinformatie naar de beheerserver. De controleserver verwerkt deze informatie, slaat deze op in de database, geeft deze weer en geeft blokkeeropdrachten. Niet alle combinaties van toegangsapparaten (methoden) en verzamel- en controlemethoden zijn echter compatibel. OVER verschillende opties en zal hieronder worden besproken.

Netwerkverkeer

Eerst moet u definiëren wat wordt bedoeld met ‘netwerkverkeer’ en wat nuttig is statistische informatie kan worden geëxtraheerd uit de gebruikersgegevensstroom.
Het dominante internetwerkprotocol is nog steeds IP-versie 4. Het IP-protocol komt overeen met laag 3 van het OSI-model (L3). Informatie (gegevens) tussen de afzender en de ontvanger wordt verpakt in pakketten - met een header en een "payload". De titel definieert waar en waar gaat hij heen pakket (IP-adressen van afzender en ontvanger), pakketgrootte, type payload. Hoofddeel netwerk verkeer UDP- en TCP-payloadpakketten zijn Layer 4 (L4)-protocollen. Naast adressen bevat de header van deze twee protocollen poortnummers, die bepalen welk type dienst (applicatie) gegevens verzendt.

Een IP-pakket verzenden via draden (of radio) netwerk apparaten worden gedwongen om het te “verpakken” (inkapselen) in een laag 2 (L2) protocolpakket. Het meest voorkomende protocol van dit type is Ethernet. De daadwerkelijke transmissie “naar de draad” vindt plaats op het 1e niveau. Normaal gesproken analyseert het toegangsapparaat (router) geen pakketheaders op niveaus hoger dan niveau 4 (met uitzondering van intelligente firewalls).
Informatie uit de velden van adressen, poorten, protocollen en lengtetellers uit de L3- en L4-headers van datapakketten vormen de ‘grondstof’ die wordt gebruikt bij verkeersadministratie en -beheer. De daadwerkelijke hoeveelheid verzonden informatie vindt u in het veld Lengte van de IP-header (inclusief de lengte van de header zelf). Trouwens, als gevolg van pakketfragmentatie als gevolg van het MTU-mechanisme, is de totale hoeveelheid verzonden gegevens altijd hetzelfde groter formaat lading.

De totale lengte van interessant voor ons in deze context De IP- en TCP/UDP-velden van het pakket vormen 2...10% van de totale pakketlengte. Als je al deze informatie batch voor batch verwerkt en opslaat, zijn er niet genoeg middelen. Gelukkig is het overgrote deel van het verkeer zo gestructureerd dat het bestaat uit een reeks ‘gesprekken’ tussen externe en interne netwerkapparaten, die ‘stromen’ worden genoemd. Binnen één e-maildoorstuurbewerking ( SMTP-protocol) wordt er een TCP-sessie geopend tussen de client en de server. Het wordt gekenmerkt door een constante reeks parameters (bron-IP-adres, bron-TCP-poort, doel-IP-adres, bestemming-TCP-poort). In plaats van informatie batch voor pakket te verwerken en op te slaan, is het veel handiger om stroomparameters (adressen en poorten) op te slaan, evenals aanvullende informatie– het aantal en de som van de lengte van de verzonden pakketten in elke richting, optioneel de duur van de sessie, indexen van routerinterfaces, de waarde van het ToS-veld, enz. Deze aanpak is gunstig voor verbindingsgerichte protocollen (TCP), waarbij het mogelijk is om de beëindiging van een sessie expliciet te onderscheppen. Zelfs voor niet-sessiegerichte protocollen is het echter mogelijk om aggregatie en logische voltooiing van een stroomrecord uit te voeren op basis van bijvoorbeeld een time-out. Hieronder vindt u een fragment uit de SQL-database van ons eigen facturatiesysteem, waarin informatie over verkeersstromen wordt geregistreerd:

Er moet rekening worden gehouden met het geval waarin het toegangsapparaat adresvertaling (NAT, masquerading) uitvoert om internettoegang voor lokale netwerkcomputers te organiseren met behulp van één extern, openbaar IP-adres. In dit geval vervangt een speciaal mechanisme IP-adressen en TCP/UDP-poorten van verkeerspakketten, waarbij interne (niet routeerbare op internet) adressen worden vervangen volgens de dynamische vertaaltabel. In deze configuratie is het noodzakelijk om te onthouden dat om gegevens op interne netwerkhosts correct vast te leggen, statistieken moeten worden verzameld op een manier en op een plaats waar het vertaalresultaat de interne adressen nog niet “anonimiseert”.

Methoden voor het verzamelen van verkeers-/statistische informatie

U kunt informatie over het doorgeven van verkeer rechtstreeks op het toegangsapparaat zelf (pc-router, VPN-server) vastleggen en verwerken, van dit apparaat naar een afzonderlijke server (NetFlow, SNMP) of "vanaf de draad" (tap, SPAN) overbrengen. Laten we alle opties in volgorde bekijken.

PC-router

Laten we eens overwegen eenvoudigste geval– toegang tot apparaat (router) op basis van een pc met Linux OS.

Hoe je zo’n server opzet, adresvertaling en routering, er is veel geschreven. We zijn geïnteresseerd in de volgende logische stap: informatie over hoe u informatie kunt verkrijgen over het verkeer dat door zo'n server gaat. Er zijn drie veel voorkomende methoden:

het onderscheppen (kopiëren) van pakketten die door de netwerkkaart van de server gaan met behulp van de libpcap-bibliotheek
het onderscheppen van pakketten die door de ingebouwde firewall
het gebruik van tools van derden voor het omzetten van pakket-voor-pakket-statistieken (verkregen door een van de twee voorgaande methoden) in een geaggregeerde netflow-informatiestroom

Libkap

In het eerste geval kan een kopie worden opgevraagd van het pakket dat door de interface gaat, nadat het door het filter (man pcap-filter) is gegaan. cliënt programma op een server geschreven met behulp van deze bibliotheek. Het pakket arriveert met een laag 2-header (Ethernet). Het is mogelijk om de lengte van de vastgelegde informatie te beperken (als we alleen geïnteresseerd zijn in informatie uit de header). Voorbeelden van dergelijke programma's zijn tcpdump en Wireshark. Er is een implementatie van libpcap voor Windows. Als adresvertaling wordt gebruikt op een pc-router, kan een dergelijke onderschepping alleen op de router worden uitgevoerd interne interface, verbonden met lokale gebruikers. Op de externe interface bevatten IP-pakketten na vertaling geen informatie over de interne hosts van het netwerk. Met deze methode is het echter onmogelijk om rekening te houden met het verkeer dat door de server zelf op internet wordt gecreëerd (wat belangrijk is als deze web- of postdienst).

libpcap vereist ondersteuning van het besturingssysteem, wat momenteel neerkomt op het installeren van een enkele bibliotheek. In dit geval moet het toepassings- (gebruikers)programma dat pakketten verzamelt:

open de gewenste interface
specificeer het filter waardoor ontvangen pakketten moeten worden doorgegeven, de grootte van het vastgelegde deel (snaplen), de buffergrootte,
stel de promisc-parameter in, die de netwerkinterface in de capture-modus zet voor alle pakketten die passeren, en niet alleen voor de pakketten die zijn geadresseerd aan het MAC-adres van deze interface
stel een functie (callback) in die voor elk ontvangen pakket wordt aangeroepen.

Wanneer een pakket via de geselecteerde interface wordt verzonden, ontvangt deze functie, nadat het filter is gepasseerd, een buffer met daarin Ethernet, (VLAN), IP, enz. headers, totale grootte tot snaplen. Omdat de libcap-bibliotheek pakketten kopieert, kan deze niet worden gebruikt om de doorgang ervan te blokkeren. In dit geval zal het programma voor het verzamelen en verwerken van verkeer moeten worden gebruikt alternatieve methoden, bijvoorbeeld door een script aan te roepen om een bepaald IP-adres in een verkeersblokkeringsregel te plaatsen.

Firewall

Door gegevens vast te leggen die door de firewall gaan, kunt u rekening houden met zowel het verkeer van de server zelf als het verkeer van netwerkgebruikers, zelfs als de adresvertaling actief is. Het belangrijkste in dit geval is om de capture-regel correct te formuleren en in te voeren juiste plaats. Deze regel activeert de overdracht van het pakket naar de systeembibliotheek, vanwaar de toepassing voor verkeersadministratie en -beheer het kan ontvangen. Voor Linux OS wordt iptables gebruikt als firewall, en onderscheppingstools zijn ipq, netfliter_queue of ulog. Voor OC FreeBSD – ipfw met regels zoals tee of divert. In ieder geval wordt het firewallmechanisme aangevuld met de mogelijkheid om op de volgende manier met een gebruikersprogramma te werken:

Een gebruikersprogramma - een verkeersafhandelaar - registreert zichzelf in het systeem met behulp van een systeemoproep of een bibliotheek.
Een gebruikersprogramma of extern script installeert een regel in de firewall, waarbij het geselecteerde verkeer (volgens de regel) in de handler wordt 'ingepakt'.
Voor elk passerend pakket ontvangt de handler de inhoud ervan in de vorm van een geheugenbuffer (met IP-headers, enz.) Na verwerking (accounting) moet het programma de kernel van het besturingssysteem ook vertellen wat het vervolgens met zo'n pakket moet doen - verwijder het of doorgeven. Als alternatief is het mogelijk het gewijzigde pakket door te geven aan de kernel.

Omdat het IP-pakket niet wordt gekopieerd, maar ter analyse naar de software wordt gestuurd, wordt het mogelijk om het te ‘uitwerpen’ en daardoor het verkeer van een bepaald type (bijvoorbeeld naar een geselecteerde lokale netwerkabonnee) geheel of gedeeltelijk te beperken. Als het applicatieprogramma echter niet meer reageert op de kernel over zijn beslissing (bijvoorbeeld vastloopt), wordt het verkeer via de server eenvoudigweg geblokkeerd.
Opgemerkt moet worden dat de beschreven mechanismen, met aanzienlijke hoeveelheden verzonden verkeer, een overmatige belasting van de server veroorzaken, wat gepaard gaat met het voortdurend kopiëren van gegevens van de kernel naar gebruikersprogramma. De methode voor het verzamelen van statistieken op het kernelniveau van het besturingssysteem, met de uitvoer van geaggregeerde statistieken naar het applicatieprogramma via het NetFlow-protocol, kent dit nadeel niet.

Netstroom

Dit protocol is ontwikkeld door Cisco Systems om verkeersinformatie van routers te exporteren ten behoeve van verkeersregistratie en -analyse. De meest populaire versie 5 biedt de ontvanger nu een stroom gestructureerde gegevens in de vorm van UDP-pakketten met informatie over eerder verkeer in de vorm van zogenaamde flowrecords:

De hoeveelheid informatie over het verkeer is enkele ordes van grootte kleiner dan het verkeer zelf, wat vooral belangrijk is in grote en gedistribueerde netwerken. Het is uiteraard onmogelijk om de overdracht van informatie te blokkeren bij het verzamelen van statistieken via netflow (tenzij er aanvullende mechanismen worden gebruikt).
Momenteel wordt een verdere ontwikkeling van dit protocol populair: versie 9, gebaseerd op de sjabloonstroomrecordstructuur, implementatie voor apparaten van andere fabrikanten (sFlow). Onlangs is de IPFIX-standaard aangenomen, waarmee statistieken via protocollen op diepere niveaus (bijvoorbeeld per applicatietype) kunnen worden verzonden.
De implementatie van netflow-bronnen (agents, probes) is beschikbaar voor pc-routers, zowel in de vorm van hulpprogramma's die werken volgens de hierboven beschreven mechanismen (flowprobe, softflowd), als rechtstreeks ingebouwd in de besturingssysteemkernel (FreeBSD:, Linux:). Voor softwarerouters kan de netflow-statistiekenstroom lokaal op de router zelf worden ontvangen en verwerkt, of via het netwerk (overdrachtsprotocol - via UDP) naar het ontvangende apparaat (collector) worden verzonden.

Het verzamelprogramma kan informatie uit vele bronnen tegelijk verzamelen, waardoor het verkeer zelfs met overlappende adresruimten kan worden onderscheiden. Met behulp van aanvullende tools zoals nprobe is het ook mogelijk om extra dataaggregatie, streambifurcatie of protocolconversie uit te voeren, wat belangrijk is bij het beheren van een groot en gedistribueerd netwerk met tientallen routers.

ondersteuning voor netflow-exportfuncties Cisco-routers Systems, Mikrotik en enkele anderen. Soortgelijke functionaliteit (met andere exportprotocollen) wordt door iedereen ondersteund grote fabrikanten netwerkapparatuur.

Libpdop “buiten”

Laten we de taak een beetje ingewikkelder maken. Wat moet ik doen als uw toegangsapparaat - hardware-router een andere fabrikant? Bijvoorbeeld D-Link, ASUS, Trendnet, enz. Het is hoogstwaarschijnlijk onmogelijk om extra te installeren softwaretool gegevensverzameling. Het is ook mogelijk dat u een slim toegangsapparaat heeft, maar dat u dit niet kunt configureren (u heeft geen rechten of het wordt beheerd door uw provider). In dit geval kunt u verkeersinformatie direct verzamelen op het punt waar het toegangsapparaat samenkomt intern netwerk, met behulp van “hardware” middelen voor het kopiëren van pakketten. In dit geval hebt u zeker een aparte server met een speciale netwerkkaart nodig om kopieën van Ethernet-pakketten te ontvangen.
De server moet het pakketverzamelingsmechanisme gebruiken met behulp van de hierboven beschreven libpcap-methode, en onze taak is om een datastroom die identiek is aan die afkomstig van de toegangsserver naar de ingang van de netwerkkaart te sturen die speciaal voor dit doel is bestemd. Hiervoor kunt u gebruik maken van:

Ethernet – hub (hub): een apparaat dat eenvoudigweg zonder onderscheid pakketten tussen al zijn poorten doorstuurt. IN moderne realiteiten het staat ergens in een stoffig pakhuis en het gebruik van deze methode wordt afgeraden: onbetrouwbaar, lage snelheid (er zijn geen hubs met een snelheid van 1 Gbit/s)
Ethernet - een switch met de mogelijkheid om te spiegelen (mirroring, SPAN-poorten). Met moderne slimme (en dure) switches kunt u al het verkeer (inkomend, uitgaand, beide) van een ander naar een opgegeven poort kopiëren fysieke interface, VLAN, inclusief afstandsbediening (RSPAN)
Een hardwaresplitter, waarvoor mogelijk installatie nodig is om er twee te verzamelen netwerkkaarten in plaats van één - en dit is een aanvulling op de hoofdsysteem.

Uiteraard kunt u een SPAN-poort configureren op het toegangsapparaat zelf (router), als dit dit toestaat: Cisco Catalyst 6500, Cisco ASA. Hier is een voorbeeld van een dergelijke configuratie voor Cisco-schakelaar:
monitorsessie 1 bron vlan 100! waar halen we de pakketten vandaan?
monitorsessie 1 bestemmingsinterface Gi6/3! waar geven wij pakketten uit?

SNMP

Wat als we geen router onder onze controle hebben, we geen contact willen opnemen met netflow, we zijn niet geïnteresseerd in de details van het verkeer van onze gebruikers. Ze zijn eenvoudigweg verbonden met het netwerk via een beheerde switch, en we hoeven alleen maar een ruwe schatting te maken van de hoeveelheid verkeer die naar elk van de poorten gaat. Zoals u weet, ondersteunen netwerkapparaten met afstandsbediening en kunnen tellers van pakketten (bytes) worden weergegeven die passeren netwerkinterfaces. Om ze te onderzoeken, zou het correct zijn om te gebruiken gestandaardiseerd protocol SNMP-beheer op afstand. Hiermee kunt u vrij eenvoudig niet alleen de waarden van de opgegeven tellers verkrijgen, maar ook andere parameters, zoals de naam en beschrijving van de interface, MAC-adressen die erdoor zichtbaar zijn en andere nuttige informatie. Dit wordt gedaan door nutsbedrijven opdrachtregel(snmpwalk), grafische SNMP-browsers en meer complexe programma's netwerkmonitoring (rrdtools, cactussen, zabbix, whats up gold, enz.). Deze methode heeft echter twee belangrijke nadelen:

Verkeersblokkering kan alleen worden gedaan door volledige afsluiting interface, waarbij dezelfde SNMP wordt gebruikt
verkeerstellers genomen via SNMP verwijzen naar de som van de lengtes van Ethernet-pakketten (unicast, broadcast en multicast afzonderlijk), terwijl de rest van de eerder beschreven tools waarden geven ten opzichte van IP-pakketten. Dit creëert een merkbare discrepantie (vooral bij korte pakketten) vanwege de overhead veroorzaakt door de lengte van de Ethernet-header (dit kan echter ongeveer worden bestreden: L3_byte = L2_byte - L2_packets * 38).

VPN

Daarnaast is het de moeite waard om het geval van gebruikerstoegang tot het netwerk te overwegen door expliciet een verbinding tot stand te brengen met de toegangsserver. Een klassiek voorbeeld is de goede oude inbelverbinding, waarvan een analoog is moderne wereld zijn VPN-diensten toegang op afstand(PPTP, PPPoE, L2TP, OpenVPN, IPSEC)

Het toegangsapparaat routeert niet alleen het IP-verkeer van gebruikers, maar fungeert ook als een gespecialiseerde VPN-server en beëindigt logische tunnels (vaak gecodeerd) waarbinnen gebruikersverkeer wordt verzonden.
Om dergelijk verkeer te verwerken, kunt u zowel alle hierboven beschreven tools gebruiken (en deze zijn zeer geschikt voor diepgaande analyse van poorten/protocollen), als aanvullende mechanismen, die VPN-toegangscontroles bieden. Allereerst we zullen praten over het RADIUS-protocol. Zijn werk is een tamelijk complex onderwerp. We zullen kort vermelden dat de controle (autorisatie) van toegang tot de VPN-server (RADIUS-client) wordt gecontroleerd door speciale toepassing(RADIUS-server), waar een database achter zit ( tekstbestand SQL Actieve map) stonden gebruikers toe met hun attributen (limieten voor verbindingssnelheid, toegewezen IP-adressen). Naast het autorisatieproces verzendt de client periodiek boekhoudberichten naar de server, informatie over de status van elke momenteel lopende VPN-sessie, inclusief tellers van overgedragen bytes en pakketten.

Conclusie

Laten we alle hierboven beschreven methoden voor het verzamelen van verkeersinformatie samenbrengen:

Laten we het samenvatten. In de praktijk zijn er een groot aantal methoden om het netwerk dat u beheert (met klanten of kantoorabonnees) te verbinden met een externe netwerkinfrastructuur, met behulp van een aantal toegangshulpmiddelen: software- en hardwarerouters, switches, VPN-servers. In vrijwel elk geval kunt u echter een schema bedenken waarbij informatie over het verkeer dat via het netwerk wordt verzonden, naar software of andere netwerken kan worden geleid. hardware de analyse en het beheer ervan. Het is ook mogelijk dat deze tool dit mogelijk maakt feedback met een toegangsapparaat dat gebruikt intelligente algoritmen toegangsbeperkingen voor individuele clients, protocollen en andere zaken.
Hier rond ik de analyse van het materiaal af. De resterende onbeantwoorde onderwerpen zijn:

hoe en waar de verzamelde verkeersgegevens naartoe gaan
verkeersboekhoudsoftware
Wat is het verschil tussen facturering en een eenvoudig “loket”
Hoe kunt u verkeersbeperkingen opleggen?
boekhouding en beperking van bezochte websites

Overdracht van IP-verkeer over SDH-netwerken, of heeft u dat? ATM-alternatief?

Oleg ALLENOV
AMT-groep

Er is veel discussie over wat transporttechnologieën zal in hoge snelheid naar voren komen multimedia netwerken bijvoorbeeld internet. En hoewel de meerderheid van de betwisters vóór ATM stemt, is niet iedereen het met dit standpunt eens. Een andere, alternatieve optie voor het bouwen van multimedia-transportnetwerken is ook mogelijk: het gebruik van het IP-protocol (Internet Protocol) met directe inkapseling in een synchroon netwerk digitale hiërarchie(SDH).

IP wordt al meer dan 15 jaar gebruikt, terwijl ATM een relatief nieuw protocol is. Tijdens zijn bestaan is het IP-internet getransformeerd van een verenigd wetenschappelijk netwerk van geïsoleerde universiteitscampussen naar een enorm computernetwerk dat de hele planeet bestreek. Het steeds toenemende aantal internetgebruikers (nu in de miljoenen) en de groeiende vraag naar bandbreedte dreigen ertoe te leiden dat het netwerk de belasting niet langer aankan. Nieuwe multimediatoepassingen stellen veel hogere eisen aan de beschikbare bandbreedte, vaak in realtime. Dit dwingt ons om de bestaande benaderingen voor het opbouwen van de internetinfrastructuur te heroverwegen.

Om de internetcapaciteit te vergroten is in de eerste plaats snel “transport” nodig. Eén optie is het gebruik van de populaire ATM-technologie. Opgemerkt moet worden dat als transportprotocol ATM veroorzaakt steeds meer kritiek van zowel apparatuurfabrikanten als eindgebruikers. We zullen proberen de tekortkomingen van ATM in meer detail te analyseren en de argumenten te overwegen ten gunste van een andere methode voor het verzenden van internetverkeer: directe inkapseling TCP-protocollen/IP naar SONET/SDH-protocollen.

ATM-technologie

Asynchrone overdrachtsmodus, ATM, werd geïntroduceerd bij fabrikanten en providers netwerkdiensten als een technologie die het mogelijk maakt om op aanvraag de nodige bandbreedte en gegarandeerde servicekwaliteit te leveren aan een breed scala aan multimediatoepassingen, waaronder internet op de eerste plaats. Dus niet het meest recente deel van de ATM-componenten was specifiek gericht en ontworpen voor het vervoeren van internetverkeer. Het was de bedoeling dat het netwerk in de nabije toekomst grotendeels zou bestaan uit ATM-gebruikers en LANE-clients (LANE-emulatie), waardoor een gemakkelijke en natuurlijke migratie van internettoepassingen naar het nieuwe transportprotocol mogelijk zou worden, dat grenzeloze mogelijkheden beloofde.

Maar (misschien vanwege de hoge kosten van nieuwe oplossingen of hun anorganische aard) gebeurde dit om de een of andere reden niet. Bovendien is de tendens om de invloed van TCP/IP-protocollen, specifiek als transportprotocollen, steeds duidelijker te worden.

De TCP/IP-protocolstack is inderdaad al lang ontwikkeld en getest; er is veel geld en moeite geïnvesteerd in het maken en debuggen ervan. Hoewel het IPv4-protocol bepaalde tekortkomingen heeft, zal de komende IPv6-versie de meeste daarvan elimineren. Echter, bestaande versie IPv4 is ook geschikt voor veel mensen en kan volgens deskundigen nog enkele jaren meegaan. Een behoorlijk aantal fabrikanten beschouwt IP als een veelbelovend transportprotocol voor de moderne telecommunicatie-infrastructuur. Wat heeft ATM ermee te maken?

ATM werd door de ITU-T voorgesteld als de basistechnologie voor breedband ISDN (of B-ISDN). Omdat B-ISDN primair is ontworpen om multimediaverkeer te vervoeren, was ATM goed gepositioneerd om dit soort verkeer in echte netwerken te ondersteunen.

Er ging enige tijd voorbij en fabrikanten van telecommunicatieapparatuur richtten hun aandacht op ATM. Het ATM-forum werd opgericht, dat de nieuwe technologie tot leven begon te brengen. Tegelijkertijd waren de taken die aan het ATM Forum waren toegewezen het standaardiseren en ontwikkelen van een effectief schaalbaar protocol dat verkeer met diametraal tegenovergestelde kenmerken (multimedia) ondersteunt, een bepaalde kwaliteit van de dienstverlening (QoS) garandeert en multicast-uitzendingen ondersteunt. Daarnaast, dit protocol moet compatibel zijn met bestaande technologieën LAN en WAN.

Het moet duidelijk zijn dat ATM-technologie juist zo wijdverspreid populair werd vanwege de algemene overtuiging dat de bestaande technologieën op dat moment niet in staat waren om aan de bovengenoemde vereisten te voldoen.

IP-technologie

IP lijkt daarentegen geen oud protocol dat vergeten mag worden. Er zijn over de hele wereld een groot aantal IP over Ethernet-oplossingen geïnstalleerd, en het is helemaal niet eenvoudig om klanten ervan te overtuigen goedkope Ethernet-kaarten weg te gooien en ATM-adapters te installeren zonder fundamenteel nieuwe mogelijkheden of op zijn minst meer mogelijkheden te beloven. hoge snelheden(de snelheidsverhoging is geenszins duidelijk).

Ik denk dat veel klanten die ervaring hebben met het gebruik van ATM-adapters voor pc's het met mij eens zullen zijn dat een Fast Ethernet 100 Mbps netwerkkaart (om nog maar te zwijgen van Full Duplex) werkt ten minste niet langzamer dan een 155 Mbps ATM-adapter. Dit komt door de grotere redundantie van het ATM-protocol en vertragingen bij de montage/demontage van de cellen. Wat de gegarandeerde servicekwaliteit van ATM betreft, deze is praktisch niet geïmplementeerd in LANE, en AAL5 UBR (maximaal UBR+ of ABR) wordt nu gebruikt om IP-verkeer via ATM te verzenden. Het is dus niet nodig om over QoS te praten.

Ongetwijfeld nieuwe technologie moet een breed scala aan servicekwaliteitsniveaus ondersteunen. IP werd echter gekozen als het protocol voor universeel internetwerken en werkte halverwege de jaren tachtig goed op het toen 20.000 computers tellende internet en verbindt vandaag de dag nog steeds met succes miljoenen hosts. Is IP echt achterhaald? Voorstanders van ATM zouden waarschijnlijk ja antwoorden.

Er zijn enorme hoeveelheden geld geïnvesteerd in de ontwikkeling van een familie van internetprotocollen en deze in de huidige staat gebracht. Niet alleen het ATM Forum is actief, maar ook de IETF (Internet Engineering Task Force) - de zoektocht naar manieren om IP te gebruiken in de opkomende gaat door. Er zijn protocollen gemaakt ter ondersteuning van multicast-uitzendingen (IGMP, DVMRP, PIM) en protocollen die resourcereservering voor verkeerstransmissie (RSVP) mogelijk maken. Het is mogelijk om routering uit te voeren (hoewel nog niet zo flexibel als bij het gebruik van PNNI) op basis van de vereiste kwaliteit van de dienstverlening (Tag Switching) en de MPLS-standaard (Multiprotocol Label Switching), die wordt voorbereid voor release in de IETF. zal de interoperabiliteit garanderen van alle apparaten die tag-switching ondersteunen, en zal waarschijnlijk de positie van MPOA (Multiprotocol Over ATM) aanzienlijk verdringen.

Heeft het dus zin om de gevestigde IP-technologie te vervangen door de opkomende ATM?

IP via geldautomaat

Aanvankelijk werd het idee om IP over ATM te verzenden beschouwd als een mogelijke manier om ATM in de bestaande internetarchitectuur te introduceren en vervolgens IP volledig te vervangen. Nu we begrijpen dat ATM IP niet volledig kan vervangen, kunnen we de vraag stellen: waarom zijn er nog geen effectieve methoden ontwikkeld voor het transporteren van IP-verkeer via ATM? Blijkbaar wordt aangenomen dat ATM een unieke snelle schakeltechnologie biedt die dit probleem kan oplossen bestaande problemen gebrek aan internetbandbreedte. In werkelijkheid zijn er hier echter enkele problemen.

Laten we allereerst aandacht besteden aan het feit dat bijna alle (op zeldzame uitzonderingen na, bijvoorbeeld ATM25, TAXI, enz.) fysieke interfaces van ATM-schakelaars werken in het SDH/SONET/PDH-frameformaat. Dit wordt gedaan om de integratie met wijdverbreide SDH-transportnetwerken te vergemakkelijken. Maar zelfs als SDH volledig afwezig is en niet in het ontwerp is voorzien, wordt er nog steeds SDH-overhead geïntroduceerd in de transmissie van gebruikersverkeer, wat, op zijn zachtst gezegd, de snelheid en prestaties van het netwerk niet verhoogt.

Het is ook passend om op te merken dat SDH een synchrone transmissiemethode is, terwijl ATM asynchroon is. Bij het verzenden van ATM-verkeer via transportnetwerken Met SDH verliezen we alle voordelen van de asynchrone celoverdrachtmethode, om nog maar te zwijgen van de duplicatie van een aantal functies (bijvoorbeeld OA&M).

De inkapseling van IP in ATM, dat op zijn beurt via SDH werkt, verbetert de situatie niet. Het ATM-protocol is verbindingsgericht, terwijl IP dat niet is. Deze discrepantie leidt ook tot extra complexiteit en duplicatie van een aantal functies.

Elk van de protocollen, IP en ATM, vereist dus zijn eigen routeringsprotocol. Er zijn aanvullende controlefuncties nodig om de gezamenlijke werking van IP en ATM te controleren. De efficiëntie van de transmissie van multicast-verkeer neemt af, omdat zonder kennis van de exacte netwerktopologie op de lagere lagen de transmissie van multicast-pakketten verandert in het eenvoudig kopiëren ervan op edge-routers. Dergelijke pakketten worden gedistribueerd op manieren die verre van optimaal zijn echt netwerk trajecten.

Het is niet nodig om stil te staan bij de nadelen van lokale netwerkemulatiemethoden, aangezien elke gekwalificeerde netwerkspecialist het erover eens zal zijn dat LANE-technologie niet organisch en veelbelovend kan worden genoemd. Vanuit veel gezichtspunten is deze technologie een mislukte poging om protocollen die zijn ontworpen voor broadcastomgevingen, te laten werken in een omgeving waar een dergelijke gegevensoverdrachtsmodus onmogelijk is (NBMA, Nonbroadcast Multiple Access).

Dus als het internet nog steeds zichzelf is en gebaseerd blijft op IP, is er dan behoefte aan een extra ‘laag’ in de vorm van ATM tussen IP en het werkelijk efficiënte, werkelijk snelle SDH-transportprotocol, dat net zo goed functioneert? om bijna elk soort verkeer te vervoeren?

IP via SDH

SDH-technologie wordt veel gebruikt om betrouwbaar transport te organiseren. SDH is ontwikkeld om een standaardprotocol te bieden voor interoperabiliteit tussen providers; verenig Amerikaanse, Europese en Japanse digitale systemen; zorgen voor multiplexing digitale signalen bij gigabitsnelheden; ondersteuning bieden voor OA&M-functies (bediening, beheer en onderhoud).

Hoewel SDH met frames werkt en vanuit het oogpunt een eigen kanaalstructuur heeft netwerklaag SDH is slechts een stroom octetten. Om een IP-pakket correct in een SDH-container te kunnen insluiten, is het noodzakelijk om de grenzen van het pakket (of de groep pakketten) binnen de synchrone transportmodule STM (synchrone transportmodule) duidelijk te definiëren. Met andere woorden: er is een protocollaag nodig tussen IP en SDH om frames op linkniveau te vormen.

Omdat SDH point-to-point-verbindingen biedt, kan het als tussenproduct worden gebruikt PPP-protocol(Point-to-Point Protocol) lijkt vrij logisch. PPP wordt op internet veel gebruikt als een link-layer-protocol voor het organiseren van verbindingen mondiale netwerken. Bovendien kunt u met PPP extra functies van het PPP-protocol gebruiken:

mogelijkheid tot inkapseling van meerdere protocollen;
bescherming tegen fouten;
gebruik van het LCP-protocol voor het tot stand brengen, configureren en testen van link-layer-verbindingen;
de mogelijkheid om de NCP-protocolfamilie te gebruiken om verschillende netwerkprotocollen te ondersteunen en te configureren.

Er moet echter worden opgemerkt dat als netwerkprotocol voor ons is nu alleen IP van belang, en bovendien zijn een aantal functies van het NCP-protocol (bijvoorbeeld dynamische toewijzing van IP-adressen) in ons geval niet relevant. Waar we echt in geïnteresseerd zijn, is het inkapselen van IP in PPP en het vervolgens plaatsen van PPP-frames in SDH.

IP-inkapseling in PPP is geen probleem, omdat het goed ingeburgerd is en op grote schaal wordt gebruikt. De inkapselingsprocedure van PPP naar SDH (gedefinieerd als padsignaallabel = 207hex), weergegeven in de afbeelding, moet worden uitgevoerd door een speciale serviceadapter op SDH-padniveau. De serviceadapter kan een "black box" zijn die een stroom PPP-frames ontvangt en een stroom STM-transportmodules "produceert". PPP is zeer geschikt voor het werken met SDH, omdat beide protocollen gericht zijn op het werken in de single-byte-modus.

Door het internetverkeer direct in te kapselen in de bestaande SDH-transportdienst, vereenvoudigen we de complexe netwerkinfrastructuur aanzienlijk, waardoor de kosten worden verlaagd en de effectieve doorvoer wordt vergroot. Met de komst van nieuwe mogelijkheden voor het verzenden van IP-verkeer met gigabit-snelheden (Gigabit Ethernet) en snelle schakeltechnologieën voor IP-pakketten (Multiprotocol Label Switching - MPLS), is het gebruik van het IP-protocol als basis van een uniforme transportdienst voor het verzenden van video, telefonie en andere multimediatoepassingen worden werkelijkheid - gelukkig is het grootste deel van het werk aan de implementatie van het IP-protocol in Wereld wijde web is al voltooid. In dit verband is de opkomst van standaarden (RFC 1619) en de eerste praktische implementaties van interfaces zoals “PPP over SDH” (of Packets Over Sonet - POS) op moderne routers bedoeld voor internet, in het bijzonder de GSR 12000 van Cisco Systems , lijkt zeer actueel.

Concluderend zou ik willen opmerken dat de auteur op geen enkele manier het belang van ATM-technologie wil bagatelliseren en de positieve impact ervan op de ontwikkeling van mondiale telecommunicatiediensten wil ontkennen. Hij vond het gewoon interessant om op een discursieve manier de mogelijkheid te overwegen van alternatieve manieren om multimediadiensten te ontwikkelen, anders dan asynchrone celoverdrachttechnologie.

OVER DE AUTEUR

Oleg Allenov - instructeur opleidingscentrum AMT-groep, CCSI/CCIE. Hij is telefonisch bereikbaar. 725 - 7660

Bekeken: 3498

Elke beheerder krijgt vroeg of laat instructies van het management: “tel wie er online gaat en hoeveel ze downloaden.” Voor aanbieders wordt het aangevuld met de taken van “het binnenlaten van iedereen die het nodig heeft, het aannemen van betalingen, het beperken van de toegang.” Wat te tellen? Hoe? Waar? Er is veel fragmentarische informatie, deze is niet gestructureerd. We zullen de beginnende beheerder behoeden voor vervelende zoekopdrachten door hem algemene kennis en nuttige links naar hardware te bieden.
In dit artikel zal ik proberen de principes te beschrijven van het organiseren van de verzameling, boekhouding en controle van verkeer op het netwerk. We zullen het probleem bekijken en mogelijke manieren opsommen om informatie van netwerkapparaten op te halen.

Dit is het eerste theoretische artikel in een reeks artikelen gewijd aan het verzamelen, boekhouden, beheren en factureren van verkeer en IT-middelen.

Structuur van internettoegang

Over het algemeen ziet de netwerktoegangsstructuur er als volgt uit:

Externe bronnen - het internet, met alle sites, servers, adressen en andere zaken die niet tot het netwerk behoren dat u beheert.

Toegangsapparaat - router (hardware of pc-gebaseerd), switch, VPN-server of concentrator.

Interne bronnen zijn een reeks computers, subnetten en abonnees waarvan de werking op het netwerk in aanmerking moet worden genomen of gecontroleerd.

Een beheer- of boekhoudserver is een apparaat waarop gespecialiseerde software draait. Functioneel te combineren met een softwarerouter.

In deze structuur gaat netwerkverkeer van externe bronnen naar interne bronnen, en terug, via het toegangsapparaat. Het verzendt verkeersinformatie naar de beheerserver. De controleserver verwerkt deze informatie, slaat deze op in de database, geeft deze weer en geeft blokkeeropdrachten. Niet alle combinaties van toegangsapparaten (methoden) en verzamel- en controlemethoden zijn echter compatibel. De verschillende opties zullen hieronder worden besproken.

Netwerkverkeer

Eerst moet u definiëren wat wordt bedoeld met ‘netwerkverkeer’ en welke nuttige statistische informatie uit de stroom gebruikersgegevens kan worden gehaald.
Het dominante internetwerkprotocol blijft. Het IP-protocol komt overeen met laag 3 (L3). De informatie (gegevens) tussen de afzender en de ontvanger wordt verpakt in pakketten - met een header en een "payload". De header bepaalt waar het pakket vandaan komt en waar het naartoe gaat (IP-adressen van afzender en ontvanger), pakketgrootte en type payload. Het grootste deel van het netwerkverkeer bestaat uit UDP- en TCP-payloadpakketten - dit zijn Layer 4 (L4)-protocollen. Naast adressen bevat de header van deze twee protocollen poortnummers, die bepalen welk type dienst (applicatie) gegevens verzendt.

Om een IP-pakket via draden (of radio) te verzenden, worden netwerkapparaten gedwongen het in een Layer 2 (L2)-protocolpakket te “verpakken” (inkapselen). Het meest voorkomende protocol van dit type is . De daadwerkelijke transmissie “naar de draad” vindt plaats op het 1e niveau. Normaal gesproken analyseert het toegangsapparaat (router) geen pakketheaders op niveaus hoger dan niveau 4 (een uitzondering vormen intelligente firewalls).
Informatie uit de velden van adressen, poorten, protocollen en lengtetellers uit de L3- en L4-headers van datapakketten vormen de ‘grondstof’ die wordt gebruikt bij verkeersadministratie en -beheer. De daadwerkelijke hoeveelheid verzonden informatie vindt u in het veld Lengte van de IP-header (inclusief de lengte van de header zelf). Trouwens, als gevolg van pakketfragmentatie als gevolg van dit mechanisme is het totale volume van de verzonden gegevens altijd groter dan de omvang van de payload.

De totale lengte van de IP- en TCP/UDP-velden van het pakket die voor ons in deze context interessant zijn, is 2...10% van de totale lengte van het pakket. Als je al deze informatie batch voor batch verwerkt en opslaat, zijn er niet genoeg middelen. Gelukkig is het overgrote deel van het verkeer zo gestructureerd dat het bestaat uit een reeks ‘gesprekken’ tussen externe en interne netwerkapparaten, die ‘stromen’ worden genoemd. Als onderdeel van een bewerking waarbij een e-mail wordt verzonden (SMTP-protocol), wordt bijvoorbeeld een TCP-sessie geopend tussen de client en de server. Het wordt gekenmerkt door een constante reeks parameters (bron-IP-adres, bron-TCP-poort, doel-IP-adres, bestemming-TCP-poort). In plaats van informatie pakketje voor pakketje te verwerken en op te slaan, is het veel handiger om stroomparameters (adressen en poorten) op te slaan, evenals aanvullende informatie - het aantal en de som van de pakketlengtes die in elke richting worden verzonden, optioneel sessieduur, routerinterface indexen, ToS-veldwaarde, enz. Deze aanpak is gunstig voor verbindingsgerichte protocollen (TCP), waarbij het mogelijk is om de beëindiging van een sessie expliciet te onderscheppen. Zelfs voor niet-sessiegerichte protocollen is het echter mogelijk om aggregatie en logische voltooiing van een stroomrecord uit te voeren op basis van bijvoorbeeld een time-out. Hieronder vindt u een fragment uit de SQL-database die informatie over verkeersstromen registreert:

Er moet rekening worden gehouden met het geval waarin het toegangsapparaat adresvertaling (masquerading) uitvoert om internettoegang voor computers op het lokale netwerk te organiseren met behulp van één extern, openbaar IP-adres. In dit geval vervangt een speciaal mechanisme IP-adressen en TCP/UDP-poorten van verkeerspakketten, waarbij interne (niet routeerbare op internet) adressen worden vervangen volgens de dynamische vertaaltabel. In deze configuratie is het noodzakelijk om te onthouden dat om gegevens op interne netwerkhosts correct vast te leggen, statistieken moeten worden verzameld op een manier en op een plaats waar het vertaalresultaat de interne adressen nog niet “anonimiseert”.

Methoden voor het verzamelen van verkeers-/statistische informatie

PC-router

Laten we het eenvoudigste geval bekijken: een toegangsapparaat (router) op basis van een pc met Linux.

Over het opzetten van zo’n server, adresvertaling en routing. We zijn geïnteresseerd in de volgende logische stap: informatie over hoe u informatie kunt verkrijgen over het verkeer dat door zo'n server gaat. Er zijn drie veel voorkomende methoden:

het onderscheppen (kopiëren) van pakketten die via de netwerkkaart van de server gaan met behulp van de bibliotheek

het onderscheppen van pakketten die door de ingebouwde firewall gaan

het gebruik van tools van derden voor het omzetten van pakket-voor-pakket-statistieken (verkregen door een van de twee voorgaande methoden) in een geaggregeerde netflow-informatiestroom

Libkap

In het eerste geval kan een kopie van het pakket dat door de interface gaat, nadat het filter () is gepasseerd, worden opgevraagd door een clientprogramma op de server dat met behulp van deze bibliotheek is geschreven. Het pakket arriveert met een laag 2-header (Ethernet). Het is mogelijk om de lengte van de vastgelegde informatie te beperken (als we alleen geïnteresseerd zijn in informatie uit de header). Voorbeelden van dergelijke programma's kunnen zijn. Er is een implementatie. Als adresvertaling wordt gebruikt op een pc-router, kan een dergelijke onderschepping alleen worden uitgevoerd op de interne interface die is verbonden met lokale gebruikers. Op de externe interface bevatten IP-pakketten na vertaling geen informatie over de interne hosts van het netwerk. Met deze methode is het echter onmogelijk om rekening te houden met het verkeer dat door de server zelf op internet wordt gegenereerd (wat belangrijk is als er een web- of e-mailservice op draait).

open de gewenste interface

specificeer het filter waardoor ontvangen pakketten moeten worden doorgegeven, de grootte van het vastgelegde deel (snaplen), de buffergrootte,

stel de promisc-parameter in, die de netwerkinterface in de capture-modus zet voor alle pakketten die passeren, en niet alleen voor de pakketten die zijn geadresseerd aan het MAC-adres van deze interface

stel een functie (callback) in die voor elk ontvangen pakket wordt aangeroepen.

Wanneer een pakket via de geselecteerde interface wordt verzonden, ontvangt deze functie, nadat het filter is gepasseerd, een buffer met daarin Ethernet, (VLAN), IP, enz. headers, totale grootte tot snaplen. Omdat de libcap-bibliotheek pakketten kopieert, kan deze niet worden gebruikt om de doorgang ervan te blokkeren. In dit geval zal het programma voor het verzamelen en verwerken van verkeer alternatieve methoden moeten gebruiken, zoals het aanroepen van een script om een bepaald IP-adres in een verkeersblokkeringsregel te plaatsen.

Firewall

Door gegevens vast te leggen die door de firewall gaan, kunt u rekening houden met zowel het verkeer van de server zelf als het verkeer van netwerkgebruikers, zelfs als de adresvertaling actief is. Het belangrijkste in dit geval is om de capture-regel correct te formuleren en op de juiste plaats te plaatsen. Deze regel activeert de overdracht van het pakket naar de systeembibliotheek, vanwaar de toepassing voor verkeersadministratie en -beheer het kan ontvangen. Voor Linux OS wordt iptables gebruikt als firewall, en onderscheppingstools zijn ipq, of. Voor OC FreeBSD - ipfw met regels zoals . In ieder geval wordt het firewallmechanisme aangevuld met de mogelijkheid om op de volgende manier met een gebruikersprogramma te werken:

Een gebruikersprogramma - een verkeersafhandelaar - registreert zichzelf in het systeem met behulp van een systeemoproep of een bibliotheek.

Een gebruikersprogramma of extern script installeert een regel in de firewall, waarbij het geselecteerde verkeer (volgens de regel) in de handler wordt 'ingepakt'.

Voor elk passerend pakket ontvangt de handler de inhoud ervan in de vorm van een geheugenbuffer (met IP-headers, enz.) Na verwerking (accounting) moet het programma de kernel van het besturingssysteem ook vertellen wat het vervolgens met zo'n pakket moet doen - verwijder het of doorgeven. Als alternatief is het mogelijk het gewijzigde pakket door te geven aan de kernel.

Omdat het IP-pakket niet wordt gekopieerd, maar ter analyse naar de software wordt gestuurd, wordt het mogelijk om het te ‘uitwerpen’ en daardoor het verkeer van een bepaald type (bijvoorbeeld naar een geselecteerde lokale netwerkabonnee) geheel of gedeeltelijk te beperken. Als het applicatieprogramma echter niet meer reageert op de kernel over zijn beslissing (bijvoorbeeld vastloopt), wordt het verkeer via de server eenvoudigweg geblokkeerd.
Opgemerkt moet worden dat de beschreven mechanismen, met aanzienlijke hoeveelheden verzonden verkeer, een overmatige belasting van de server veroorzaken, wat gepaard gaat met het voortdurend kopiëren van gegevens van de kernel naar het gebruikersprogramma. De methode voor het verzamelen van statistieken op het kernelniveau van het besturingssysteem heeft dit nadeel niet, omdat geaggregeerde statistieken naar het applicatieprogramma worden verzonden met behulp van het protocol.

Netstroom

Dit protocol is ontwikkeld door Cisco Systems om verkeersinformatie van routers te exporteren ten behoeve van verkeersregistratie en -analyse. De meest populaire biedt de ontvanger nu een stroom gestructureerde gegevens in de vorm van UDP-pakketten met informatie over eerder verkeer in de vorm van zogenaamde stroomrecords:

De hoeveelheid informatie over het verkeer is enkele ordes van grootte kleiner dan het verkeer zelf, wat vooral belangrijk is in grote en gedistribueerde netwerken. Het is uiteraard onmogelijk om de overdracht van informatie te blokkeren bij het verzamelen van statistieken via netflow (tenzij er aanvullende mechanismen worden gebruikt).
Momenteel wordt een verdere ontwikkeling van dit protocol populair: versie 9, gebaseerd op de sjabloonstroomrecordstructuur, implementatie voor apparaten van andere fabrikanten (). Onlangs is de IPFIX-standaard aangenomen, waarmee statistieken via protocollen op diepere niveaus (bijvoorbeeld per applicatietype) kunnen worden verzonden.
De implementatie van netflow-bronnen (agents, probes) is beschikbaar voor pc-routers, zowel in de vorm van hulpprogramma's die werken volgens de hierboven beschreven mechanismen (flowprobe,) als rechtstreeks ingebouwd in de OS-kernel (FreeBSD:, Linux:). Voor softwarerouters kan de netflow-statistiekenstroom lokaal op de router zelf worden ontvangen en verwerkt, of via het netwerk (overdrachtsprotocol - via UDP) naar het ontvangende apparaat (collector) worden verzonden.

Het verzamelprogramma kan informatie uit vele bronnen tegelijk verzamelen, waardoor het verkeer zelfs met overlappende adresruimten kan worden onderscheiden. Met behulp van aanvullende tools is het bijvoorbeeld ook mogelijk om extra dataaggregatie, streambifurcatie of protocolconversie uit te voeren, wat belangrijk is bij het beheren van een groot en gedistribueerd netwerk met tientallen routers.

Netflow-exportfuncties ondersteunen routers van Cisco Systems, Mikrotik en enkele anderen. Soortgelijke functionaliteit (met andere exportprotocollen) wordt ondersteund door alle grote fabrikanten van netwerkapparatuur.

Libpcap in “buiten”

Laten we de taak een beetje ingewikkelder maken. Wat moet ik doen als uw toegangsapparaat een hardwarerouter van een andere fabrikant is? Bijvoorbeeld D-Link, ASUS, Trendnet, enz. Het is hoogstwaarschijnlijk onmogelijk om er extra software voor gegevensverzameling op te installeren. Het is ook mogelijk dat u een slim toegangsapparaat heeft, maar dat u dit niet kunt configureren (u heeft geen rechten of het wordt beheerd door uw provider). In dit geval kunt u informatie over het verkeer rechtstreeks verzamelen op het punt waar het toegangsapparaat het interne netwerk ontmoet, met behulp van 'hardware' pakketkopieerhulpmiddelen. In dit geval hebt u zeker een aparte server met een speciale netwerkkaart nodig om kopieën van Ethernet-pakketten te ontvangen.
De server moet het pakketverzamelingsmechanisme gebruiken met behulp van de hierboven beschreven libpcap-methode, en onze taak is om een datastroom die identiek is aan die afkomstig van de toegangsserver naar de ingang van de netwerkkaart te sturen die speciaal voor dit doel is bestemd. Hiervoor kunt u gebruik maken van:

Ethernet - hub (hub): een apparaat dat eenvoudigweg zonder onderscheid pakketten tussen al zijn poorten doorstuurt. In de moderne realiteit kan het ergens in een stoffig pakhuis worden gevonden, en het gebruik van deze methode wordt niet aanbevolen: onbetrouwbaar, lage snelheid (er zijn geen hubs met een snelheid van 1 Gbit/s)

Ethernet - een switch met spiegelmogelijkheden. Met moderne slimme (en dure) switches kunt u al het verkeer (inkomend, uitgaand, beide) van een andere fysieke interface, VLAN, inclusief extern (RSPAN) naar een opgegeven poort kopiëren.

Hardware, waarvoor mogelijk de installatie van twee netwerkkaarten nodig is in plaats van één om te verzamelen - en dit is een aanvulling op de hoofdsysteemkaart.

Uiteraard kunt u een SPAN-poort configureren op het toegangsapparaat zelf (router), als dit dit toestaat: Cisco Catalyst 6500, Cisco ASA. Hier is een voorbeeld van een dergelijke configuratie voor een Cisco-switch:
monitorsessie 1 bron vlan 100! waar halen we de pakketten vandaan?
monitorsessie 1 bestemmingsinterface Gi6/3! waar geven wij pakketten uit?

SNMP

Wat als we geen router onder onze controle hebben, we geen contact willen opnemen met netflow, we zijn niet geïnteresseerd in de details van het verkeer van onze gebruikers. Ze zijn eenvoudigweg verbonden met het netwerk via een beheerde switch, en we hoeven alleen maar een ruwe schatting te maken van de hoeveelheid verkeer die naar elk van de poorten gaat. Zoals u weet, ondersteunen netwerkapparaten met afstandsbediening en kunnen ze tellers weergeven van pakketten (bytes) die via netwerkinterfaces gaan. Om ze te ondervragen zou het juist zijn om een gestandaardiseerd afstandsbedieningsprotocol te gebruiken. Hiermee kunt u vrij eenvoudig niet alleen de waarden van de opgegeven tellers verkrijgen, maar ook andere parameters, zoals de naam en beschrijving van de interface, MAC-adressen die erdoor zichtbaar zijn en andere nuttige informatie. Dit wordt gedaan door opdrachtregelhulpprogramma's (), grafische SNMP-browsers en complexere netwerkbewakingsprogramma's (, enz.). Deze methode heeft echter twee belangrijke nadelen:

het blokkeren van verkeer kan alleen worden gedaan door de interface volledig uit te schakelen, met behulp van dezelfde SNMP

verkeerstellers genomen via SNMP verwijzen naar de som van de lengtes van Ethernet-pakketten (unicast, broadcast en multicast afzonderlijk), terwijl de rest van de eerder beschreven tools waarden geven ten opzichte van IP-pakketten. Dit creëert een merkbare discrepantie (vooral bij korte pakketten) vanwege de overhead veroorzaakt door de lengte van de Ethernet-header (dit kan echter ongeveer worden bestreden: L3_byte = L2_byte - L2_packets * 38).

VPN

Daarnaast is het de moeite waard om het geval van gebruikerstoegang tot het netwerk te overwegen door expliciet een verbinding tot stand te brengen met de toegangsserver. Een klassiek voorbeeld is de goede oude inbelverbinding, waarvan de analogie in de moderne wereld externe toegang is (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)

Het toegangsapparaat routeert niet alleen het IP-verkeer van gebruikers, maar fungeert ook als een gespecialiseerde VPN-server en beëindigt logische tunnels (vaak gecodeerd) waarbinnen gebruikersverkeer wordt verzonden.
Om rekening te houden met dergelijk verkeer kunt u alle hierboven beschreven tools gebruiken (en deze zijn zeer geschikt voor diepgaande analyse door poorten/protocollen), evenals aanvullende mechanismen die tools voor VPN-toegangscontrole bieden. Allereerst zullen we het hebben over het protocol. Zijn werk is een tamelijk complex onderwerp. We zullen kort vermelden dat de controle (autorisatie) van toegang tot de VPN-server (RADIUS-client) wordt gecontroleerd door een speciale applicatie (RADIUS-server), die een database (tekstbestand, SQL, Active Directory) heeft van toegestane gebruikers met hun attributen (beperkingen op verbindingssnelheden, toegewezen IP-adressen). Naast het autorisatieproces verzendt de client periodiek boekhoudberichten naar de server, informatie over de status van elke momenteel lopende VPN-sessie, inclusief tellers van overgedragen bytes en pakketten.

Conclusie

Laten we alle hierboven beschreven methoden voor het verzamelen van verkeersinformatie samenbrengen:

Laten we het samenvatten. In de praktijk zijn er een groot aantal methoden om het netwerk dat u beheert (met klanten of kantoorabonnees) te verbinden met een externe netwerkinfrastructuur, met behulp van een aantal toegangshulpmiddelen: software- en hardwarerouters, switches, VPN-servers. In vrijwel elk geval kunt u echter een schema bedenken waarbij informatie over het verkeer dat via het netwerk wordt verzonden, naar een software- of hardwaretool kan worden gestuurd voor analyse en beheer. Het is ook mogelijk dat deze tool feedback naar het toegangsapparaat mogelijk maakt, met behulp van intelligente algoritmen voor toegangsbeperking voor individuele clients, protocollen en andere zaken.
Hier rond ik de analyse van het materiaal af. De resterende onbeantwoorde onderwerpen zijn:

hoe en waar de verzamelde verkeersgegevens naartoe gaan

verkeersboekhoudsoftware

Wat is het verschil tussen facturering en eenvoudige facturering?

Hoe kunt u verkeersbeperkingen opleggen?

boekhouding en beperking van bezochte websites

Het wereldwijde internetverkeer zal in 2018 groeien tot 1,6 zettabytes. De belangrijkste groeimotoren zullen de verspreiding zijn van Ultra-HD/4K-video en machine-to-machine-communicatietechnologieën, waaronder slimme auto's.

Dat blijkt uit een onderzoek van Cisco getiteld “Visual Networking Index: Global Forecast and Service Distribution, 2013-2018.” (Cisco VNI) zal het wereldwijde IP-verkeer binnen vier jaar bijna verdrievoudigen. Dit zal gebeuren door de groei van het aantal internetgebruikers en verschillende apparaten, een toename van breedbandsnelheden en het aantal videoweergaven. In 2018 zal het jaarlijkse volume van het wereldwijde IP-verkeer dat via vaste en mobiele verbindingen loopt naar verwachting 1,6 zettabytes* bedragen, d.w.z. 1,6 zettabytes*. ruim anderhalf biljoen gigabytes. Dit is meer IP-verkeer (1,3 zettabytes) dat tussen 1984 en 2013 wereldwijd is gegenereerd.

Tientallen miljoenen fans zullen de uitzending van wedstrijden van het WK via internet bekijken. Streaming van video en IP-uitzendingen van games kunnen 4,3 exabytes aan internetverkeer genereren, wat drie keer het maandelijkse verkeersvolume in Brazilië is. Bovendien zal het internetverkeer dat door toeschouwers in elk stadion en op weg naar de wedstrijd wordt gegenereerd, naar verwachting groter zijn dan de gemiddelde hoeveelheid verkeer die tijdens de spitsuren** wordt gegenereerd door alle smartphones die momenteel in het bezit zijn van Brazilianen.

Er wordt verwacht dat het wereldwijde IP-verkeer in 2018 132 exabytes per maand zal bereiken. Dezelfde hoeveelheid verkeer kan worden gegenereerd door:

ultra-high definition (Ultra-HD/4K) videostreaming op 8,8 miljard schermen tegelijk tijdens de WK-finale;
5,5 miljard kijkers die met behulp van de video-on-demand-service seizoen 4 van “Games of Thrones” zonder onderbrekingen in high definition (HD) bekijken, of 1,5 miljard in ultra-high definition;
House of Cards seizoen 3 wordt gelijktijdig gestreamd op 24 miljard schermen in ultrahoge definitie;
940 biljard sms-berichten;
4,5 biljoen YouTube-clips.

De komende jaren zal de samenstelling van IP-verkeer dramatisch veranderen. In 2018 zal het grootste deel ervan voor het eerst niet met personal computers worden geassocieerd, maar met andere apparaten. Bovendien zal het volume van het Wi-Fi-verkeer voor het eerst groter zijn dan het volume van het bekabelde verkeer, en zal het volume van het videoverkeer hoge resolutie zal het verkeer van reguliere video overtreffen.

Het Internet of Everything wint ook aan kracht, en tegen 2018 zal het aantal machine-to-machine communicatiemodules gelijk zijn aan het aantal mensen. Voor elke ‘slimme’ auto zijn er dus bijna 4 aansluitingen.

“In het eerste rapport in zijn soort, negen jaar geleden gepubliceerd, hebben we zettabytes vastgesteld als de groeimijlpaal voor het wereldwijde IP-verkeer”, zegt Doug Webster, vice-president van product- en oplossingenmarketing bij Cisco. - Tegenwoordig leven we al in het zettabyte-tijdperk en zijn we getuige geweest van ongelooflijke veranderingen in de sector. Onder de belangrijkste trends die in de huidige prognose worden benadrukt en die zowel vandaag als in de nabije toekomst aanzienlijke kansen bieden voor dienstverleners, merken we de implementatie van het Internet of Everything, de groeiende vraag naar netwerkmobiliteit en de opkomst van ultrahogedefinitievideo op. .”

Voorspellingen voor de mondiale verkeersgroei en de belangrijkste factoren voor de adoptie van diensten

IP-verkeer

In 2018 zal het merendeel van het verkeer afkomstig zijn van mobiele en draagbare apparaten, zonder personal computers. Als in 2013 andere apparaten dan pc's 33% van het IP-verkeer voor hun rekening namen, zal hun aandeel in 2018 groeien tot 57%. De groei van het pc-verkeer zal 10% per jaar bedragen, terwijl dit cijfer voor andere apparaten en verbindingen hoger zal zijn: 18% voor tv, 74% voor tablets, 64% voor smartphones en 84% voor machine-to-machine (M2M) communicatie modules.

Het verkeer tijdens de spitsuren groeit sneller dan normaal internetverkeer. In 2013 bedroeg de groei van het internetverkeer tijdens de spits 32%, terwijl het verkeer op andere momenten van de dag met 25% groeide.

In 2013 vervoerden stedelijke netwerken meer verkeer dan hoofdverbindingen. Gedurende de periode 2013-2018. Het verkeer in stedelijke netwerken zal bijna twee keer zo snel groeien als in stedelijke netwerken trunkverbindingen. Dit is deels te wijten aan de verwachte verdubbeling van het internetverkeer op netwerken voor inhoudslevering in 2018.

IP-video

In 2018 zal het aandeel van IP-video in het totale IP-verkeer groeien tot 79% (in 2013 was dit 66%).

Het aandeel van ultra-high definition video in het totale IP-verkeer zal in 2018 met 0,1% toenemen ten opzichte van 2013 en uitkomen op 11%. Het aandeel van high-definition video zal stijgen van 36% in 2013 naar 52% in 2018, en video standaard definitie zal worden teruggebracht van 64% naar 37% van het totale IP-verkeer.

IP-verkeer per toegangstype

In 2018 zullen wifi en mobiele apparaten 61% van het IP-verkeer genereren. Het aandeel van Wi-Fi zal 49% bedragen, het aandeel mobiele netwerken- 12%. Vast verkeer zal in 2018 slechts 39% van het totale IP-verkeer uitmaken. Ter vergelijking: in 2013 bedroeg het aandeel wifi 41%, mobiel verkeer 3%, vast verkeer 56%.

In 2018 zullen wifi en mobiele apparaten 76% van het internetverkeer genereren. Het aandeel van Wi-Fi zal 61% bedragen, het aandeel van mobiele netwerken 15%. Vast verkeer zal in 2018 slechts 24% van het totale internetverkeer uitmaken. Ter vergelijking: in 2013 bedroeg het aandeel wifi 55%, mobiel verkeer 4%, vast verkeer 41%.

Apparaten en verbindingen

In 2018 zullen er gemiddeld 2,7 netwerkapparaten of verbindingen zijn voor elke persoon op onze planeet. In 2013 was dit cijfer 1,7 per hoofd van de bevolking.

Het mondiale aantal machine-to-machine-verbindingen zal 7,3 miljard bedragen, of bijna één verbinding per persoon (uitgaande van een wereldbevolking van 7,6 miljard in 2018).

Aantal vaste en mobiele apparaten met IPv6-ondersteuning zal groeien van 2 miljard in 2013 naar 10 miljard in 2018.

Verhoging van de breedbandsnelheden

De breedbandsnelheid in de wereld zal stijgen van 16 Mbit/s eind 2013 naar 42 Mbit/s in 2018.

Het merendeel (ongeveer 55%) van de breedbandverbindingen zal in 2018 de 10 Mbps overschrijden. In Japan en Zuid-Korea zal de gemiddelde breedbandsnelheid in 2018 de 100 Mbit/s benaderen.

Distributie van geavanceerde diensten

De snelst groeiende dienst in de residentiële sector zal online video zijn: met een gemiddelde jaarlijkse groei van 10% over de periode 2013-2018. het aantal gebruikers zal toenemen van 1,2 naar 1,9 miljard mensen.

Het consumentensegment zal het snelst groeien mobiele diensten per locatie: met een gemiddelde jaarlijkse groei van 36 procent over de periode 2013-2018. het aantal gebruikers van dergelijke diensten zal groeien van 236 miljoen naar ruim een miljard mensen.

In het zakelijke segment zal de snelst groeiende internetdienst videoconferenties zijn via persoonlijke apparaten en desktopcomputers: met een gemiddelde jaarlijkse groei van 45 procent voor de periode 2013-2018. het aantal gebruikers zal groeien van 37 miljoen naar 238 miljoen mensen.

Prognoses per land en regio

In 2018 zal het grootste volume aan IP-verkeer – 47,7 exabytes per maand – gegenereerd worden in de regio Azië-Pacific. De dichtstbevolkte regio ter wereld, die verantwoordelijk is voor de meeste apparaten en verbindingen, zal in 2018 de nummer één blijven qua verkeersvolumes.

In het Midden-Oosten en Afrika in de periode 2013-2018. de hoogste groeipercentages van IP-verkeer zullen blijven bestaan (een vervijfvoudiging met een gemiddelde jaarlijkse stijging van 38 procent).

In 2018 zullen de landen die de grootste verkeersvolumes genereren de Verenigde Staten en China zijn (respectievelijk 37 en 18 exabytes per maand).

De snelste groei van IP-verkeer in de periode 2013-2018. zal worden waargenomen in India en Indonesië (respectievelijk 39 procent en 37 procent gemiddelde jaarlijkse groei).

Wat betekent dit alles voor dienstverleners?

Netwerken van serviceproviders zullen verbeterde beveiliging en intelligentie nodig hebben. Ze zullen zich moeten aanpassen aan het groeiende aantal tablets, smartphones en machine-to-machine communicatieapparatuur die authenticatie vereisen om toegang te krijgen tot vaste en mobiele netwerken.

De ontwikkeling van videodiensten zoals high-definition en ultra-high-definition video kan ertoe leiden dat serviceproviders de bandbreedte moeten vergroten en extra schaalbaarheid moeten toevoegen. Er zal in de residentiële, mobiele en zakelijke sectoren een sterke vraag blijven bestaan naar toegang tot geavanceerde videodiensten via allerlei soorten netwerken en apparaten. De belangrijkste succesfactoren hierbij zijn de kwaliteit van de dienstverlening, het gebruiksgemak en de prijs.

De voortdurende adoptie van diensten zoals high-definition videoconferenties, webvideoconferenties en zakelijke video-on-demand in het zakelijke segment kan leiden tot een grotere groei in netwerkvirtualisatie en het gebruik van internet voor videotransmissie, wat zal leiden tot bepaalde problemen zowel voor dienstverleners als voor onafhankelijke dienstverleners (over-the-top providers, OTT).

Het is mogelijk om de groei van 4G-netwerken en de verspreiding van aanverwante diensten te versnellen, rekening houdend met het feit dat dit het geval is mobiele gebruikers blijven dezelfde diensten en servicekwaliteit eisen op hun vaste en mobiele netwerken.

IP-netwerken moeten over voldoende intelligentie en flexibiliteit beschikken om de steeds evoluerende nieuwe en zich ontwikkelende toepassingen voor vaste telefonie te ondersteunen mobiele netwerken. In een poging hun diensten te differentiëren, werken veel dienstverleners actief samen met applicatieontwikkelaars.

...U kunt uw firewall ook zo configureren dat alles binnenkomend wordt geblokkeerd verkeer van een bepaalde IP adressen. ... Een firewall staat bijvoorbeeld doorgaans binnenkomend verkeer van een website toe, maar geen ongeautoriseerde verbindingen met uw computer. ... Om te herkennen welk verkeer moet worden toegestaan of juist geblokkeerd, gebruikt de firewall automatische parameters, A...

...Sommige bedrijven geven aan waarvan IP-adressen kunnen worden ontvangen verkeer, maar dit kan lang duren. ... Dit betekent dat u kunt controleren welk IP-adres verkeer op uw netwerk gebruikt. ... Om de veiligheid van uw poorten te garanderen, kunt u voor altijd afscheid nemen van dynamische IP-adressen en een permanent exemplaar kopen. ... Routerpoorten zijn numerieke kenmerken van een netwerk...

... De firewall heeft dat ook IP een filter dat kan voorkomen dat bekende kwaadaardige IP-adressen proberen toegang te krijgen tot uw gegevens. ...Ook een firewall kan ongewenst stoppen verkeer van penetratie. ... U kunt dergelijke software eenvoudig aanschaffen, installeren en gebruiken. ...Vandaag de meerderheid antivirusprogramma's kan online worden gekocht en...

...Het zal je geven technische fiche elke specificatie IP adres en hoe het signaal zich onderweg naar de eindbestemming verplaatst. ... De tijd die nodig is om informatie van de ene router naar de andere te krijgen, varieert afhankelijk van hoeveel verkeer op dit moment op de router. ... Ten slotte is het laatste stukje informatie op elke regel het daadwerkelijke IP-adres zelf...

... Configuratietabel - een verzameling informatie, waaronder: - Informatie over welke verbindingen naar specifieke groepen adressen leiden - Prioriteiten voor de gebruikte verbindingen - Regels voor het verwerken van zowel patroon- als speciale typen verkeer informatie Het internet is werkelijk een ongelooflijke uitvinding. ... Ze geven bijvoorbeeld twee computers toegang tot internet onder...

... Dit adres wordt gebeld IP. ...Maar wat is een IP-adres? ... Een IP-adres is een getal van 4 bytes (32 bits) dat een uniek nummer specificeert voor de computer van een gebruiker op internet. ... Als de firewall het datapakket en het IP-adres ervan herkent, laat hij de gegevens ‘doorgeven’. ... De firewall scant het geheel verkeer op de aanwezigheid van virussen van welke aard dan ook: - spyware (spyware); - kwaadaardige software...

... Een firewall met inspectiemodus inspecteert elke verbindingsstatus en biedt meer hoge prestaties en het downgraden van kwaadaardig verkeer. ... Grotendeels, draadloze router gebruikt om netwerkverkeer tussen het netwerk en internet te distribueren. ...Controleer ook de URL, IP en MAC-adressen in de filteropties.

... Ze begonnen een speciale klem in de routersoftware te implementeren om te zien of er een grote hoeveelheid informatie vandaan kwam IP-adressen. ... Hackers begonnen dit systeem te bestuderen en realiseerden zich dat ze dezelfde enorme hoeveelheid informatie van velen zouden sturen diverse computers of IP-adressen, routers zullen niet in staat zijn om service-overbelastingsfouten te voorspellen,...

... Gebruikers iPod, wiens muziekbestanden verloren zijn gegaan als gevolg van een computerstoring, kunnen ze deze vanaf hun iPod op de computer herstellen. ... Wanneer u via uw computer praat, communiceert u via een IP-netwerk dat het hele internet verzendt en ontvangt verkeer. ... Zakelijk: Bent u manager van een computerserviceprovider, dan omvatten uw taken...

... Naast de richtingsfunctie verkeer packet kunnen routers worden gebruikt om netwerkverkeer te monitoren. Ze kunnen zich ook aanpassen aan veranderingen in het netwerk die ze dynamisch detecteren, netwerken beschermen door pakketten te filteren en te bepalen welke pakketten moeten worden geblokkeerd of toegestaan. ... Wanneer de host gegevens heeft voor een niet-lokaal IP-adressen, hij stuurt het frame zelf...