Pampublikong Wi-Fi at VPN: ano ang hindi sakop ng lagusan

Berdeng badge, nasisiyahang portal, gumaganang browser: iyan ang buong nakikitang kuwento. Ang iniiwan ng badge ay ang naka-encrypt na koneksyon ay dinadala mismo ng wireless link na dapat magprotekt sa iyo mula rito. Naghahatid pa rin ang link na iyon ng bawat packet, nakikita pa rin ang address ng destinasyon at nagpapasya pa rin kung may darating. Ang pagsusuri sa gilid ng laptop ng koneksyon sa hotel ay nagpapakita kung aling bahagi ang sakop ng lagusan at alin ang ipinapaubaya sa iyo.

Dinadala ng access link ang lahat

Binabalot ng IPsec ESP tunnel ang protektadong panloob na packet sa panlabas na header na kayang i-route ng network, at RFC 4303 seksyon 3.1.2 ang nagpapaliwanag ng paghahating iyon. Ang panloob na packet ang pinoprotektahan ng tunnel. Ang panlabas na header ang binabasa ng hotspot para ipasa ito. Iba ang pag-encapsulate ng ibang disenyo, ngunit ang tanong sa pagpaplano ay pareho: aling access path ang nagdadala ng koneksyong ito?

Ang pagpalya ng gateway o link na nagtatapon ng packet ay humihinto sa paghahatid nang hindi inilalantad ang nilalaman. Walang tulong dito ang paglipat sa mas malakas na cipher, dahil ang kulang na piraso ay transportasyon, hindi kriptograpiya. Ang matagumpay na paghahatid ay kasing-kaunti rin ang pinapatunayan sa kabilang direksyon, dahil ang gumaganang landas ay walang sinasabi tungkol sa kalagayan ng alinman sa dalawang makina.

May sariling mga pinto pa rin ang laptop mo

Ang pagsali sa hindi pinagkakatiwalaang segment ay nagbabago kung sino ang makakaabot sa mga port na pinakikinggan ng makina mo. Ang serbisyo ng pagbabahagi ng file, ahente ng malayuang administrasyon o development server na nakatali sa lahat ng interface ay maaabot ng kahit sino sa segment na iyon maliban kung may humaharang. Ang trapik na hindi kailanman pumapasok sa tunnel ay hindi protektado nito. Ang nakikinig na sumasagot bago umangat ang tunnel ay nakalantad nang eksakto sa window na iyon.

Makitid ang pangangailangan at dapat sabihin nang tumpak: dapat maabot ng laptop ang endpoint ng VPN, at ang mga hindi kaugnay na aparato sa hotspot ay hindi dapat makaabot sa lokal na serbisyo. Ipinapahayag ng mga patakaran ng firewall ng host ang hangganang iyon, at ipinapahayag din ng sariling mga setting ng pagbabahagi ng platform ang isang bahagi nito. Ang printer o hakbang sa portal ay limitadong eksepsyon na sinasadya mong idagdag, hindi patunay na ang buong hotspot ay karapat-dapat sa tiwala ng LAN ng opisina.

Nililimitahan din ng ilang organisasyon ang lokal na access habang aktibo ang koneksyon sa trabaho, at ito ay patakaran, hindi inhenyeriya. Basahin ang patakarang iyon bago i-disable ang firewall para gumana ang peripheral.

Suriin kung ano ang aktuwal na nakikinig

Tingnan ang mga socket at hindi ang pahina ng setting, dahil inilalarawan ng pahina ang layunin at inilalarawan ng talahanayan ng socket ang makina. Hinihiwalay ng dalawang listahan sa ibaba ang bawat socket na nakikinig mula sa mga maaabot ng kapitbahay. Patakbuhin ang mga ito sa hindi pinagkakatiwalaang segment bago ikonekta ang tunnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

Ipinapakita ng unang utos ang bawat socket, at ang pangalawa ay nagsasala sa mga nakatali sa labas ng loopback. Ang serbisyo sa 0.0.0.0 o :: ay available sa bawat interface, kabilang ang wireless, samantalang ang parehong serbisyo sa 127.0.0.1 ay hindi maabot mula sa segment. Kinukumpirma ng query ng resolver kung aling landas ang tinatahak ng pangalan bago umiral ang tunnel, at doon nagkakagulo ang mga captive portal. Ulitin ang listahan pagkatapos kumonekta, dahil may mga client na nag-aangat ng interface na nagbabago ng sagot.

Ang port na lumilitaw lamang habang nakaangat ang tunnel ay hindi gaanong nakalantad, kahit sulit pa ring malaman. Itala ang pagkakaiba at hindi ang absolutong listahan, dahil ang delta ang idinagdag ng tunnel.

Huwag tumanggap ng bagong pagkakakilanlan sa gitna ng sesyon

Ang hindi inaasahang pagbabago ng ruta, muling pagkonekta o pag-redirect ng portal ay hindi pahintulot na tanggapin ang ibang pagkakakilanlan ng server. Kung iniuulat ng client ang hindi pagtutugma ng sertipiko o key, ituring itong natuklasan tungkol sa pagkakakilanlan at hindi bilang koneksyon na dapat iwasan. Ang pag-install ng hindi maipaliwanag na root certificate para gumana ang portal ay ginagawang problema sa paghahatid ang isang problema sa tiwala. Pagkatapos, ang problema sa tiwala ay nabubuhay nang mas matagal kaysa sa paglalakbay na lumikha nito.

Gamitin ang sariling daloy ng browser ng portal, pagkatapos ay ikonekta muli ang tunnel at basahin sa log ng client kung aling pagkakakilanlan ang na-verify. Ang kabiguan sa pagkakakilanlan ay nangangahulugang ang kabilang panig ay hindi ang inaasahan mo, samantalang ang kabiguan sa paghahatid ay nangangahulugang hindi kailanman sumagot ang kabilang panig. Ang una ay dahilan para huminto, at ang pangalawa ay dahilan para subukan ang ibang landas.

Magpasya muna sa pag-uugali kapag may pagkaputol

Dalawang magkaibang tampok ang napagpapalit dito. Sinusubukan ng muling pagkonekta na ibalik ang serbisyo, samantalang kinokontrol ng patakaran ng pagharang kung aling trapik ang pinapayagan habang nakababa ang tunnel. Wala sa dalawa ang nagbibigay ng gumaganang wireless link, at wala sa dalawa ang nagpapatunay na malinis ang endpoint. Pumili nang tahasan: saradong kabiguan para sa mga app na hindi dapat gumamit ng lokal na landas, at payagan ang ordinaryong pag-browse sa labas ng tunnel kung katanggap-tanggap iyon.

Isulat ang pagpipilian, dahil ang default sa karamihan ng client ay wala sa dalawa, at nag-iiba ito ayon sa bersyon. Pagkatapos ay maghanda ng alternatibong access path kung mahalaga ang availability, tulad ng hotspot ng telepono na may sariling data plan. Ang katanggap-tanggap na pagsubok sa pagtanggap ay may tatlong hiwalay na resulta: ginagamit ng nilalayong trapik ang na-verify na tunnel, hindi maaabot ang mga hindi kaugnay na lokal na nakikinig, at ang pagkaputol ay gumagawa ng pag-uugaling pinili mo.