DHCP VPN-ის გავლით: ბროდკასტი ხიდით გადავიტანოთ თუ რელეთი?
გვირაბის მეორე მხარეს მყოფი კლიენტები მისამართს ვერ იღებენ. გადაწყვიტეთ, გადაიტანოთ ბროდკასტი თუ გადასცეთ რელეთი, და გამოყავით DHCP ARP-ისგან.
გვირაბის მეორე მხარეს ახალი ლეპტოპი მისამართს ვერ იღებს, მაშინ როცა იგივე ლეპტოპი ცენტრალურ ოფისში მუშაობს. ჩვეულებრივი პირველი ვარაუდია, რომ გვირაბი DHCP-ს ბლოკავს. უფრო ხშირად ბროდკასტს გზა არასოდეს ჰქონია: არაკონფიგურირებული კლიენტი აგზავნის 255.255.255.255-ზე, და ჩვეულებრივი IP მარშრუტიზატორი ამ პაკეტს არ გადასცემს. გვირაბი აკეთებს ზუსტად იმას, რასაც მარშრუტიზებული გვირაბი აკეთებს.
ორმა დიზაინმა შეიძლება შეცვალოს ეს, და ისინი ეკვივალენტური არ არიან. ერთი ბროდკასტს ატარებს; მეორე მოთხოვნას გადასცემს რელეთი.
ბროდკასტი მარშრუტიზატორს არასოდეს კვეთს
მისამართის გარეშე DHCPv4 კლიენტი აგზავნის 0.0.0.0-დან შეზღუდულ ბროდკასტის მისამართზე UDP პორტებით 67 და 68. ეს პაკეტი დიზაინის მიხედვით თავის რგოლზე რჩება. მარშრუტიზატორი, რომელიც მას გადასცემდა, დატბორავდა ყოველ სეგმენტს, რომელსაც ემსახურება.
ამრიგად, მარშრუტიზებული საიტ-საიტ გვირაბი რელეს სერვერს უკავშირებს. ის არ აფართოებს კლიენტის ბროდკასტის დომენს, და ვერც ერთი ფაირვოლის წესი ამას ვერ მოახდენს.
რას აფართოებს სინამდვილეში ხიდად ქცეული გვირაბი
განზრახ ხიდად ქცეულ VPN-ს შეუძლია Ethernet ბროდკასტი გადაიტანოს თავის მხარდაჭერილ ტოპოლოგიაში, და მაშინ DHCP შეიძლება ლოკალურ ტრაფიკად გაიაროს. ეს რეალური არჩევანია, მაგრამ 2-ე დონის დიზაინის გადაწყვეტილებაა. თქვენ აფართოებთ წარუმატებლობის დომენს და წვდომის საზღვარს ბროდკასტთან ერთად.
ხიდად ქცევა ასევე ცვლის, თუ რამდენად შორს შეიძლება მიაღწიოს ბროდკასტის ქარიშხალმა, ARP სკანირებამ ან თაღლითურმა DHCP სერვერმა. თუ დისტანციურ ოფისს იმავე კომუტატორთან არ შეაერთებდით, მაშინ მხოლოდ მისამართების გასანაწილებლად გვირაბს ნუ გადააქცევთ ხიდად. ჩართვამდე შეამოწმეთ ეს ზემოქმედების რადიუსი.
ეს უფრო დიდი გადაწყვეტილებაა, ვიდრე მისამართის მიცემა, და ის განზრახ უნდა მივიღოთ.
ამის ნაცვლად გადასცეთ მოთხოვნა რელეთი
ჩვეულებრივი პასუხია რელე კლიენტის ლოკალურ ქსელში. ის იღებს ბროდკასტს, გარდაქმნის unicast მოთხოვნად და თავის მისამართს კარიბჭის მისამართის ველში ათავსებს. სერვერი პასუხობს იმ რელეს მისამართზე.
საილუსტრაციო დისტანციური ოფისისთვის რელე ოფისის LAN-ზე ზის, ხოლო სერვერს საიტის VPN-ით აღწევენ. დააკონფიგურირეთ იმ ოფისის სფერო, რელესა და სერვერის იდენტობები და სრული დაბრუნების გზა. UDP 67-ის გვირაბით დაშვება სერვერს არ ეუბნება, რომელი აუზი გამოიყენოს.
რელე, რომელიც გადასცემს, მაგრამ პასუხს არასოდეს იღებს, ჩვეულებრივ დაბრუნების გზის პრობლემაა. სფეროს შეცვლამდე შეამოწმეთ მარშრუტი რელეს მისამართისკენ.
გამოყავით DHCP ARP-ისგან და გვირაბის მისამართებისგან
DHCP UDP/IP-ზე მიდის. Ethernet-ზე ჰოსტმა შეიძლება ARP-იც გამოიყენოს იმის შესამოწმებლად, უკვე გამოყენებულია თუ არა კანდიდატი მისამართი. ეს კონფლიქტის შემოწმება ცალკე რგოლ-ლოკალური ოპერაციაა, არა DHCP შეტყობინებების ტრანსპორტი. იმის თქმა, რომ DHCP არსებითად ARP-ია, არასწორია; იმის თქმა, რომ ეს ორი არასოდეს არის დაკავშირებული, ზედმეტად ფართოა.
VPN კლიენტს შეუძლია თავისი გვირაბის მისამართი მიიღოს VPN პროტოკოლისგან ან თავად სერვერის აუზიდან, და არა DHCP ბროდკასტიდან. ოპცია, რომლის სახელშიც DHCP-ია, შეიძლება აღწერდეს დაძალებულ კლიენტის პარამეტრებს და არა რელეთი გადაცემულ DHCP პაკეტს. სანამ ჩათვლით, რომ DHCP საერთოდ მონაწილეობს, შეამოწმეთ სერვერის აუზი.
ჩაწერეთ მიმღები ქსელი, გამოყოფის მფლობელი, სფერო, არსებობს თუ არა რელე და მოსალოდნელი ქცევა შეფერხების დროს. შემდეგ ამ მოდელით შეამოწმეთ ახალი იჯარა და განახლება. თუ ორ საიტს შეუძლია ერთი და იმავე აუთვისებელი აუზის მომსახურება, თქვენ გაქვთ კონფლიქტი, რომელიც პირველ მოძრავ ლეპტოპს ელოდება.