Gaurko bideo-tutoriala hasi baino lehen, eskerrak eman nahi dizkiet YouTube-n nire ikastaroaren ospea lortzen lagundu duten guztiei. Duela 8 hilabete inguru hasi nintzenean, ez nuen halako arrakastarik espero - gaur nire ikasgaiak 312724 pertsonek ikusi dituzte, 11208 harpidedun ditut. Inoiz ez nuen amestu hasiera xume hau halako garaietara iritsiko zenik. Baina ez gaitezen denbora galdu eta zuzenean gaurko ikasgaira. Gaur azken 7 bideo ikasgaietan gertatutako hutsuneak beteko ditugu. Gaur 6. eguna baino ez bada ere, 3. eguna 3 bideo-ikasgaitan banatu zen, beraz, gaur zortzigarren bideo-ikasgaia ikusiko duzu.
Gaur 3 gai garrantzitsu landuko ditugu: DHCP, TCP garraioa eta ataka-zenbaki ohikoenak. IP helbideei buruz hitz egin dugu jada, eta IP helbidea konfiguratzeko faktore garrantzitsuenetako bat DHCP da.
DHCP Dynamic Host Configuration Protocol-ek esan nahi du eta ostalarientzako IP helbideak dinamikoki konfiguratzen laguntzen duen protokoloa da. Beraz, guztiok ikusi dugu leiho hau. “Lortu IP helbidea automatikoki” aukeran klik egiten duzunean, ordenagailuak azpisare berean konfiguratuta dagoen DHCP zerbitzari bat bilatzen du eta IP helbidearen hainbat pakete eta eskaera bidaltzen ditu. DHCP protokoloak 6 mezu ditu, eta horietatik 4 funtsezkoak dira IP helbidea esleitzeko.
Lehenengo mezua DHCP DISCOVERY mezua da. DHCP aurkikuntza-mezua agur-mezu baten antzekoa da. Gailu berri bat sarera sartzen denean, sarean DHCP zerbitzaririk dagoen galdetzen du.
Diapositiban ikusten duzuna igorpen-eskaera baten itxura du, non gailua sareko gailu guztiekin harremanetan jartzen baita DHCP zerbitzari baten bila. Esan bezala, hau igorpen eskaera bat da, beraz, sareko gailu guztiek entzun dezakete.
Sarean DHCP zerbitzari bat badago, pakete bat bidaltzen du - DHCP ESKAINTZA eskaintza. Proposamenak esan nahi du DHCP zerbitzariak, aurkikuntza-eskaera bati erantzunez, konfigurazio bat bidaltzen diola bezeroari, bezeroari IP helbide zehatz bat onar dezala eskatuz.
DHCP zerbitzariak IP helbide bat gordetzen du, kasu honetan 192.168.1.2, ez du ematen, helbide hori gailurako gorde beharrean. Aldi berean, eskaintza paketeak DHCP zerbitzariaren IP helbidea dauka.
Sare honetan DHCP zerbitzari bat baino gehiago egonez gero, beste DHCP zerbitzari batek ere, bezeroaren difusio eskaera jasotzean, bere IP helbidea eskainiko lioke, adibidez, 192.168.1.50. Ez da ohikoa sare berean bi DHCP zerbitzari ezberdin konfiguratuta egotea, baina batzuetan gertatzen da. Beraz, bezero bati DHCP eskaintza bat bidaltzen zaionean, 2 DHCP eskaintza jasotzen ditu eta orain erabaki behar du zein DHCP eskaintza onartu nahi duen.
Demagun bezeroak lehenengo aplikazioa onartzen duela. Horrek esan nahi du bezeroak DHCP REQUEST eskaera bat bidaltzen duela, literalki esaten duena "192.168.1.2 DHCP zerbitzariak eskaintzen duen 192.168.1.1 IP helbidea onartzen dut".
Eskaera jasotzean, 192.168.1.1 DHCP zerbitzariak "ados, onartzen dut" erantzuten du, hau da, eskaera onartzen du eta DHCP ACK hau bezeroari bidaltzen dio. Baina gogoan dugu beste DHCP zerbitzari batek 1.50eko IP helbidea erreserbatu duela bezeroarentzat. Bezero baten igorpen-eskaera jasotzen duenean, hutsegitearen berri izango du eta IP helbide hori igerilekuan jarriko du berriro, beste bezero bati esleitu dezan beste eskaera bat jasotzen badu.
Hauek dira DHCP-k IP helbideak esleitzean trukatzen dituen 4 mezu kritikoak. Ondoren, DHCP-k 2 informazio-mezu gehiago ditu. Informazio-mezu bat igortzen du bezeroak, bigarren urratsean DHCP ESKAINTZA klausulan jasotakoa baino informazio gehiago behar badu. Zerbitzariak DHCP eskaintzan informazio nahikoa eman ez badu edo bezeroak eskaintza-paketean jasotakoa baino informazio gehiago behar badu, DHCP informazio gehigarria eskatzen du. Beste mezu bat dago bezeroak zerbitzariari bidaltzen diona - hau DHCP RELEASE da. Bezeroak lehendik duen IP helbidea askatu nahi duela jakinarazten dizu.
Hala ere, gehien gertatzen dena da erabiltzailea saretik deskonektatzen dela bezeroak zerbitzariari DHCP RELEASE bat bidaltzeko denbora izan baino lehen. Ordenagailua itzaltzen duzunean gertatzen da hori, guk egiten duguna. Kasu honetan, sareko bezeroak, edo ordenagailuak, besterik gabe, ez du zerbitzariari erabilitako helbidea askatzeko astirik emateko astirik, beraz, DHCP RELEASE ez da beharrezkoa urratsa. IP helbidea lortzeko beharrezkoak diren urratsak hauek dira: DHCP aurkikuntza, DHCP eskaintza, DHCP eskaera eta DHCP esku-ematea.
Hurrengo ikasgaietako batean esango dizut nola konfiguratzen dugun DHCP zerbitzari bat DNCP pool bat sortzean. Bateratzeak zerbitzariari 192.168.1.1 eta 192.168.1.254 bitarteko IP helbideak esleitzeko esaten diozula esan nahi dugu. Horrela, DHCP zerbitzariak igerileku bat sortuko du, 254 IP helbide jarriko ditu bertan eta sareko bezeroei helbideak esleitu ahal izango dizkie igerileku horretatik soilik. Beraz, hau erabiltzaileak egin dezakeen administrazio ezarpen baten antzeko zerbait da.
Ikus dezagun orain TCP transmisioa. Ez dakit argazkian agertzen den “telefonoa” ezagutzen duzun, baina txikitan kate baten bidez loturiko lata hauek erabiltzen genituen elkarrekin hitz egiteko.
Zoritxarrez, gaur egungo belaunaldiak ezin du halako “luxua” ordaindu. Esan nahi dut gaur umeak telebistaren aurrean daudela urtebetetik aurrera, PSPra jolasten dute eta agian hau eztabaidagarria da baina haurtzarorik onena izan genuela uste dut, egia esan kalera joaten ginen jolasetara eta Gaur egungo umeak ezin dira sofatik kendu .
Nire semeak urte bat besterik ez du eta dagoeneko ikusten dut iPadarekiko adikzioa dela, esan nahi dut oraindik oso gaztea dela baina gaur egungo haurrak tramankulu elektronikoak maneiatzen jakinda jaio direla uste dut. Beraz, esan nahi nuen txikitan, jolasten ginenean, latetan zuloak egiten genituela, eta soka batekin lotzen genituzkeen eta lata batean zerbait esaten genuenean, orduan beste muturrean pertsonak esaten zena entzuten zuen. berari, lata belarrira jarriz besterik gabe. Beraz, sareko konexio baten oso antzekoa da.
Gaur egun, TCP transferentziak ere benetako datu-transferentzia hasi aurretik ezarri behar den konexioa izan behar du. Aurreko ikasgaietan aztertu genuen bezala, TCP konexiora bideratutako transmisioa da, eta UDP konexiora bideratutako transmisioa. Esan liteke UDP dela nik baloia botatzen dudan lekuan eta zure esku dago ea harrapatzen duzun. Egiteko prest egon ala ez ez da nire arazoa, bera utziko dut.
TCP gehiago da mutil batekin hitz egitea eta aldez aurretik pilota bat botako duzula abisatzea, beraz, lotura bat eratzen duzu, eta gero baloia botatzen duzu zure bikotea harrapatzeko prest egon dadin. Beraz, TCP-k konexioa eraikitzen du eta gero benetako transmisioa egiten hasten da.
Ikus dezagun nola sortzen duen konexio hori. Protokolo honek 3 norabideko esku-ematea erabiltzen du konexioa sortzeko. Hau ez da oso termino teknikoa, baina aspalditik erabiltzen da TCP konexio bat deskribatzeko. 3 moduko esku-eskubidea igortzen duen gailuak abiarazten du, bezeroak zerbitzariari SYN bandera duen pakete bat bidaliz.
Demagun lehen planoko neska, zeinaren aurpegia ikus dezakegun, A gailua dela, eta atzealdean dagoen neska, aurpegia ikusten ez dena, B gailua dela. “Oso, nork- orduan nirekin komunikatu nahi du. Beraz, komunikatzeko prest nagoela erantzun behar dut!». Nola egin? Besterik gabe, beste SYN pakete bat itzul liteke eta, ondoren, jatorrizko SYN paketearen jasotzea adierazten duen ACK bat. Baina ACKak bereiz bidali beharrean, zerbitzariak SYN eta ACK dituen pakete komun bat osatzen du eta sarean zehar transmititzen du.
Beraz, une honetan, A gailuak SYN pakete bat bidali du eta SYN/ACK pakete bat jaso du. Orain A gailuak B gailuak ACK pakete bat bidali behar du, hau da, B gailutik komunikazioa ezartzeko baimena jaso duela baieztatu behar du. Horrela, bi gailuek SYN eta ACK paketeak jaso zituzten, eta orain esan dezakegu konexioa ezarri dela, hau da, 3 etapako esku-ematea osatu dela TCP protokoloa erabiliz.
Jarraian, TCP Windowing teknologia ikusiko dugu. Besterik gabe, TCP/IPn erabiltzen den metodo bat da igorlearen eta hartzailearen gaitasunak negoziatzeko.
Demagun Windows-en fitxategi handi bat transferitzen saiatzen ari garela, demagun 2 GB-ko tamaina, disko batetik bestera. Transferentziaren hasieran, sistemak jakinaraziko digu fitxategien transferentzia urtebete beharko dela gutxi gorabehera. Baina segundo batzuk geroago sistemak bere burua zuzenduko du eta esango du: "a, itxaron minutu bat, uste dut 1 hilabete inguru beharko direla, ez urtebete". Denbora pixka bat gehiago igaroko da eta Windows-ek esango du: "Uste dut hilabete batean fitxategia transferitzeko gai izango naizela". Ondoren, "egun bat", "6 ordu", "1 ordu", "1 ordu", "6 minutu", "3 minutu", "1 minutu" mezua agertuko da. Izan ere, fitxategiak transferitzeko prozesu osoak 20 minutu baino ez ditu hartuko. Nola gertatu da hau? Hasieran, zure gailua beste gailu batekin komunikatzen saiatzen denean, pakete bat bidaltzen du eta berrespenaren zain egongo da. Gailuak denbora luzez itxaroten badu berresteko, hauxe pentsatzen du: "abiadura honetan 10 GB datu transferitu behar baditut, 3 urte inguru beharko ditu". Denbora pixka bat igaro ondoren, zure gailuak ACK bat jasotzen du eta pentsatzen du: "ados, pakete bat bidali dut eta ACK bat jaso dut, beraz, hartzaileak pakete bat jaso dezake. Orain saiatuko naiz 3 pakete bidaltzen bat izan beharrean». Bidaltzaileak 2 pakete bidaltzen ditu eta denbora pixka bat igaro ondoren ACK baieztapena jasotzen du gailu hartzaileak, hau da, hartzaileak hurrengo 2. paketearen zain dagoela esan nahi du. Bidaltzaileak hauxe pentsatzen du: "oso ona, hartzaileak 1 pakete aldi berean kudeatzen zituenez, orain saiatuko naiz 10 pakete bidaltzen hamar izan beharrean". 10 pakete bidaltzen ditu, eta hartzaileak erantzun dio jaso dituela eta orain 11 paketeren zain dagoela. Horrela, denborarekin, igorritako paketeen kopurua handitzen da.
Hori dela eta, fitxategien kopia-denbora azkar murrizten da hasiera batean adierazitakoarekin alderatuta; hori datu-kopuru handiak transferitzeko gaitasuna handitu delako gertatzen da. Hala ere, iristen da une bat transmisio-bolumenaren gehikuntza gehiago ezinezko bihurtzen direnean. Demagun 10000 pakete bidali dituzula, baina hartzailearen gailuaren bufferak 9000 baino ezin ditu onartu. Kasu honetan, hartzaileak ACK bat bidaltzen du mezu honekin: "9000 pakete jaso ditut eta 9001 jasotzeko prest nago". Hortik, igorleak ondorioztatzen du gailu hartzailearen buffer-ak 9000 besterik ez duela edukiera, hau da, hemendik aurrera ez ditudala 9000 pakete baino gehiago bidaliko aldi berean. Kasu honetan, igorleak azkar kalkulatzen du gainerako datu kopurua 9000 pakete zatitan transferitzeko beharko duen denbora, eta 3 minutu ematen ditu. Hiru minutu hauek benetako transmisio-denbora dira. Hori da TCP Windowing-ek egiten duena.
Hau trafikoa mugatzeko mekanismo horietako bat da, non bidaltzen duen gailuak azkenean ulertzen duen benetako sarearen ahalmena zein den. Galdetzen ari zara zergatik ezin duten aldez aurretik ados jarri zein den gailu hartzailearen edukiera? Kontua da hori teknikoki ezinezkoa dela sarean gailu mota desberdinak daudelako. Demagun iPad bat duzula eta iPhone batek baino datu-transferentzia/jasotze-abiadura desberdina duela, baliteke telefono mota desberdinak izatea edo, agian, ordenagailu oso zaharra izatea. Hori dela eta, denek sareko banda zabalera desberdina dute.
Horregatik garatu zen TCP Windowing teknologia, datuen transmisioa abiadura baxuan edo gutxieneko pakete kopuru baten transmisioarekin hasten denean, trafikoaren “leihoa” pixkanaka handituz. Pakete bat, 5 pakete, 10 pakete, 1000 pakete, 10000 pakete bidaltzen dituzu eta poliki-poliki leiho hori gero eta gehiago irekitzen duzu "irekitzea" denbora-tarte zehatz batean bidalitako trafiko-bolumen maximora iritsi arte. Horrela, Windowing kontzeptua TCP protokoloaren funtzionamenduaren parte da.
Jarraian, ataka-zenbaki ohikoenak ikusiko ditugu. Egoera klasikoa zerbitzari nagusi 1 duzunean da, agian datu-zentro bat. Fitxategi zerbitzaria, web zerbitzaria, posta zerbitzaria eta DHCP zerbitzaria biltzen ditu. Orain, bezero-ordenagailuetako bat argazkiaren erdian dagoen datu-zentroarekin harremanetan jartzen bada, fitxategi-zerbitzariaren trafikoa bezero gailuetara bidaltzen hasiko da. Trafiko hori gorriz agertzen da eta zerbitzari zehatz batetik aplikazio zehatz baterako ataka zehatz batean transmitituko da.
Nola jakin zuen zerbitzariak nora joan behar zen trafiko jakin bat? Helmugako atakaren zenbakitik ikasten du hori. Markoa begiratuz gero, ikusiko duzu datu-transferentzia bakoitzean helmugako atakaren zenbakia eta iturburuko portuaren aipamena agertzen dela. Ikusten duzu trafiko urdina eta gorria, eta trafiko urdina web zerbitzariaren trafikoa dela, biak zerbitzari fisiko berera doazela, zerbitzari desberdinak instalatuta dituena. Datu-zentro bat bada, zerbitzari birtualak erabiltzen ditu. Orduan, nola jakin zuten trafiko gorria IP helbide horrekin ezkerreko ordenagailu eramangarri horretara itzuli behar zela? Hori portu zenbakiei esker dakite. Wikipediako "TCP eta UDP portuen zerrenda" artikulua aipatzen baduzu, ikusiko duzu portu-zenbaki estandar guztiak zerrendatzen dituela.
Orrialde honetan behera joaten bazara, zerrenda hau zenbaterainokoa den ikusiko duzu. Gutxi gorabehera 61 zenbaki ditu. 000etik 1ra arteko portu-zenbakiak ataka-zenbaki ohikoenak bezala ezagutzen dira. Adibidez, 1024/TCP ataka ftp komandoak bidaltzeko da, 21 ataka sshrako, 22 ataka Telneterako, hau da, zifratu gabeko mezuak bidaltzeko. 23 ataka oso ezagunak datuak HTTP bidez eramaten ditu, eta 80 atakak, berriz, enkriptatutako datuak HTTPS bidez, HTTPren bertsio seguruaren antzekoa da.
Portu batzuk TCP zein UDPra dedikatzen dira, eta beste batzuk zeregin desberdinak egiten dituzte konexioa TCP edo UDP denaren arabera. Beraz, ofizialki TCP 80 ataka HTTPrako erabiltzen da, eta ez ofizialki UDP ataka 80 HTTPrako erabiltzen da, baina HTTP protokolo desberdin baten arabera - QUIC.
Hori dela eta, TCP-ko ataka-zenbakiek ez dute beti UDP-ko gauza bera egiteko xedea. Ez duzu zerrenda hau bihotzez ikasi behar, ezinezkoa da gogoratzea, baina portu-zenbaki ezagun eta ohikoenak ezagutu behar dituzu. Esan bezala, portu horietako batzuek helburu ofiziala dute, estandarretan deskribatzen dena, eta beste batzuek helburu ez-ofiziala dute, Chromium-en kasuan bezala.
Beraz, taula honek ataka-zenbaki arrunt guztiak zerrendatzen ditu, eta zenbaki horiek trafikoa bidaltzeko eta jasotzeko erabiltzen dira aplikazio zehatzak erabiltzean.
Ikus dezagun orain nola mugitzen diren datuak sarean zehar ezagutzen dugun informazio gutxiren arabera. Demagun 10.1.1.10 ordenagailuak 30.1.1.10 helbidea duen ordenagailu honekin edo zerbitzari honekin harremanetan jarri nahi duela. Gailu bakoitzaren IP helbidearen azpian bere MAC helbidea dago. Azken 4 karaktereak dituen MAC helbide baten adibidea jartzen dut, baina praktikan 48 biteko hamaseitar zenbaki bat da 12 karaktere dituena. Zenbaki hauetako bakoitza 4 bitez osatuta dagoenez, 12 zifrak hamaseitar 48 biteko zenbakia adierazten dute.
Dakigunez, gailu honek zerbitzari honekin harremanetan jarri nahi badu, 3 norabideko esku-ematearen lehen urratsa egin behar da lehenik, hau da, SYN pakete bat bidaliz. Eskaera hori egiten denean, 10.1.1.10 ordenagailuak iturburuko ataka-zenbakia zehaztuko du, Windows-ek dinamikoki sortzen duena. Windows-ek ausaz hautatzen du 1 eta 65,000 arteko ataka-zenbakia. Baina 1etik 1024ra bitarteko hasierako zenbakiak oso ezagunak direnez, kasu honetan sistemak 25000 baino handiagoak diren zenbakiak hartuko ditu kontuan eta ausazko iturburu-ataka bat sortuko du, adibidez, 25113 zenbakia.
Jarraian, sistemak helmugako ataka bat gehituko dio paketeari, kasu honetan 21. portua da, FTP zerbitzari honetara konektatzen saiatzen ari den aplikazioak badakielako FTP trafikoa bidali behar duela.
Ondoren, gure ordenagailuak dio: "Ados, nire IP helbidea 10.1.1.10 da, eta 30.1.1.10 IP helbidearekin harremanetan jarri behar dut". Bi helbide hauek paketean sartzen dira SYN eskaera bat osatzeko, eta pakete hau ez da aldatuko konexioa amaitu arte.
Bideo honetatik datuak sarean zehar nola mugitzen diren ulertzea nahi dut. Eskaera bidaltzen duen gure ordenagailuak iturburuko IP helbidea eta helmugako IP helbidea ikusten dituenean, helmuga helbidea ez dagoela sare lokal horretan ulertzen du. Horiek guztiak /24 IP helbideak direla esatea ahaztu zait. Beraz, /24 IP helbideak begiratuz gero, 10.1.1.10 eta 30.1.1.10 ordenagailuak ez daudela sare berean konturatuko zara. Horrela, eskaera bidaltzen duen ordenagailuak ulertzen du sare horretatik irteteko 10.1.1.1 atebidearekin harremanetan jarri behar duela, bideratzaileen interfazeetako batean konfiguratuta dagoena. Badaki 10.1.1.1era joan behar duela eta bere MAC helbidea 1111 badaki, baina ez daki 10.1.1.1 atebidearen MAC helbidea. Zertan ari da? Sareko gailu guztiek jasoko duten ARP difusio eskaera bidaltzen du, baina 10.1.1.1 IP helbidea duen bideratzaileak soilik erantzungo dio.
Bideratzaileak bere AAAA MAC helbidearekin erantzungo du, eta iturburuko zein helmugako MAC helbideak ere marko honetan jarriko dira. Fotograma prest dagoenean, saretik irten aurretik CRC datuen osotasunaren egiaztapena egingo da, hau da, akatsak detektatzeko checksum bat aurkitzeko algoritmoa.
Cyclic Redundancy CRC esan nahi du fotograma osoa, SYNetik azken MAC helbidera arte, hashing algoritmo baten bidez exekutatzen dela, esate baterako, MD5, eta hash balio bat sortzen da. Hash balioa edo MD5 checksuma markoaren hasieran jartzen da.
FCS/CRC etiketatu nion FCS Frame Check Sequence bat delako, lau byteko CRC balioa. Batzuek FCS izendapena erabiltzen dute eta beste batzuek CRC izendapena, beraz, bi izendapenak sartu ditut. Baina funtsean hash balio bat besterik ez da. Sarean jasotako datu guztiek akatsik ez dutela ziurtatu behar da. Hori dela eta, fotograma hau bideratzailera iristen denean, bideratzaileak egingo duen lehenengo gauza checksuma bera kalkulatzea izango da eta jasotako FCS edo CRC balioarekin alderatzea izango da. Horrela egiaztatu ahal izango du sarean jasotako datuek akatsik ez dutela, eta ondoren checksum-a markotik kenduko du.
Ondoren, bideratzaileak MAC helbidea begiratuko du eta esango du: "Ados, AAAA MAC helbideak esan nahi du markoa niri zuzenduta dago" eta MAC helbideak dituen fotograma zatia ezabatuko du.
Helmugako 30.1.1.10 IP helbideari begiratuta, pakete hori berari zuzenduta ez dagoela ulertuko du eta bideratzailetik urrunago joan behar duela.
Orain bideratzaileak 30.1.1.10 helbidea duen sarea non dagoen ikusi behar duela "uste du". Oraindik ez dugu bideratzearen kontzeptu osoa estali, baina badakigu bideratzaileek bideratze-taula bat dutela. Taula honek 30.1.1.0 helbidea duen sarerako sarrera du. Gogoratzen duzunez, hau ez da ostalariaren IP helbidea, sarearen identifikatzailea baizik. Bideratzaileak 30.1.1.0/24 helbidera irits daitekeela "pentsatuko" du 20.1.1.2 bideratzailetik pasatuz.
Galdetuko duzu, nola daki hori? Kontuan izan hori bideratze-protokoloetatik edo zure ezarpenetatik jakingo duela administratzaile gisa ibilbide estatiko bat konfiguratu baduzu. Baina, nolanahi ere, bideratzaile honen bideratze-taulak sarrera zuzena dauka, beraz, badaki pakete hau 20.1.1.2ra bidali behar duela. Bideratzaileak helmugako MAC helbidea ezagutzen duela suposatuz, paketea birbidaltzen jarraituko dugu. Helbide hau ezagutzen ez badu, ARP berriro abiaraziko du, bideratzailearen MAC helbidea 20.1.1.2 jasoko du eta markoa bidaltzeko prozesuak berriro jarraituko du.
Beraz, suposatzen dugu dagoeneko ezagutzen duela MAC helbidea, orduan BBB iturriko MAC helbidea eta CCC helmuga MAC helbidea izango ditugu. Bideratzaileak berriro FCS/CRC kalkulatzen du eta markoaren hasieran jartzen du.
Ondoren, fotograma hau sarera bidaltzen du, markoa 20.1.12 bideratzailera iristen da, checksum-a egiaztatzen du, datuak hondatuta ez daudela ziurtatzen du eta FCS/CRC ezabatzen du. Ondoren, MAC helbideak "moztu" ditu, helmuga begiratu eta 30.1.1.10 dela ikusten du. Badaki helbide hori bere interfazera konektatuta dagoela. Fotograma eratzeko prozesu bera errepikatzen da, bideratzaileak iturburuko eta helmugako MAC helbidearen balioak gehitzen ditu, hashing-a egiten du, hash-a markoan lotzen du eta sarean zehar bidaltzen du.
Gure zerbitzariak, azkenean hari zuzendutako SYN eskaera jaso ondoren, hash checksum-a egiaztatzen du, eta paketeak akatsik ez badu, hash-a ezabatzen du. Ondoren, MAC helbideak kendu, IP helbidea begiratu eta pakete hori berari zuzenduta dagoela konturatzen da.
Horren ostean, OSI ereduaren hirugarren geruzarekin lotutako IP helbideak moztu eta ataka-zenbakiak aztertzen ditu.
21 ataka ikusten du, hau da, FTP trafikoa, SYN ikusten du eta, beraz, norbait berarekin komunikatzen saiatzen ari dela ulertzen du.
Orain, esku-emateari buruz ikasitakoaren arabera, 30.1.1.10 zerbitzariak SYN/ACK pakete bat sortuko du eta 10.1.1.10 ordenagailura bidaliko du berriro. Pakete hau jasotzean, 10.1.1.10 gailuak ACK bat sortuko du, saretik pasako du SYN pakete baten moduan, eta zerbitzariak ACKa jaso ondoren, konexioa ezarriko da.
Jakin behar duzun gauza bat da hori guztia segundo batean baino gutxiagoan gertatzen dela. Prozesu oso-oso azkarra da, moteltzen saiatu naizena, dena argi izan dezazuen.
Espero dut tutorial honetan ikasitakoa erabilgarria izatea. Galderarik baduzu, idatzi iezadazu helbide honetara [posta elektroniko bidez babestua] edo utzi galderak bideo honen azpian.
Hurrengo ikasgaitik hasita, YouTubeko 3 galdera interesgarrienak hautatuko ditut, bideo bakoitzaren amaieran errepasatuko ditudanak. Hemendik aurrera "Galdera nagusiak" atala izango dut, beraz, zure izenarekin batera galdera bat argitaratuko dut eta zuzenean erantzungo dut. Hau onuragarria izango dela uste dut.
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, % 30eko deskontua Habr erabiltzaileentzat sarrera-mailako zerbitzarien analogo berezi batean, guk zuk asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
VPS (KVM) E5-2650 v4 (6 nukleoak) 10 GB DDR4 240 GB SSD 1 Gbps doan udara arte sei hilabeteko epean ordaintzean, eska dezakezu .
Dell R730xd 2 aldiz merkeagoa? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com