Router sa VPN client mode: bakit nawawala ang mga device sa LAN

Ang paniniwalang ang client mode mismo ang pumapatay sa LAN access ay nagdadala ng mga tao sa maling settings menu, at ang tunay na dahilan ay karaniwang dalawa. Hindi inaalis ng tunnel ang LAN bridge at hindi pinipigilan ang wired at wireless clients na maabot ang isa't isa. Ang sumisira sa lokal na access ay alinman sa inspection feature sa forward path ng router o isang LAN address range na gumalaw nang gawin ito ng firmware. Pareho silang nagdudulot ng parehong reklamo, at wala sa kanila ang naayos sa muling pag-install ng VPN profile.

Ang mito, at ano talaga ang binabago ng client mode

Nagdadagdag ang client mode ng tunnel interface at default route na dumadaan dito, at pagkatapos ay ipinapasa ang LAN traffic sa tunnel na iyon. Nananatiling buo ang bridge sa pagitan ng wired ports at wireless radios, gayundin ang lokal na switching. Ang binabago ay patakaran: aling traffic ang ipinapasa, saan ito isinasalin at aling resolver ang natatanggap ng mga client.

Mahalaga ang pagkakaibang iyon dahil ang sirang LAN ay karaniwang nangangahulugang nagbago ang isa sa tatlong patakarang iyon, hindi na tumigil ang router sa pagiging switch. Ang router na sumasagot pa rin sa sarili nitong administration page ay patunay na buhay ang LAN interface. Ang router na walang sinasagot ay may ibang problema, tulad ng binagong LAN address o client sa maling subnet.

Kaya ang kapaki-pakinabang na unang hakbang ay alamin kung aling layer ang nasira, hindi baguhin ang layer na pinaghihinalaan mo.

Subukan ang tatlong target bago hawakan ang isang setting

Mula sa wired client, subukan ang tatlong target nang hiwalay at isulat ang bawat resulta: ang sariling LAN address ng router, isa pang device sa parehong switch ayon sa IP, at isang bagay na maaabot lamang sa tunnel. Gawin sa ganoong pagkakasunod-sunod, dahil ang bawat resulta ay nag-aalis ng ibang layer. Gumamit ng address sa halip na pangalan sa unang pag-ikot, dahil ang pagkabigo ng pangalan ay naghahalo ng DNS sa tanong ng connectivity.

Ang pattern ng mga sagot ang diagnosis. Ang router na sumasagot habang ang mga lokal na device ay hindi, ay tumutukoy sa lokal na switching o filtering feature kaysa routing. Ang mga lokal na device na sumasagot habang ang tunnel side ay hindi, ay tumutukoy sa tunnel route o remote firewall. Kung lahat ay sumasagot sa address pero nabibigo ang mga pangalan, tanong ito ng resolver, at walang route editing ang makakaayos.

Itago ang talahanayan sa tabi ng mga resulta ng test. Ginagawa nitong isang linya na maaari mong aksyunan ang malabong reklamo.

Ang security layer sa loob ng forward path

Ang mga consumer router ay parami nang parami ang may inspection feature na nagbabantay sa ipinapasang traffic, at tumatakbo ito sa parehong path na nagdadala ng packets mula LAN papuntang tunnel. Kapag hindi ma-classify ng inspection na iyon ang tunnel traffic, maaaring tumigil ang forwarding habang nananatiling aktibo ang tunnel at nag-uulat ang router ng malusog na koneksyon. Walang makikita sa VPN log, dahil talagang nakakonekta ang VPN.

Ang diagnosis ay kontroladong eksperimento, hindi permanenteng pagbabago. Itala ang kasalukuyang setting, patayin ang feature sa loob ng isang test, iangat muli ang tunnel at subukan ang isang lokal na host ayon sa address. Ang forwarding na bumabalik ang patunay na kailangan mo, at ang trade-off ay nagiging desisyon sa halip na hula. Kung walang nagbago, agad itong i-on muli at pumunta sa dahilan ng addressing.

Ang iwanang patay ang bayad na security feature para magpatuloy ang tunnel ay isang trade-off na dapat gawin nang sinasadya at itala. Sulit ding itanong kung dapat nasa ibang device ang tunnel, dahil ang router na kailangang inspeksyunin ang lahat at router na kailangang ipasa ang lahat ay dalawang magkaibang trabaho.

Ang ikalawang dahilan: gumalaw ang LAN range

Ang mga firmware update ay regular na nagbabalik ng LAN address sa default ng manufacturer, at may mga router na may malinaw na mode switch na nagpapasya kung pananatilihin ng LAN ang private range o mamana ang isa mula sa device sa itaas. Ang client na umaasa sa 192.168.8.x ay maaaring mapunta sa 10.64.0.x, at pagkatapos ay mag-expire ang SSH session sa isang host kahit perpektong malusog ang tunnel.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Basahin ang prefix at gateway mula sa lease bago buksan ang router page. Ipinapakita ng unang dalawang command ang aktwal na natanggap ng client, at ang pangatlo ay nagpapakita kung aling interface ang gagamitin ng client para sa lokal na address, at ganoon nahahayag ang natitirang route o lumang subnet. Pagkatapos ihambing iyon sa LAN page at sa mode kung saan naroroon ang router.

Kung hindi na makabalik ang range, i-update ang bawat object na tumutukoy dito: DHCP reservations, anumang static route papunta sa lumang subnet at bawat firewall rule na may dating prefix. Ang range na bumabangga sa remote subnet ng tunnel ay ang mas masamang variant, dahil nananatiling maabot ang mga lokal na device habang tahimik na nadidirekta ang malalayong destinasyon sa LAN.

Kumonekta muli at muling subukan sa ayos ng packet

Pagkatapos ng alinman sa dalawang pagbabago, kumonekta muli sa tunnel at ulitin ang mga test sa ayos ng packet: router, lokal na host, remote na host, pagkatapos ay mga pangalan, pagkatapos ang application. Ang pagsubok sa application muna ay nagtatago kung aling layer ang sira pa, at ang muling pagsubok ng browser sa naka-cache na pangalan ay maaaring magmukhang routing failure.

Itala ang firmware version, LAN prefix at estado ng inspection feature sa tabi ng VPN profile. Ang tatlo ay configuration na maaaring i-overwrite ng susunod na update, at ang dalawang linya ng notes ay nakakatipid ng oras na ginugol mo lang.