Bakit tinatago ng full-tunnel VPN ang iyong rutadong lokal na VLAN

Ang switch na “payagan ang lokal na network” sa isang VPN client ay parang sinasaklaw ang lahat sa gusali. Sa pagsasanay, karaniwan itong nagdaragdag ng ilang eksepsiyon sa pribadong address sa default na ruta ng tunnel at doon na lang natatapos. Ang iyong storage VLAN ay naaabot pa rin lamang kung may rutang para sa partikular na prefix na iyon na nakakaligtas sa pagdating ng tunnel, at sa maraming client ay hindi ito nakakaligtas.

Ito ay tanong sa routing at hindi setting ng VPN, na mabuting balita: may konkretong sagot ito.

Ano ba talaga ang sinasaklaw ng payagan-ang-lokal-na-network

Iba-iba ang pagpapatupad ng mga client sa opsyong iyon. May nagdaragdag ng ruta para sa subnet na kinabibilangan ng makina, may nagdaragdag ng mga saklaw ng RFC 1918, at kakaunti lang ang nagbubukod lamang ng default gateway. Wala sa kanila ang nakakaalam na ang router ng opisina mo ay naglilingkod din ng storage VLAN, segment ng lab, o subnet ng printer, dahil ang mga prefix na iyon ay wala sa link na nakikita ng client. Basahin ang sariling dokumentasyon ng client para sa eksaktong pag-uugali sa halip na ipagpalagay na inilalarawan ng label ang topolohiya mo.

Pinakamahalaga ang pagkakaibang ito sa disenyong full tunnel, kung saan sadyang pinapalitan ng client ang default na ruta para dumaan sa VPN ang lahat ng trapiko. Iyan ang buong layunin ng disenyo, at iyan din ang nagpapawala sa mga lokal na rutadong network. Hindi sila kailanman nasaklaw ng sarili nilang ruta; sumasakay sila sa default na rutang kakakapalit lang. Hindi maruruta ng client ang hindi nito alam na umiiral, at natututo lamang ito tungkol sa mga prefix na nakakabit sa sarili nitong interface. Ang lahat ng iba pa ay dapat ilarawan ng taong nakakaalam ng topolohiya.

Humihinto ang mga konektadong ruta sa unang router

Ang workstation sa 192.168.10.20/24 na may gateway na 192.168.10.1 ay awtomatikong nakakakuha ng konektadong ruta para sa 192.168.10.0/24. Ang storage VLAN sa 192.168.20.0/24 ay ibang prefix, naaabot lamang sa pamamagitan ng gateway na iyon, at walang ruta ang workstation para dito bukod sa default. Bago umangat ang tunnel, ang ordinaryong default ay nagpapadala ng trapiko ng storage sa 192.168.10.1 at gumagana ang lahat.

Kapag nag-install ang VPN ng default na full tunnel, sinusundan ng mga packet para sa 192.168.20.1 ang bagong default papasok sa tunnel. Walang ideya ang remote gateway kung saan nakatira ang prefix na iyon, kaya ibinabagsak ito o ipinapasa sa isang lugar na walang silbi. Walang na-miskonfigur sa storage VLAN; hiniram ang landas nito, at sinisingil ang utang.

Ang tukso ay abutin ang malawak na eksepsiyon tulad ng pares ng rutang /1 o pangalawang default. Labanan ito. Kapag mas makitid ang eksepsiyon, mas madali itong ipaliwanag, i-audit, at alisin kapag nagbago ang network.

Ilagay ang eksepsiyon sa talahanayang nananalo

Sa loob ng isang routing table, tinatalo ng /24 ang /0 o /1 sa pinakamahabang prefix match, kaya sapat ang partikular na ruta patungo sa storage VLAN sa pamamagitan ng lokal na gateway, basta konsultahin ang talahanayan. Sa Linux, maikli ang karaniwang anyo:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Pinapakumplikado ng policy routing ang garantiya. Maaaring magpadala ang naunang panuntunan ng trapiko sa isang talahanayang ang sariling default na ruta ay tumuturo sa tunnel, at ang pangunahing talahanayang may hawak ng /24 mo ay hindi na maaabot. Suriin ang mga panuntunan bago ipagpalagay na awtoritatibo ang ruta, dahil ang entry na mukhang tama sa maling talahanayan ay nagpapaliwanag ng pagkabigo na mukhang sirang ruta.

Pagkatapos, gawing permanente ang entry sa pamamagitan ng sinusuportahang mekanismo ng client o ng network manager na may-ari ng interface. Naglalaho sa susunod na reconnect ang rutang tinipa sa prompt, at ang rutang nakatali sa isang Wi-Fi gateway ay hindi madadala sa susunod na network na bibisitahin ng laptop.

Hindi sumusunod ang mga pangalan at patakaran sa mga ruta

Ang pag-aayos ng ruta ay nagbabalik ng mga packet, hindi ng mga pangalan. Kung ang mga lokal na device ay nireresolba sa pamamagitan ng itinulak na resolver na walang alam tungkol sa kanila, nabibigo pa rin ang mount kahit naaabot ang address. Kailangan ng mga lokal na pangalan ang lokal o hinati na DNS, at hiwalay na desisyon iyon sa eksepsiyon sa ruta.

Hiwalay na naman ang patakaran. Maaaring sadyang ipagbawal ng filter ng lokal na access ng VPN client ang trapiko sa mga pribadong saklaw, at hindi binabaligtad ng ruta ang panuntunang iyon. Sa isang network na hindi mapagkakatiwalaan, ang pribadong address ay hindi rin patunay na ang destinasyon ay ang iyong storage server, kaya dapat kasing-tiyak ng ruta ang eksepsiyon.

Isang kontratang maipapasa mo

Dapat basahin ang tapos na disenyo bilang maikling listahan: sinusundan ng pangkalahatang trapiko sa internet ang tunnel, at pinapanatili ng mga pinangalanang lokal na prefix na ito ang kanilang landas sa lokal na router. Isulat ang mga prefix, ang susunod na pagtalon, at ang DNS suffix na kasama nila, at panatilihing sapat na maikli ang listahan upang ma-verify ito ng iba nang hindi binabasa ang routing table.

Mag-ingat sa overlap sa pagitan ng lokal at remote na saklaw. Ang storage VLAN na nakikibahagi ng prefix sa isang bagay sa likod ng VPN ay maireresolba sa rutang mas partikular, at ang resulta ay nakakalito sa paraang mukhang paminsan-minsan. Ang muling pagbilang ng isang panig ay karaniwang mas mura kaysa sa walang hanggang pag-debug ng kalabuan.

Subukan ang kontrata nang dalawang beses: isang beses na nakataas ang tunnel at isang beses na nakababa. Kung gumagana ang lokal na landas sa isa lamang sa mga estadong iyon, hindi pa ito kontrata.