ამ პროექტის მიზანი იყო:

სწავლა DHCP-ის შესახებ IPv4 ქსელში
პითონის სწავლა (ცოტა მეტი, ვიდრე ნულიდან 😉)
სერვერის გამოცვლა DB2DHCP (ჩემი ჩანგალი), ორიგინალი აქ, რომლის აწყობა სულ უფრო და უფრო რთულდება ახალი OS-ისთვის. და მე არ მომწონს, რომ ეს ორობითია, რომლის „შეცვლა ახლავე“ არ არსებობს
მოქმედი DHCP სერვერის მოპოვება აბონენტის IP მისამართის არჩევის შესაძლებლობით აბონენტის Mac ან გადართვის mac+პორტის კომბინაციის გამოყენებით (ვარიანტი 82)
სხვა ველოსიპედის წერა (ოჰ! ეს ჩემი საყვარელი საქმიანობაა)
ჰაბრაჰაბრზე თქვენი კლუბური ხელობის შესახებ კომენტარების მიღება (ან კიდევ უკეთესი, მოწვევა) 😉

შედეგი: მუშაობს 😉 ტესტირება FreeBSD-ზე და Ubuntu OS-ზე. თეორიულად, კოდი შეიძლება მოითხოვოს მუშაობა ნებისმიერი OS-ით, რადგან როგორც ჩანს, კოდში არ არის რაიმე კონკრეტული სავალდებულოობა.
ფრთხილად! წინ კიდევ ბევრია.

ბმული მოყვარულთა საცავთან "ცოცხლად შეხება".

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

ცოტა თეორია

რა არის DHCP

ეს არის ქსელის პროტოკოლი, რომელიც საშუალებას აძლევს მოწყობილობას გაარკვიოს მისი IP მისამართი (და სხვა პარამეტრები, როგორიცაა კარიბჭე, DNS და ა.შ.) DHCP სერვერიდან. პაკეტების გაცვლა ხდება UDP პროტოკოლის გამოყენებით. მოწყობილობის მუშაობის ზოგადი პრინციპი ქსელის პარამეტრების მოთხოვნისას შემდეგია:

მოწყობილობა (კლიენტი) აგზავნის UDP მაუწყებლობის მოთხოვნას (DHCPDISCOVER) მთელ ქსელში მოთხოვნით „კარგი, ვინმემ მომეცით IP მისამართი“. უფრო მეტიც, ჩვეულებრივ (მაგრამ არა ყოველთვის) მოთხოვნა ხდება პორტიდან 68 (წყარო), და დანიშნულება არის პორტი 67 (დანიშნულება). ზოგიერთი მოწყობილობა ასევე აგზავნის პაკეტებს 67-ე პორტიდან. კლიენტის მოწყობილობის MAC მისამართი შედის DHCPDISCOVER პაკეტში.
ქსელში განთავსებული ყველა DHCP სერვერი (და შეიძლება იყოს რამდენიმე მათგანი) ქმნის DHCPOFFER შეთავაზებას ქსელის პარამეტრებით მოწყობილობისთვის, რომელმაც გაგზავნა DHCPDISCOVER, და ასევე ავრცელებს მას ქსელში. იდენტიფიკაცია, ვისთვის არის განკუთვნილი ეს პაკეტი, ეფუძნება კლიენტის MAC მისამართს, რომელიც ადრე იყო მოწოდებული DHCPDISCOVER მოთხოვნაში.
კლიენტი იღებს პაკეტებს ქსელის პარამეტრების წინადადებებით, ირჩევს ყველაზე მიმზიდველს (კრიტერიუმები შეიძლება განსხვავებული იყოს, მაგალითად, პაკეტის მიწოდების დრო, შუალედური მარშრუტების რაოდენობა) და აკეთებს „ოფიციალურ მოთხოვნას“ DHCPREQUEST ქსელის პარამეტრებით. DHCP სერვერიდან, რომელიც მას მოსწონს. ამ შემთხვევაში, პაკეტი მიდის კონკრეტულ DHCP სერვერზე.
სერვერი, რომელმაც მიიღო DHCPREQUEST, აგზავნის DHCPACK ფორმატის პაკეტს, რომელშიც კიდევ ერთხელ ჩამოთვლის ამ კლიენტისთვის განკუთვნილ ქსელის პარამეტრებს

გარდა ამისა, არის DHCPINFORM პაკეტები, რომლებიც მოდის კლიენტისგან და რომლის მიზანია აცნობოს DHCP სერვერს, რომ „კლიენტი ცოცხალია“ და იყენებს გაცემული ქსელის პარამეტრებს. ამ სერვერის დანერგვისას ეს პაკეტები იგნორირებულია.

პაკეტის ფორმატი

ზოგადად, Ethernet პაკეტის ჩარჩო ასე გამოიყურება:

ჩვენს შემთხვევაში, ჩვენ განვიხილავთ მხოლოდ მონაცემებს პირდაპირ UDP პაკეტის შიგთავსიდან, OSI ფენის პროტოკოლის სათაურების გარეშე, კერძოდ, DHCP სტრუქტურა:

DHCPDISCOVER

ამრიგად, მოწყობილობისთვის IP მისამართის მიღების პროცესი იწყება იმით, რომ DHCP კლიენტი აგზავნის სამაუწყებლო მოთხოვნას 68 პორტიდან 255.255.255.255:67-ზე. ამ პაკეტში კლიენტი მოიცავს თავის MAC მისამართს, ასევე იმას, რისი მიღებაც სურს DHCP სერვერისგან. პაკეტის სტრუქტურა აღწერილია ქვემოთ მოცემულ ცხრილში.

DHCPDISCOVER პაკეტის სტრუქტურის ცხრილი

პოზიცია პაკეტში
ღირებულების სახელი
მაგალითი
შესავალი
ბიტი
განმარტება

1
ჩატვირთვის მოთხოვნა
1
Hex
1
შეტყობინების ტიპი. 1 - მოთხოვნა კლიენტიდან სერვერზე, 2 - პასუხი სერვერიდან კლიენტზე

2
აპარატურის ტიპი
1
Hex
1
აპარატურის მისამართის ტიპი, ამ პროტოკოლში 1 - MAC

3
აპარატურის მისამართების სიგრძე
6
Hex
1
მოწყობილობის MAC მისამართის სიგრძე

4
Hops
1
Hex
1
შუალედური მარშრუტების რაოდენობა

5
გარიგების ID
23:cf:de:1d
Hex
4
ტრანზაქციის უნიკალური იდენტიფიკატორი. გენერირდება კლიენტის მიერ მოთხოვნის ოპერაციის დასაწყისში

7
მეორე გავიდა
0
Hex
4
დრო წამებში მისამართის მიღების პროცესის დაწყებიდან

9
ჩექმის დროშები
0
Hex
2
გარკვეული დროშები, რომლებიც შეიძლება დაყენდეს პროტოკოლის პარამეტრების მითითებისთვის

11
კლიენტის IP მისამართი
0.0.0.0
ხაზი
4
კლიენტის IP მისამართი (ასეთის არსებობის შემთხვევაში)

15
თქვენი კლიენტის IP მისამართი
0.0.0.0
ხაზი
4
სერვერის მიერ შემოთავაზებული IP მისამართი (თუ შესაძლებელია)

19
შემდეგი სერვერის IP მისამართი
0.0.0.0
ხაზი
4
სერვერის IP მისამართი (თუ ცნობილია)

23
სარელეო აგენტის IP მისამართი
172.16.114.41
ხაზი
4
სარელეო აგენტის IP მისამართი (მაგალითად, გადამრთველი)

27
კლიენტის MAC მისამართი
14:d6:4d:a7:c9:55
Hex
6
პაკეტის გამგზავნის (კლიენტის) MAC მისამართი

31
კლიენტის აპარატურის მისამართის შევსება

Hex
10
დაჯავშნილი ადგილი. ჩვეულებრივ ივსება ნულებით

41
სერვერის ჰოსტის სახელი

ხაზი
64
DHCP სერვერის სახელი. როგორც წესი, არ არის გადაცემული

105
ჩატვირთვის ფაილის სახელი

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

235
ჯადოსნური ნამცხვრები
63: 82: 53: 63
Hex
4
"ჯადოსნური" ნომერი, რომლის მიხედვითაც, მ.შ. თქვენ შეგიძლიათ განსაზღვროთ, რომ ეს პაკეტი ეკუთვნის DHCP პროტოკოლს

DHCP პარამეტრები. ნებისმიერი თანმიმდევრობით შეიძლება წასვლა

236
ვარიანტის ნომერი
53
Dec
1
ვარიანტი 53, რომელიც განსაზღვრავს DHCP პაკეტის ტიპს

1 - DHCPDISCOVER
3 - DHCPREQUEST
2 - DHCPOFFER
5 - DHCPACK
8 - DHCPINFORM

ვარიანტის სიგრძე
1
Dec
1

ვარიანტის ღირებულება
1
Dec
1

ვარიანტის ნომერი
50
Dec
1
რა IP მისამართი სურს კლიენტს მიიღოს?

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
172.16.134.61
ხაზი
4

ვარიანტის ნომერი
55

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

01 - ქსელის ნიღაბი
03 - კარიბჭე
06 - DNS
oc — მასპინძლის სახელი
0f - ქსელის დომენის სახელი
1c - სამაუწყებლო მოთხოვნის მისამართი (მაუწყებლობა)
42 - TFTP სერვერის სახელი
79 - უკლასო სტატიკური მარშრუტი

ვარიანტის სიგრძე
8

1

ვარიანტის ღირებულება
01:03:06:0c:0f:1c:42:79

8

ვარიანტის ნომერი
82
Dec

ვარიანტი 82, რომელიც გადასცემს განმეორებითი მოწყობილობის MAC მისამართს და დამატებით მნიშვნელობას.

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

ამ შემთხვევაში, 82-ე ოფციაში, ქვეოფციები ჩადგმულია:
Agent Circuit ID = 00:04:00:01:00:04, სადაც ბოლო ორი ბაიტი არის DHCP კლიენტის პორტი, საიდანაც მოვიდა მოთხოვნა

აგენტის დისტანციური ID = 00:06:c8:be:19:93:11:48 - DHCP განმეორებითი მოწყობილობის MAC მისამართი

ვარიანტის სიგრძე
18
Dec

ვარიანტის ღირებულება
01:06
00:04:00:01:00:04
02:08
00:06:c8:be:19:93:11:48
Hex

პაკეტის დასასრული
255
Dec
1
255 სიმბოლოა პაკეტის დასასრული

DHCPOFFER

როგორც კი სერვერი მიიღებს DHCPDISCOVER პაკეტს და თუ დაინახავს, რომ მას შეუძლია კლიენტს შესთავაზოს რაიმე მოთხოვნილიდან, მაშინ ის წარმოქმნის მასზე პასუხს - DHCPDISCOVER. პასუხი იგზავნება პორტში „საიდანაც მოვიდა“, მაუწყებლობის საშუალებით, რადგან ამ მომენტში კლიენტს ჯერ არ აქვს IP მისამართი, ამიტომ მას შეუძლია მიიღოს პაკეტი მხოლოდ იმ შემთხვევაში, თუ ის გაგზავნილია გადაცემით. კლიენტი აცნობიერებს, რომ ეს არის მისთვის პაკეტი მისი MAC მისამართის მიხედვით პაკეტის შიგნით, ისევე როგორც ტრანზაქციის ნომერი, რომელსაც ის ქმნის პირველი პაკეტის შექმნის დროს.

DHCPOFFER პაკეტის სტრუქტურის ცხრილი

პოზიცია პაკეტში
ღირებულების სახელი (საერთო)
მაგალითი
შესავალი
ბიტი
განმარტება

2
აპარატურის ტიპი
1
Hex
1
აპარატურის მისამართის ტიპი, ამ პროტოკოლში 1 - MAC

3
აპარატურის მისამართების სიგრძე
6
Hex
1
მოწყობილობის MAC მისამართის სიგრძე

4
Hops
1
Hex
1
შუალედური მარშრუტების რაოდენობა

7
მეორე გავიდა
0
Hex
4
დრო წამებში მისამართის მიღების პროცესის დაწყებიდან

9
ჩექმის დროშები
0
Hex
2
გარკვეული დროშები, რომლებიც შეიძლება დაყენდეს პროტოკოლის პარამეტრების მითითებისთვის. ამ შემთხვევაში 0 ნიშნავს Unicast მოთხოვნის ტიპს

15
თქვენი კლიენტის IP მისამართი
172.16.134.61
ხაზი
4
სერვერის მიერ შემოთავაზებული IP მისამართი (თუ შესაძლებელია)

19
შემდეგი სერვერის IP მისამართი
0.0.0.0
ხაზი
4
სერვერის IP მისამართი (თუ ცნობილია)

27
კლიენტის MAC მისამართი
14:d6:4d:a7:c9:55
Hex
6
პაკეტის გამგზავნის (კლიენტის) MAC მისამართი

DHCP პარამეტრები. ნებისმიერი თანმიმდევრობით შეიძლება წასვლა

236
ვარიანტის ნომერი
53
Dec
1
ვარიანტი 53, რომელიც განსაზღვრავს DHCP 2 პაკეტის ტიპს - DHCPOFFER

ვარიანტის სიგრძე
1
Dec
1

ვარიანტის ღირებულება
2
Dec
1

ვარიანტის ნომერი
1
Dec
1
DHCP კლიენტს ქსელის ნიღბის შეთავაზების შესაძლებლობა

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
255.255.224.0
ხაზი
4

ვარიანტის ნომერი
3
Dec
1
DHCP კლიენტს ნაგულისხმევი კარიბჭის შეთავაზების შესაძლებლობა

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
172.16.12.1
ხაზი
4

ვარიანტის ნომერი
6
Dec
1
DHCP DNS კლიენტისთვის შეთავაზების ვარიანტი

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
8.8.8.8
ხაზი
4

ვარიანტის ნომერი
51
Dec
1
გაცემული ქსელის პარამეტრების სიცოცხლე წამებში, რის შემდეგაც DHCP კლიენტმა უნდა მოითხოვოს ისინი ხელახლა

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
86400
Dec
4

ვარიანტის ნომერი
82
Dec
1
ვარიანტი 82, იმეორებს იმას, რაც მოვიდა DHCPDISCOVER-ში

ვარიანტის სიგრძე
18
Dec
1

ვარიანტის ღირებულება
01:08:00:06:00
01:01:00:00:01
02:06:00:03:0f
26:4d:ec
Dec
18

პაკეტის დასასრული
255
Dec
1
255 სიმბოლოა პაკეტის დასასრული

DHCPREQUEST

მას შემდეგ, რაც კლიენტი მიიღებს DHCPOFFER-ს, ის აყალიბებს პაკეტს, რომელიც ითხოვს ქსელის პარამეტრებს ქსელში არა ყველა DHCP სერვერზე, არამედ მხოლოდ ერთ კონკრეტულ სერვერზე, რომლის DHCPOFFER შეთავაზება მას ყველაზე მეტად „მოეწონა“. "მსგავსი" კრიტერიუმები შეიძლება იყოს განსხვავებული და დამოკიდებულია კლიენტის DHCP-ის განხორციელებაზე. მოთხოვნის მიმღები მითითებულია DHCP სერვერის MAC მისამართის გამოყენებით. ასევე, კლიენტის მიერ DHCPREQUEST პაკეტის გაგზავნა შესაძლებელია DHCPDISCOVER-ის პირველი გენერირების გარეშე, თუ სერვერის IP მისამართი უკვე მიღებულია ადრე.

DHCPREQUEST პაკეტის სტრუქტურის ცხრილი

2
აპარატურის ტიპი
1
Hex
1
აპარატურის მისამართის ტიპი, ამ პროტოკოლში 1 - MAC

3
აპარატურის მისამართების სიგრძე
6
Hex
1
მოწყობილობის MAC მისამართის სიგრძე

4
Hops
1
Hex
1
შუალედური მარშრუტების რაოდენობა

7
მეორე გავიდა
0
Hex
4
დრო წამებში მისამართის მიღების პროცესის დაწყებიდან

9
ჩექმის დროშები
8000
Hex
2
გარკვეული დროშები, რომლებიც შეიძლება დაყენდეს პროტოკოლის პარამეტრების მითითებისთვის. ამ შემთხვევაში დაყენებულია „მაუწყებლობა“.

19
შემდეგი სერვერის IP მისამართი
0.0.0.0
ხაზი
4
სერვერის IP მისამართი (თუ ცნობილია)

27
კლიენტის MAC მისამართი
14:d6:4d:a7:c9:55
Hex
6
პაკეტის გამგზავნის (კლიენტის) MAC მისამართი

DHCP პარამეტრები. ნებისმიერი თანმიმდევრობით შეიძლება წასვლა

236
ვარიანტის ნომერი
53
Dec
3
ვარიანტი 53, რომელიც განსაზღვრავს DHCP პაკეტის ტიპს 3 - DHCPREQUEST

ვარიანტის სიგრძე
1
Dec
1

ვარიანტის ღირებულება
3
Dec
1

ვარიანტის ნომერი
61
Dec
1
კლიენტის ID: 01 (Ehernet-ისთვის) + კლიენტის MAC მისამართი

ვარიანტის სიგრძე
7
Dec
1

ვარიანტის ღირებულება
01:2c:ab:25:ff:72:a6
Hex
7

ვარიანტის ნომერი
60
Dec

"მიმწოდებლის კლასის იდენტიფიკატორი". ჩემს შემთხვევაში, ის იტყობინება DHCP კლიენტის ვერსიას. შესაძლოა სხვა მოწყობილობები რაღაც განსხვავებულს აბრუნებენ. Windows მაგალითად იუწყება MSFT 5.0

ვარიანტის სიგრძე
11
Dec

ვარიანტის ღირებულება
გზამკვლევი 0.9.8
ხაზი

ვარიანტის სიგრძე
8

1

ვარიანტის ღირებულება
01:03:06:0c:0f:1c:42:79

8

ვარიანტის ნომერი
82
Dec
1
ვარიანტი 82, იმეორებს იმას, რაც მოვიდა DHCPDISCOVER-ში

ვარიანტის სიგრძე
18
Dec
1

ვარიანტის ღირებულება
01:08:00:06:00
01:01:00:00:01
02:06:00:03:0f
26:4d:ec
Dec
18

პაკეტის დასასრული
255
Dec
1
255 სიმბოლოა პაკეტის დასასრული

DHCPACK

როგორც დადასტურება, რომ „დიახ, ეს ასეა, ეს არის თქვენი IP მისამართი და მე მას სხვას არ გადავცემ“ DHCP სერვერიდან, DHCPACK ფორმატის პაკეტი სერვერიდან კლიენტამდე ემსახურება. ის იგზავნება მაუწყებლობის მსგავსად სხვა პაკეტების მსგავსად. მიუხედავად იმისა, რომ ქვემოთ მოცემულ კოდში Python-ში დანერგილი DHCP სერვერისთვის, ყოველი შემთხვევისთვის, მე ვაპირებ გადაცემის ნებისმიერ მოთხოვნას კონკრეტული კლიენტის IP-ზე პაკეტის გაგზავნით, თუ ის უკვე ცნობილია. უფრო მეტიც, DHCP სერვერს საერთოდ არ აინტერესებს მიაღწია თუ არა DHCPACK პაკეტი კლიენტს. თუ კლიენტი არ მიიღებს DHCPACK-ს, გარკვეული პერიოდის შემდეგ ის უბრალოდ იმეორებს DHCPREQUEST-ს

DHCPACK პაკეტის სტრუქტურის ცხრილი

1
ჩატვირთვის მოთხოვნა
2
Hex
1
შეტყობინების ტიპი. 1 - მოთხოვნა კლიენტიდან სერვერზე, 2 - პასუხი სერვერიდან კლიენტზე

2
აპარატურის ტიპი
1
Hex
1
აპარატურის მისამართის ტიპი, ამ პროტოკოლში 1 - MAC

3
აპარატურის მისამართების სიგრძე
6
Hex
1
მოწყობილობის MAC მისამართის სიგრძე

4
Hops
1
Hex
1
შუალედური მარშრუტების რაოდენობა

7
მეორე გავიდა
0
Hex
4
დრო წამებში მისამართის მიღების პროცესის დაწყებიდან

19
შემდეგი სერვერის IP მისამართი
0.0.0.0
ხაზი
4
სერვერის IP მისამართი (თუ ცნობილია)

27
კლიენტის MAC მისამართი
14:d6:4d:a7:c9:55
Hex
6
პაკეტის გამგზავნის (კლიენტის) MAC მისამართი

DHCP პარამეტრები. ნებისმიერი თანმიმდევრობით შეიძლება წასვლა

236
ვარიანტის ნომერი
53
Dec
3
ვარიანტი 53, რომელიც განსაზღვრავს DHCP პაკეტის ტიპს 5 - DHCPACK

ვარიანტის სიგრძე
1
Dec
1

ვარიანტის ღირებულება
5
Dec
1

ვარიანტის ნომერი
1
Dec
1
DHCP კლიენტს ქსელის ნიღბის შეთავაზების შესაძლებლობა

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
255.255.224.0
ხაზი
4

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
172.16.12.1
ხაზი
4

ვარიანტის ნომერი
6
Dec
1
DHCP DNS კლიენტისთვის შეთავაზების ვარიანტი

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
8.8.8.8
ხაზი
4

ვარიანტის სიგრძე
4
Dec
1

ვარიანტის ღირებულება
86400
Dec
4

ვარიანტის ნომერი
82
Dec
1
ვარიანტი 82, იმეორებს იმას, რაც მოვიდა DHCPDISCOVER-ში

ვარიანტის სიგრძე
18
Dec
1

ვარიანტის ღირებულება
01:08:00:06:00
01:01:00:00:01
02:06:00:03:0f
26:4d:ec
Dec
18

პაკეტის დასასრული
255
Dec
1
255 სიმბოლოა პაკეტის დასასრული

დაყენების

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

FreeBSD

pkg დააინსტალირე python3 python3 -m surepip pip3 დააინსტალირე mysql-კონექტორი

Ubuntu

sudo apt-get დააინსტალირე python3 sudo apt-get დააინსტალირე pip3 sudo pip3 დააინსტალირე mysql-კონექტორი

ჩვენ ვქმნით MySQL მონაცემთა ბაზას, ვტვირთავთ მასში pydhcp.sql ნაგავსაყრელს და ვაკონფიგურირებთ კონფიგურაციის ფაილს.

კონფიგურაცია

სერვერის ყველა პარამეტრი არის xml ფაილში. საცნობარო ფაილი:

1.0 0.0.0.0 255.255.255.255 192.168.0.71 8600 1 255.255.255.0 192.168.0.1 ლოკალჰოსტი ტესტი ტესტი pydhcp option_8.8.8.8_hex:sw_port82:1:20 option_22_hex:sw_port82:2:16 option_18_hex:sw_mac:82:26 40 აირჩიეთ ip, mask, როუტერი, dns მომხმარებლებიდან, სადაც upper(mac)=upper('{option_3_AgentRemoteId_hex}') და upper(port)=upper('{option_1_AgentCircuitId_port_hex}') აირჩიეთ ip, mask, როუტერი, dns მომხმარებლებისგან, სადაც upper(mac)=upper('{sw_mac}') და upper(port)=upper('{sw_port82}') აირჩიეთ ip, mask, როუტერი, dns მომხმარებლებისგან, სადაც upper(mac)=upper ('{ClientMacAddress}') ისტორიაში ჩასმა (id,dt,mac,ip,კომენტარი) მნიშვნელობები (null,now(),'{ClientMacAddress}','{RequestedIpAddress}','DHCPACK/INFORM')

ახლა უფრო დეტალურად ტეგებზე:

dhcpserver განყოფილება აღწერს სერვერის გაშვების ძირითად პარამეტრებს, კერძოდ:

ჰოსტი - რა IP მისამართს უსმენს სერვერი 67 პორტზე
ეთერში - რომელი IP არის DHCPOFFER-ისა და DHCPACK-ის მაუწყებლობა
DHCPServer - რა არის DHCP სერვერის IP
გაცემული IP მისამართის LeaseTime იჯარის დრო
ThreadLimit - რამდენი თემა გაშვებულია ერთდროულად 67-ე პორტზე შემომავალი UDP პაკეტების დასამუშავებლად. ის უნდა დაეხმაროს მაღალი დატვირთვის პროექტებს 😉
defaultMask,defaultRouter,defaultDNS - რას სთავაზობენ აბონენტს ნაგულისხმევად, თუ მონაცემთა ბაზაში ნაპოვნია IP, მაგრამ მისთვის დამატებითი პარამეტრები არ არის მითითებული.

mysql განყოფილება:

ჰოსტი, მომხმარებლის სახელი, პაროლი, საბაზისო სახელი - ყველაფერი თავისთავად საუბრობს. გამოქვეყნებულია მონაცემთა ბაზის სავარაუდო სტრუქტურა GitHub

შეკითხვის განყოფილება: OFFER/ACK-ის მიღების მოთხოვნები აღწერილია აქ:

offer_count — ხაზების რაოდენობა მოთხოვნით, რომლებიც აბრუნებენ შედეგს, როგორიცაა ip, mask, როუტერი, dns
offer_n — შეკითხვის სტრიქონი. თუ დაბრუნება ცარიელია, მაშინ ახორციელებს შემდეგი შეთავაზების მოთხოვნას
history_sql - შეკითხვა, რომელიც წერს, მაგალითად, აბონენტისთვის „ავტორიზაციის ისტორიას“

მოთხოვნები შეიძლება შეიცავდეს ნებისმიერ ცვლადს პარამეტრების განყოფილებიდან ან ვარიანტებს DHCP პროტოკოლიდან.

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

მაგალითად:

option_82_hex:sw_port1:20:22

, ეს ბრძანების ხაზი იღებს მთელ ხაზს, რომელიც მოვიდა DHCP მოთხოვნის ვარიანტში 82, თექვსმეტობით ფორმატში, 20-დან 22 ბაიტამდე დიაპაზონში და აყენებს ახალ ცვლადში sw_port1 (გადამრთველი პორტი საიდანაც მოვიდა მოთხოვნა)

option_82_hex:sw_mac:26:40

, განსაზღვრეთ sw_mac ცვლადი, აიღეთ ჰექსი დიაპაზონიდან 26:40

თქვენ შეგიძლიათ ნახოთ ყველა შესაძლო ვარიანტი, რომელიც შეიძლება გამოყენებულ იქნას შეკითხვებში სერვერის გაშვებით -d გადამრთველით. ჩვენ დავინახავთ მსგავსი რამის ჟურნალს:

-- DHCPINFORM პაკეტი ჩამოვიდა პორტ 67-ზე, 0025224ad764-დან, b'x91xa5xe0xa3xa5xa9-x8fx8a' , ('172.30.114.25', 68) {'ClientMacAddress': '0025224ClientMacAddress', '764y00'7ClientMacAddress', '91y' 5 0%"Jxd3d' , 'HType': 'Ethernet', 'HostName': b'x5xa9xe8xa8xa43xa0.0.0.0-x5.0fx0025224a', 'ReqListDNS': True, 'ReqListDomainName': True, 'ReqListPerfowmRouterDiscover':TrueqLuteReist': TrueRouta მართალია, 'ReqListSubnetM ask': True, 'ReqListVendorSpecInfo': 764, 'RequestedIpAddress': '172.30.128.13', 'Vendor': b'MSFT 00', 'chaddr': '00ad172.30.114.25', '308', '6. , 'flags': b'x1x82', 'giaddr': '12', 'gpoz': 12, 'hlen': 53, 'hops': 53, 'htype': 'MAC', 'magic_cookie': b'cx55Sc ', 'op': 'DHCPINFORM', 'option55': 60, 'option60': 61, 'option61': 82, 'option82': 82, 'option12': 01, 'option06': 00, ' option_04_byte': b'x00x01x00x06x02x08x00x06x00x1x9x2' b'x82x12010600040001000602080006001x589eXx2exb82xad', 'option_18_hex': '82 _12_len': 01 06, 'option_00_str': "b'x04x00x01x00x06x02x08x00x06x00x1x9x2x768x0.0.0.0eXx001exb589xad'", 'შედეგი': მცდარი, 'წმ': 2 'siaddr': '1', 'sw_mac': '06e89eb8ad', 'sw_port3': '897', 'xidbyte': b'

შესაბამისად, შეგვიძლია ნებისმიერი ცვლადი ჩავაკრათ {}-ში და ის გამოყენებული იქნება SQL მოთხოვნაში.

მოდით ჩავწეროთ ისტორიაში, რომ კლიენტმა მიიღო IP მისამართი:

სერვერის დაწყება

./pydhcpdb.py -d -c config.xml

— კონსოლის გამომავალი რეჟიმი DEBUG
- c <filename> კონფიგურაციის ფაილი

გაღიზიანება

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

XML კონფიგურაციის ფაილის პარსერი

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

    ხე = minidom.parse(gconfig["config_file"]) mconfig=tree.getElementsByTagName("mysql") elem-ისთვის mconfig-ში: gconfig["mysql_host"]=elem.getElementsByTagName("მასპინძელი")[0].datast gconfig["mysql_username"]=elem.getElementsByTagName("მომხმარებლის სახელი")[0].firstChild.data gconfig["mysql_password"]=elem.getElementsByTagName("პაროლი")[0].first"sqlChild. =elem.getElementsByTagName("basename")[0].firstChild.data dconfig=tree.getElementsByTagName("dhcpserver") ელემენტისთვის dconfig-ში: gconfig["broadcast"]=elem.getElementsByTagName.)"(0) firstChild.data gconfig["dhcp_host"]=elem.getElementsByTagName("მასპინძელი")[0].firstChild.data gconfig["dhcp_LeaseTime"]=elem.getElementsByTagName("LeaseTime")[0]Child]"dast dhcp_ThreadLimit"]=int(elem.getElementsByTagName("ThreadLimit")[0].firstChild.data) gconfig["dhcp_Server"]=elem.getElementsByTagName("DHCPServer")[0]configd]Maild]. =elem.getElementsByTagName("defaultMask")[0].firstChild.data gconfig["dhcp_defaultRouter"]=elem.getElementsByTagName("defaultRouter")[0].firstChild.data gconfig[element.Nsp. " defaultDNS")[0].firstChild.data qconfig=tree.getElementsByTagName("query") elem-ისთვის qconfig-ში: gconfig["offer_count"]=elem.getElementsByTagName("offer_count")[0].firstChild.მონაცემები num-ისთვის დიაპაზონი(int(gconfig["offer_count"]): gconfig["offer_"+str(num+1)]=elem.getElementsByTagName("offer_"+str(num+1))[0].firstChild.data gconfig ["history_sql"]=elem.getElementsByTagName("history_sql")[0].firstChild.data options=tree.getElementsByTagName("options") ელემისთვის ოფციებში: node=elem.getElementsByTagName") პარამეტრებისთვის" : optionsMod.append(options.firstChild.data)

მრავალძაფიანი

უცნაურად საკმარისია, რომ Python-ში მრავალძალიანობა ხორციელდება ძალიან ნათლად და მარტივად.

def PacketWork(data,addr): ... # შემომავალი პაკეტის გარჩევის და მასზე პასუხის განხორციელება ... ხოლო True: data, addr = udp_socket.recvfrom(1024) # ელოდება UDP პაკეტის ძაფს = threading.Thread( target=PacketWork , args=(data,addr,)).start() # როგორც მოვიდა - ჩვენ ვიშვებთ ადრე განსაზღვრულ PacketWork ფუნქციას ფონზე პარამეტრებით threading.active_count() >gconfig["dhcp_ThreadLimit"]: დრო. sleep(1) # თუ ნომერი უკვე უფრო მეტი თემაა გაშვებული, ვიდრე პარამეტრებში, ველოდებით სანამ ნაკლები იქნება

DHCP პაკეტის მიღება/გაგზავნა

ქსელის ბარათის მეშვეობით შემოსული UDP პაკეტების გადასაჭრელად, თქვენ უნდა "აწიოთ" სოკეტი:

udp_socket = socket.socket(socket.AF_INET,socket.SOCK_DGRAM,socket.IPPROTO_UDP) udp_socket.bind((gconfig["dhcp_host"],67))

, სადაც დროშებია:

AF_INET - ნიშნავს, რომ მისამართის ფორმატი იქნება IP: პორტი. ასევე შეიძლება იყოს AF_UNIX - სადაც მისამართი მითითებულია ფაილის სახელით.
SOCK_DGRAM - ნიშნავს, რომ ჩვენ არ ვიღებთ „ნედლეულ პაკეტს“, არამედ ის, რომელიც უკვე გაიარა firewall-ში და ნაწილობრივ მოჭრილი პაკეტით. იმათ. ჩვენ ვიღებთ მხოლოდ UDP პაკეტს UDP პაკეტის შეფუთვის „ფიზიკური“ კომპონენტის გარეშე. თუ იყენებთ SOCK_RAW დროშას, მაშინ ასევე დაგჭირდებათ ამ „შეფუთვის“ გარჩევა.

პაკეტის გაგზავნა შეიძლება იყოს მაუწყებლობის მსგავსი:

                    udp_socket.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) #switch socket მაუწყებლობის რეჟიმში rz=udp_socket.sendto(packetack, (gconfig["მაუწყებლობა"],68))

, და მისამართზე „საიდან მოვიდა პაკეტი“:

                        udp_socket.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1) # გადართეთ სოკეტი მრავალ მოსმენის რეჟიმში rz=udp_socket.sendto(packetack, addr)

, სადაც SOL_SOCKET ნიშნავს "პროტოკოლის დონეს" პარამეტრების დასაყენებლად,

, SO_BROADCAST ვარიანტი, რომ ჩაფხუტის პაკეტი "მაუწყებელია"

SO_REUSEADDR ოფცია ცვლის სოკეტს „ბევრი მსმენელის“ რეჟიმში. თეორიულად, ამ შემთხვევაში ეს ზედმეტია, მაგრამ ერთ-ერთ FreeBSD სერვერზე, რომელზეც მე გამოვცადე, კოდი არ მუშაობდა ამ პარამეტრის გარეშე.

DHCP პაკეტის ანალიზი

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

    res["xidhex"]=data[4:8].hex() res["xidbyte"]=data[4:8]

, ჩაალაგე ბაიტები სტრუქტურაში:

res["flags"]=pack('BB',data[10],data[11])

მიიღეთ IP სტრუქტურიდან:

res["ciaddr"]=socket.inet_ntoa(pack('BBBB',data[12],data[13],data[14],data[15]));

და პირიქით:

res=res+socket.inet_pton(socket.AF_INET, gconfig["dhcp_Server"])

ჯერჯერობით სულ ესაა 😉

წყარო: www.habr.com

DHCP + Mysql სერვერი Python-ში

ცოტა თეორია

რა არის DHCP

პაკეტის ფორმატი

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK

დაყენების

FreeBSD

Ubuntu

კონფიგურაცია

სერვერის დაწყება

გაღიზიანება

XML კონფიგურაციის ფაილის პარსერი

მრავალძაფიანი

DHCP პაკეტის მიღება/გაგზავნა

DHCP პაკეტის ანალიზი

ახალი კომენტარის დამატება

DHCP + Mysql სერვერი Python-ში

ცოტა თეორია

რა არის DHCP

პაკეტის ფორმატი

DHCPDISCOVER

DHCPOFFER

DHCPREQUEST

DHCPACK

დაყენების

FreeBSD

Ubuntu

კონფიგურაცია

სერვერის დაწყება

გაღიზიანება

XML კონფიგურაციის ფაილის პარსერი

მრავალძაფიანი

DHCP პაკეტის მიღება/გაგზავნა

DHCP პაკეტის ანალიზი

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება