Nakabukas ang VPN, hindi maabot ang VM? Malamang hindi kailanman ang ruta ang problema

Ikonekta ang VPN, at ang development VM na sumasagot isang minuto lang ang nakalipas ay tatahimik. Ang halatang kuwento ay nagsusulat mismo: kinuha ng tunel ang ruta, ipinapadala na ngayon ng host ang trapiko ng bisita sa corporate network, at ang solusyon ay magdagdag ng static na ruta o palitan ang adapter sa bridge mode. Ang kuwentong iyon ay totoo kung minsan. Ngunit hindi iyon ang karaniwang dahilan, at ang pag-aksyon dito nang una ay karaniwang nakakasira ng ibang bagay.

Ang host-only networking ay isang software network na pag-aari ng host at ibinabahagi sa mga bisita nito, hiwalay sa anumang pisikal na koneksyon. Walang anuman sa sariling interface ng VPN client ang nagbabago sa network na iyon, kaya bago ito hawakan, alamin kung alin sa apat na layer ang talagang nabigo.

Karaniwang lokal pa rin ang ruta

Tanungin ang kernel sa halip na ang unang pahina ng routing table. Sa Linux, ang ip route get 192.168.56.10 ay nag-uulat ng eksaktong ruta, interface at source address na gagamitin, na ibang sagot kaysa sa pagbasa ng default na ruta at paghula. Kung pinangalanan ng output ang host-only interface, wala talagang kinalaman ang tunel sa landas na iyon.

Dalawang bagay ang tunay na makakasira nito, at parehong problema sa address, hindi sa VPN. Ang malayong subnet na nagsasapawan sa host-only prefix ay nagpapapanalo sa mas tiyak na ruta, at ang VPN client na naglalagay ng malawak na ruta na may mas mababang metric ay maaaring humatak sa prefix. Pareho silang nakikita sa iisang utos: ang interface na pinangalanan sa output ang magiging tunel, at ang pagwawasto ay pag-aari ng may-ari ng address plan na iyon.

Ang pagpili ng ruta at pagtanggap ng packet ay dalawang magkaibang desisyon

Ito ang bahaging madalas palampasin ng mental model. Kahit may perpektong lokal na ruta, maaaring tanggihan ng VPN client ang packet. Maraming kliyente ang nagpapatupad ng lokal na patakaran sa pag-access sa network na nagpapasya kung aling mga destinasyon ang pinapayagan sa labas ng tunel, at ang konektadong subnet ay hindi awtomatikong nag-a-update ng listahang iyon.

Kaya ang kabiguan ay mukhang katulad ng problema sa routing mula sa panig ng aplikasyon, at lubos na naiiba mula sa panig ng kliyente. Kung pinangalanan ng ip route get ang tamang interface ngunit nag-expire pa rin ang koneksyon, itigil ang pag-edit ng mga ruta at basahin na lang ang dokumentadong lokal na pag-access na pag-uugali ng kliyente. Ang ilang kliyente ay may allowlist para sa mga lokal na subnet, ang iba ay hinaharang ang lahat ng hindi tunel, at ang iba ay humaharang lamang kapag naka-enable ang kill switch.

Mahalaga ang pagkakaibang iyon dahil hindi mapagpapalit ang mga pagwawasto. Ang pagdaragdag ng ruta ay hindi makakasatisfy sa isang filter, at ang pag-disable ng filter upang maabot ang isang bisita ay mas malaking desisyon kaysa sa ipinahihiwatig ng sintomas.

May tatlong paraan ang bisita para magsabi ng hindi

Ang bisitang nakakapag-browse sa internet ay walang napatunayan tungkol sa serbisyong gusto mo. Maaaring nakatali ang nakikinig sa 127.0.0.1 sa loob ng bisita, at sa kasong iyon walang kahilingan mula sa host ang makakarating, gaano man kaganda ang landas. Suriin gamit ang ss -ltn sa bisita at tingnan ang column ng lokal na address, hindi lamang ang port.

Susunod ay ang sariling firewall ng bisita. Ang development image na may mahigpit na default ay maaaring tumanggap ng mga packet ng host at ihulog ang mga ito sa hangganan ng serbisyo, na gumagawa ng timeout na mukhang eksaktong katulad ng routing black hole. Panghuli, naroon ang sariling configuration ng serbisyo: ang web app na nakatali sa partikular na hostname, o listahan ng pinapayagang client address, ay tatanggihan ang kahilingan mula sa host-only subnet kahit dumating ang bawat packet.

Suriin ang tatlong iyon bago isaalang-alang ang pagbabago ng network mode ng VM. Ang bawat isa ay mas maliit na pagbabago kaysa sa muling pagdidisenyo ng koneksyon ng bisita, at bawat isa ay may malinaw na pagsubok.

Ano talaga ang bridge, at magkano ito

Ang paglipat ng adapter sa bridge mode ay hindi pag-aayos ng host-only na landas. Ito ay desisyon na ilagay ang bisita sa ibang network, karaniwang ang pisikal na LAN, kung saan siya ay nagiging nakikita ng lahat ng iba pang naninirahan doon. Maaaring iyon mismo ang gusto mo. Ngunit hindi iyon ang ginagawa ng orihinal na configuration.

Gamitin ito kapag ang bisita ay talagang kailangang maging kapantay sa LAN na iyon at aprubado ang pagkakalantad. Huwag itong gamitin dahil tumigil sa pagsagot ang isang serbisyo, dahil maaaring ilabas ng pagbabago ang bisita mula sa paghihiwalay na nagpapanatiling ligtas ang pag-develop laban dito.

Pagkatapos ng anumang aprubadong pagwawasto, subukan sa tiyak na pagkakasunod-sunod: bagong kahilingan mula host patungo sa bisita, kinakailangang corporate resource sa pamamagitan ng tunel, at ang sinadyang pagtanggi na pag-uugali kapag patay ang tunel. Kung hindi na umiiral ang huli, lumampas ang pagwawasto sa problema.

Ang seksyon ng VirtualBox tungkol sa host-only networking ay naglalarawan ng software interface sa panig ng host at kung paano ito naiiba sa bridge connection, na siyang reperensiyang dapat basahin bago ipagpalagay na mapagpapalit ang dalawang mode.