JSN Mico - шаблон joomla Авто
შესვლა რეგისტრაცია

შეხვიდეთ თქვენს ანგარიშზე

მომხმარებლის სახელი *
პაროლი *
დამიმახსოვრე

შექმენი ანგარიში

ველი რომელიც აღნიშნულია ვარსკვლავი (*) აუცილებელია.
სახელი *
მომხმარებლის სახელი *
პაროლი *
დაადასტურეთ პაროლი *
ელ-ფოსტა *
დაადასტურეთ ელ-ფოსტა *
Captcha *
  • dgdfgdg-laoderi.png
  • dosddos.png
  • dosddosxx.png
  • ubiquiti.png

შესავალი

1981 წელს იქნა მიღებული IPv4 პროტოკოლი, რომელიც დაფუძნდა 32-bit მისამართით და შეეძლო გაეგზავნა 4 მილიარდი მისამართები (2^32). იმ დროისათვის ყველა დარწმუნებული იყო, რომ ეს იქნებოდა საკმარისი ყოველთვის.

თუმცა, ქსელის განვითარებას და მასსზე დაკავშირებული მოწყობილობების რაოდენობამ გადააჭარბა ყველაზე გამბედავ პროგნოზებს, და როგორც შედეგი, თავიდან წარმოიშვა მისამართების დეფიციტი, და ამის შემდეეგ ისინი დამთავრდა. მინიმუმ ევროპაში, ეს მოხდა 2012 წლის 17 სექტემბრს. ამ დღეს, ევროპის IP-რეგისტრატურამ RIPE NCC (Réseaux IP Européens Network Coordination Centre) განაცხადა, რომ ბოლო IPv4-მისამართების ბლოკი დარიგდა გასულ კვირას.

თუმცა, არსებობს მისამართების სამი დიაპაზონი სახელწოდებით "კერძო". ასევე შეიძლება შეგხვდეთ დასახელებით "ნაცრისფერი" და "კერძო". ეს მისამართები არ გადაიცემა ინტერნეტ ქსელში და შესაძლებელს ხდის ნებისმიერი ადამიანისთვის მათ გამოყენებას. აი ეს მისამართები:

  • 10.0.0.0/8
  • 172.16-31.0.0/16
  • 192.168.0-255.0/24

ცხადია, რომ ეს მისამართები შეიძლება იყოს დუბლირებული ბევრჯერ და შესაძლებელია თქვენს მეზობელსაც ჰქონდეს იგივე მისამართების დიაპაზონი, როგორიც გაქვთ თქვენ. თუმცა, ინტერნეტში მუშაობისათვის, ეს მისამართები უნდა გარდაიქმნას საჯარო მისამართზე რომელიც გაცემულია თქვენი ქსელის ოპერატორის მიერ. ასევე, ზოგჯერ საჭიროა უზრუნველყოს "ხილვადობა" სერვერზე გარეთ მდებარე დიაპაზონის მისამართები.

ორივე უზრუნველყოფილი მისამართების გაგზავნის ტექნოლოგიით (Network Address Translation), შემოკლებით როგორც NAT.

როგორც მოგეხსენებათ, IP-პაკეტის სათაური შეიცავს შემდეგ ინფორმაციას:

  1. მისამართი და წყაროს პორტი (source address и source port);
  2. მისამართი და დანიშნულების პორტი (destination Address и destination port).

მარშრუტიზატორში მისამართების ტრანსლირებისათვის გათვალისწინებულია ორი ქსელი:

  1. src-nat (ცვლის მისამართს და, შესაძლოა წყაროს პორტი);
  2. DST-nat (ცვლის მისამართს და, შესაძლოა დანიშნულების პორტი).

მარშრუტიზატორის მიერ დამუშავებული პაკეტი თავიდან ხდება dst-nat, და შემდეგ, ფილტრების მიერ პაკეტების დამუშავების მერე და მარშრუტიზაციის გადაწყვეტილების მიღების შემდეგ შემოდის src-nat ქსელში.

ეს არის მარშრუტიზატორის მიერ ტრაფიკის დამუშავების დიაგრამა, რომელიც ადასტურებს, რომ პაკეტი, რომელმაც მოვიდა მარშრუტიზატორზე, პირველი შემოდის prerouting ქსელში, ერთერთი ეტაპიდან რომელიც წარმოადგენს Destination NAT, და ყველა ძირითადი ეტაპების დამუშავების გავლის შემდეგ, შედის postrouting ქსელში, სადაც, მიმდინარეობს ეტაპი Source NAT.

აქედან გამომდინარეობს ორი მნიშვნელოვანი დასკვნები:

  1. მისამართი და დანიშნულების პორტის პაკეტი შეიცვლება dst-nat ქსელში სანამ მოხვდებიან input ან forward ქსელში. ეს ნიშნავს, რომ ფეირვოლში უნდა გაიწეროს წესი იმის გათვალისწინებით, რომ უკვე გარდაქმნილი დანიშნულების პაკეტის მისამართი (მაგ. თუ თქვენ ქსელის შიგნით გაქვთ ტერმინალური სერვერი მისამართით 192.168.0.15 და პორტი 3389, სწორედ ეს მისამართი და პორტი უნდა იყოს გამოყენებული ფეირვოლში, მიუხედავად იმისა, რომ თქვენ გარედან გაქვთ მითითებული სხვა მისამართი და პორტი);
  2. ერთი და იგივე პაკეტი შეიძლება იყოს დამუშავებული პირველად dst-nat, და შემდეგ src-nat-ში.

უბრალოდ გვახსოვდეს, რომ NAT წესით მუშავდება მხოლოდ პირველი პაკეტი დაკავშირებისას. შემდეგ ამით დაკავებულია Connection Tracker.

ყველა NAT პარამეტრები კეთდება მენიუში /IP firewall nat. ვმუშაობს იგივე პაკეტის არჩევის წესები, რომელიც ასახულია ამ სტატიაში რამდენიმე გამონაკლისით. კერძოდ:

  1. dst-nat ქსელში მიუწვდომელია out-interface არჩევა. რადგან ქსელი მას დაამუშავებს მარშრუტიზაციის შესახებ გადაწყვეტილების მიღებამდე და როუტერს ჯერ კიდევ არ აქვს განსაზღვრული ეს ინტერფეისი.
  2. ქსელში src-nat მიუწვდომელია in-interface არჩევა. რადგან პრინციპი მსგავსია.
  3. არ იმუშაფებს სწორად დაკავშირების წესი პაკეტების რაოდენობასთან ან ტრაფიკის მოცულობასთან, ანუ, მუშავდება მხოლოდ პირველი პაკეტი დაკავშირების.

ჩანართი Action განსხვავებულია.

Accept

არ დავამუშავოთ პაკეტი. პაკეტი დამუშავება არ იქნება შესრულებული. აუცილებელია პაკეტის ნაწილების დამუშავების გამორიხვისათვის. მაგალითად, როდესაც ვაკონფიგურებთ IPSec.

Add dst to address list

ამატებს პაკეტის დანიშნულების მისამართს, მისამართების დასახელების სიაში Adress List გარკვეული დროით (timeout სფეროში).

Dst-nat

იგი ცვლის პაკეტის დანიშნულების მისამართს მნიშვნელობის სფეროდან to addresses და სურვილისამებრ პორტი, სფეროდან მნიშვნელობა to ports. ეს მუშაობს მხოლოდ ქსელში dstnat და რაც გამომდინარეობს მისგან.

Jump

გადავიდეთ პაკეტების დამუშავების საკუთარ ქსელში (chain).

ვარიანტი - ქსელების სახელები. მაგალითად, ეს ვარიანტი შეგიძლიათ იხილოთ აქ.

Log

შეიყვანეთ ინფორმაცია პაკეტის შესახებ მარშრუტიზატორის Log-ფაილში. ეს პაკეტი გადაეგზავნება შემდე წესს. ეს ვარიანტი ხშირად გამოიყენება გამართვისას.

Masquerade

გამორჩეული შემთხვევა Action=src-nat. პაკეტის გამომგზავნელის მისამართი შეიცვლება პირველ მისამართში out-interface. გამოყენება მხოლოდ ერთობლივად srcnat ქსელში

Netmap

გამოიყენება 1:1 NAT-თან. როდესაც ყველა პაკეტები რომლებიც გაგზავნილი ქსელზე 1.1.1.0/24 უნდა იყოს გარდაქმნილი 2.2.2.0/24 და პირიქით. გამოიყენება როგორც srcnat და dstnat ქსელი

Passthrough

არაფერი არ გააკეთოთ. გადავცეთ პაკეტი შემდეგ წესს. თუმცა, ამასთან ერთად მრიცხველები მოქმედებს, აჩვენებს რამდენი პაკეტები შეესაბამებოდა ამ წესს. როგორც წესი, გამოიყენება სტატისტიკისათვის.

Redirect

კონკრეტულ შემთხვევაში dst-na. როგორც დანიშნულების მისამართი გამოიყენება თავად მარშრუტიზატოტი.

Return

კონკრეტული ქსელის (chain) დამუშავების ადრეული შეწყვეტა და დავუბრუნდეთ შემდეგ წესს, წესიდან Action=jump, რომელმაც გადააგზავნა პაკეტი ამ ქსელში.

Same

კონკრეტულ შემთხვევაში src-nat გამოიყენება, როდესაც არსებობს მრავალი მისამართები ტრაფიკის კონვერციისათვის. (მაგალითად, თქვენ გაქვთ მრავალი გარე IP)

Src-nat

ცვლის გამომგზავნელის პაკეტის მისამართს დანიშნულებით სფეროდან to addresses და სურვილისამებრ პორტი, სფეროდან მნიშვნელობა to ports. ეს მუშაობს მხოლოდ ქსელში srcnat და რაც გამომდინარეობს მისგან.

ამ სტატიაში ჩვენ განვიხილეთ NAT-ს ძირითადი ფუნქციონირება. ამ სტატიის მომდევნო ნაწილში იქნება განხილული ყველაზე გავრცელებული კონფიგურაცია.

ტექნიკური დირექტორი ილია კნიაზევი (MTCNA, MTCWE, MTCTCE)
სტატია ნათარგმნია რუსულიდან ქართულზე, jsh-ის მიერ. infoit.ge

სხვა სტატიები:

საიტი შეიცავს მხოლოდ გადამოწმებულ მასალას MikroTik-ის მოწყობილობების დასაკონფიგურირებლად.

ჩვენ ვიყენებთ Cookies-ს, რათა დავრწმუნდეთ იმაში, რომ გაძლევთ საუკეთესო გამოცდილებას ჩვენს ვებ-გვერდზე ყოფნისას. Cookies-ს გამოყენებასთან დაკავშირებით ამომწურავი ინფორმაცია იხილეთ Cookie პოლიტიკა. ამ საიტის გამოყენებით თქვენ ავტომატურად ეთანხმებით Cookies-ის გამოყენების უფლებას.