Jūsu VPN baseins nav LAN DHCP diapazons: kāpēc tas lūzt

Kārdinošais īsākais ceļš ir piešķirt VPN klientiem adreses no tā paša diapazona, ko izmanto biroja DHCP serveris, balstoties uz pieņēmumu, ka viss taču ir viens tīkls. Nav. Maršrutēts tunelis pārvieto unicast paketes starp diviem galiem, bet LAN baseins pastāv, lai atbildētu uz apraides pieprasījumiem fiziskā segmentā. To pašu numuru izmantošana liek diviem sadalītājiem atbildēt par vienu adrešu telpu un atstāj atgriešanās ceļu nedefinētu.

Divi sadalītāji, viena adrešu telpa

LAN DHCP serveris zina, kuras adreses tas ir iznomājis un kurai MAC adresei, un aizstāv tās ar ARP. VPN serverim ir savs baseins, un tas neko nezina par šiem nomas līgumiem. Neviens nekļūdās; viņi vienkārši nekad netika iepazīstināti.

Adrese no LAN baseina, ko izsniedz VPN serveris, var jau piederēt printerim. Tagad divas ierīces pretendē uz vienu adresi vienā prefiksā, un komutatora pārsūtīšanas tabula izlemj, kura atbildēs.

Tas ir bojājums, ar ko cilvēki sastopas pirmie: klients, kas veiksmīgi pieslēdzas un pēc tam nonāk nepareizajā mašīnā, vai nonāk pareizajā ar pārtraukumiem.

Kāpēc maršrutētājs neizplata VPN adreses

DHCP atklāšana ir apraide, un apraides apstājas pie maršrutētas robežas. Ja projekts nesavieno tuneli ar tiltu vai nepalaiž DHCP releju ar atbilstošām pilnvarām, klienta pieprasījums nekad nesasniedz LAN serveri.

Tāpēc VPN serveris adresi piešķir pats: baseins servera konfigurācijā, adrese katram partnerim WireGuard iestatījumā, vai adrese, ko autentifikācijas slānis iebīda IKEv2 ieviešanā. Šie mehānismi nav atkarīgi no LAN nomas datubāzes, un tieši tāpēc tiem vajadzīgs savs diapazons.

Tā pati loģika izskaidro, kāpēc DHCP apgabala maiņa nesalabo VPN klientu, kas nekad nesaņem adresi. Klients nejautā LAN serverim, un nekāda apgabala rediģēšana neliks tam jautāt.

Pārklāšanās izpaužas kā konflikts, nevis kā lēns tīkls

Divi tīkli, kas dala prefiksu bez atbalstīta projekta, ir cita problēma nekā dubultas īpašumtiesības, un tos bieži sajauc. Ja VPN baseins ir atsevišķs prefikss, pārklāšanās ir svarīga tikai tad, kad maršruts sūta trafiku uz nepareizo pusi. Ja baseins atrodas LAN prefiksa iekšpusē, konflikts ir tūlītējs un vietējs.

Praksē jūs redzat ARP atbildes no nepareizās ierīces, savienojumus, kas atiestatās pusceļā, un klientu, kura paša adresi pieprasa kāds cits. Nekas no tā neizskatās pēc maršrutēšanas problēmas, tāpēc labojums tiek piemērots nepareizajam slānim. Dubulta noma ir viegli apstiprināma un nepatīkama, ar to dzīvojot. Tā pārdzīvo arī pārstartēšanu, jo abi sadalītāji turpina uzstāt uz to pašu adresi.

Atgriešanās ceļš ir atsevišķa problēma

Pat ar tīru, atsevišķu baseinu LAN resursdatoriem jāzina, kā atbildēt klientam. Viņu noklusējuma vārteja ir maršrutētājs, un maršrutētājam vajadzīgs maršruts baseinam, kas norāda uz VPN serveri, ja vien projekts tā vietā netulko klienta trafiku.

Izlasiet ceļu abos virzienos, pirms kaut ko maināt. Vārtejā pajautājiet, kuru saskarni kodols izmantotu klienta adresei; klientā pajautājiet, kuru maršrutu tas izmanto LAN adresei.

Šīs komandas parāda pārsūtīšanas lēmumu vārtejā un kaimiņu ierakstus, kas atklāj dublikātu:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Ja pirmā komanda atbild ar tuneļa saskarni, atgriešanās maršruts pastāv. Ja tā atbild ar LAN saskarni, maršrutētājs uzskata, ka klients ir uz vada, un mēģinās tam veikt ARP.

Tiltotie projekti pastāv, bet tie ir jāizvēlas

Tuneļa savienošana ar LAN tiltu ir īsts projekts, ko izmanto, kad klientiem jāsaņem apraide vai tie jāatklāj protokoliem, kas pieņem vienu segmentu. Tas prasa, lai serverim piederētu šī tilta uzvedība un ar to saistītā adrešu apstrāde.

Tas, kas nedarbojas, ir rezultāta atdarināšana, kopējot numurus. Kopīgs baseins bez tilta dod konfliktu bez atklāšanas, kas ir sliktākais no abiem izkārtojumiem.

Izvēlieties trešo slāni ar atsevišķu baseinu, ja vien lietojumprogrammai tiešām nav vajadzīgs segments, un dokumentējiet baseinu, lai nākamais administrators atkal neizmantotu DHCP diapazonu kārtības dēļ.