Piešķiriet LAN resursdatoriem VPN atgriešanās maršrutu ar DHCP 121. opciju

Attālinātie VPN klienti pieslēdzas, LAN serveris atbild, un atbilde iziet caur parasto interneta maršrutētāju un tur nomirst. Vienu serveri var salabot ar statisku maršrutu, bet veselu to apakštīklu labāk pārvaldīt tur, kur tie jau saņem savu tīkla konfigurāciju. DHCPv4 121. opcija izplata tieši šādu galamērķa maršrutu, un tā ir tā daļa, ko cilvēki parasti izdara nepareizi, tiklīdz aizmirst noklusējumu. Simptoms ir vienvirziena trafiks: pieprasījumi ierodas, bet atbildes pazūd.

Vispirms nosauciet trīs adreses

Ņemiet konkrētu LAN: 192.168.50.0/24 ar parasto noklusējuma maršrutētāju 192.168.50.1 un atsevišķu VPN vārteju 192.168.50.2. Autentificēti attālinātie klienti aizņem 10.90.0.0/24.

Maršruts, kas vajadzīgs katram iesaistītajam resursdatoram, ir 10.90.0.0/24 via 192.168.50.2. Galamērķis ir klientu kopa, un nākamais lēciens ir vārtejas LAN adrese, nevis tās tuneļa adrese.

Kodējiet to kā bezklašu statisku maršrutu

121. opcija pārvadā prefiksa un nākamā lēciena pārus, un RFC 3442 nosaka gan kodējumu, gan no tā izrietošo klienta uzvedību. Esošai dnsmasq instancei, kas apkalpo tikai šo ilustratīvo LAN, konfigurācijas forma ir šāda:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Tas ir fragments, nevis jauns DHCP pakalpojums. Serverī, kas apkalpo vairākus segmentus, ierobežojiet opciju ar tagiem vai tīkla politiku, ko jau lietojat. Turiet iepriekšējo konfigurāciju pie rokas, jo atgriešana nozīmē vēl vienu nomas atjauninājumu, nevis pārstartēšanu.

Nezāudējiet noklusējuma maršrutu

Šie ir slazdi. Klientam, kas saņem 121. opciju, ir jāignorē parastā Router opcija, tāpēc, izsludinot tikai VPN kopas maršrutu, var atstāt šo resursdatoru pilnīgi bez noklusējuma maršruta. Iekārta joprojām izskatās konfigurēta un klusi zaudē internetu. Lietotāji to raksturo kā tīkla kritienu, kamēr visas saskarnes ir augšā.

Iekļaujiet paredzēto noklusējumu tajā pašā sarakstā, kā to dara iepriekšējais fragments. Paturiet arī parasto Router opciju klientiem, kas neievieš bezklašu maršrutus; servera paša opciju apstrāde izlemj, kas kam tiek sūtīts.

Pārbaudiet, ko klients pieņems

Resursdators ar manuālu adresi to nekad neuztver, jo tas nepieprasa nomu. Arī klientu atbalsts atšķiras, tāpēc testējiet tajā operētājsistēmā, ko patiešām lietojat, nevis pieņemiet, ka katra ierīce ievēro 121. opciju. Pārliecinieties pie šo serveru īpašniekiem, kuriem ir statiska adrese. Šiem resursdatoriem vajadzīgi savi maršruta ieraksti, citādi tie vienkārši nepiedalīsies.

Pārvaldīti DHCP pakalpojumi ir vēl viena robeža. Daži mākoņu tīkli neļauj administratoriem publicēt patvaļīgas opcijas, un konkurējošs DHCP serveris tajā pašā segmentā ir sliktāk nekā nekāda opcija.

Pārbaudiet nomu, tad meklēšanu

Lūdziet DHCP īpašniekam piemērot izmaiņas, pēc tam atjauniniet nomu klientā. Esošās nomas saglabā veco konfigurāciju, līdz tās tiek atjauninātas, tāpēc tūlītējs rezultāts nav garantēts.

Linux klientā nolasiet faktiskos maršrutus un apstipriniet abus ierakstus:

ip -4 route
ip -4 route get 10.90.0.23

Kontekstuālajai meklēšanai jārāda kopas maršruts caur 192.168.50.2 un noklusējums caur 192.168.50.1. Ja noklusējuma nav, esat atkārtojis iepriekš aprakstītos slazdus.

Pēc tam pārbaudiet īsto apmaiņu

Maršrutu izplatīšana nav viss ceļš. Atsevišķai vārtejai joprojām vajadzīga pāradresācija, attālināto partneru piederība un piekļuves politika, kas atļauj serveri, un DHCP nevienu neautentificē.

Visbeidzot, turiet noņemšanas plānu. Apgūts statisks maršruts pats neatkāpjas, kad VPN nokrīt, tāpēc novecojis nākamais lēciens var pārvērst šo prefiksu melnajā caurumā ilgi pēc tam, kad tunelis ir pazudis.