Ang pool ng VPN mo ay hindi ang DHCP range ng LAN: bakit ito nasisira

Ang tuksong shortcut ay bigyan ang mga kliyente ng VPN ng mga address mula sa parehong range na ginagamit ng DHCP server ng opisina, sa teoryang isang network lang naman ang lahat. Hindi. Ang routed tunnel ay nagdadala ng mga unicast packet sa pagitan ng dalawang dulo, habang ang pool ng LAN ay umiiral para sagutin ang mga broadcast request sa isang pisikal na segment. Ang muling paggamit ng mga numero ay naglalagay ng dalawang allocator na may pananagutan sa isang address space at iniiwan ang pabalik na ruta na hindi natukoy.

Dalawang allocator, isang address space

Alam ng DHCP server ng LAN kung aling mga address ang ipinaupa niya at sa aling MAC address, at ipinagtatanggol niya ang mga ito sa ARP. Ang VPN server ay may sariling pool at wala siyang alam sa mga lease na iyon. Wala sa dalawa ang mali; hindi lang sila kailanman ipinakilala sa isa't isa.

Ang address mula sa pool ng LAN na ibinibigay ng VPN server ay maaaring pag-aari na ng isang printer. Ngayon dalawang device ang nag-aangkin ng isang address sa parehong prefix, at ang forwarding table ng switch ang nagpapasya kung sino ang sasagot.

Iyan ang failure na unang natatagpuan ng mga tao: isang kliyenteng matagumpay na kumokonekta at pagkatapos ay nakakarating sa maling makina, o nakakarating sa tama nang pahinto-hinto.

Bakit hindi namimigay ng VPN address ang router

Ang DHCP discovery ay isang broadcast, at ang mga broadcast ay humihinto sa isang routed boundary. Maliban kung ang disenyo ay nag-bridge sa tunnel o nagpapatakbo ng DHCP relay na may tugmang awtoridad, hindi kailanman nakakarating ang request ng kliyente sa LAN server.

Kaya ang VPN server mismo ang nagtatalaga ng address: isang pool sa configuration ng server, isang address bawat peer sa isang WireGuard setup, o isang address na itinutulak ng authentication layer sa isang IKEv2 deployment. Ang mga mekanismong ito ay independiyente sa lease database ng LAN, at iyon mismo ang dahilan kung bakit kailangan nila ng sariling range.

Ang parehong pangangatwiran ay nagpapaliwanag kung bakit ang pagbabago ng DHCP scope ay hindi nag-aayos ng VPN client na hindi kailanman nakakakuha ng address. Hindi tinatanong ng kliyente ang LAN server, at walang pag-edit ng scope ang makapagpapatanong sa kanya.

Ang overlap ay lumalabas bilang conflict, hindi bilang mabagal na network

Ang dalawang network na nagbabahagi ng prefix na walang sinusuportahang disenyo ay ibang problema sa double ownership, at madalas silang napagkakamalan. Kung ang VPN pool ay hiwalay na prefix, ang overlap ay mahalaga lamang kapag may rutang nagpapadala ng trapiko sa maling panig. Kung ang pool ay nasa loob ng prefix ng LAN, ang conflict ay agaran at lokal.

Sa praktika makikita mo ang mga ARP reply mula sa maling device, mga koneksyong nagre-reset sa kalagitnaan, at isang kliyenteng ang sariling address ay inaangkin ng iba. Wala sa mga ito ang mukhang problema sa routing, kaya inilalapat ang pagwawasto sa maling layer. Ang dobleng lease ay madaling kumpirmahin at nakakainis pakisamahan. Nakakaligtas din ito sa mga reboot, dahil ang dalawang allocator ay patuloy na nagsisigi sa parehong address.

Ang pabalik na ruta ay hiwalay na problema

Kahit may malinis at hiwalay na pool, kailangang malaman ng mga host ng LAN kung paano sasagutin ang isang kliyente. Ang default gateway nila ay ang router, at ang router ay nangangailangan ng ruta para sa pool na tumuturo sa VPN server, maliban kung isinasalin ng disenyo ang trapiko ng kliyente.

Basahin ang ruta sa dalawang direksyon bago baguhin ang anuman. Sa gateway, itanong kung aling interface ang gagamitin ng kernel para sa address ng kliyente; sa kliyente, itanong kung aling ruta ang ginagamit nito para sa address ng LAN.

Ipinapakita ng mga command na ito ang desisyon sa forwarding sa gateway at ang mga neighbor entry na naglalantad ng duplicate:

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

Kung ang unang command ay sumasagot gamit ang tunnel interface, umiiral ang pabalik na ruta. Kung sumasagot ito gamit ang LAN interface, naniniwala ang router na ang kliyente ay nasa kable at susubukan nitong gumawa ng ARP para sa kanya.

May mga bridged na disenyo, ngunit kailangang piliin ang mga ito

Ang pag-bridge ng tunnel sa LAN ay tunay na disenyo, ginagamit kapag kailangang tumanggap ng broadcast ng mga kliyente o matuklasan sila ng mga protocol na nagpapalagay ng isang segment. Kailangan nitong pag-aari ng server ang ganoong pag-uugali sa bridge at ang paghawak ng address na kasama nito.

Ang hindi gumagana ay ang paggaya sa resulta sa pamamagitan ng pagkopya ng mga numero. Ang pinagsasaluhang pool na walang bridge ay nagbibigay sa iyo ng conflict na walang pagtuklas, na siyang pinakamasama sa dalawang kaayusan.

Piliin ang layer three na may hiwalay na pool maliban kung tunay na kailangan ng application ang segment, at idokumento ang pool upang hindi muling gamitin ng susunod na administrator ang DHCP range dahil sa kaayusan.