Ĉu kill switch blokas vian printilon? Tri kontroloj unue

Via printilo funkciis antaŭ horo. Poste vi ŝaltis la VPN, kaj nun laboroj staras en la vico ĝis ili malsukcesos. La kill switch estas la verŝajna kaŭzo, ne la printilo: ĝi faligas trafikon, kiu forlasus la maŝinon ekster la tunelo, kaj LAN-printilo estas ĝuste tia trafiko. La vera decido ne estas kiel ripari presadon, sed ĉu ĉi tiu aparato entute devas atingi la lokan reton. Tri kondiĉoj solvas tion, kaj iu ajn el ili povas fini la diskuton frue.

Kion la kill switch faligas kaj kial

Kill switch estas enkursiga regulo kun alkroĉita fiaska reĝimo. Dum la tunelo staras, kongruaj pakaĵoj eliras ĉifritaj; kiam la tunelo falas, la kliento direktas la defaŭltan vojon en nigran truon, por ke nenio eliru en klara teksto. Printilo en la sama subreto neniam kongruas kun la tunela vojo, do ĝi estas traktata kiel provo eskapi, eĉ se la trafiko neniam forlasas la konstruaĵon.

Malkovro igas la simpton konfuza. Printiloj anoncas sin per multdissenda DNS sur pordo 5353, kaj la vico en la printilo-aldona dialogo konstruiĝas el tiuj anoncoj. Dum la blokado aktivas, la anonco eble ne alvenos, do la printilo malaperas el la listo eĉ se ĝia adreso ankoraŭ respondas. IPP sur 631, kruda presado sur 9100 kaj SMB sur 445 estas ordinaraj LAN-servoj tute sen tunela vojo.

Unue pruvu, ke la printilo estas atingebla

Antaŭ ol ŝanĝi ajnan politikon, konfirmu, ke la printilo sanas, kaj konfirmu la adreson, kiun vi pensas, ke ĝi havas. Legu la adreson de la printila panelo aŭ de ĝia propra retpaĝo. Malnova rikordo en la listo de la operaciumo povas montri al adreso, kiun DHCP donis al alia aparato antaŭ semajnoj.

Malkonektu la VPN, poste testu la adreson kaj la du kutimajn presajn pordojn:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

En Windows la ekvivalento estas Test-NetConnection 192.168.1.50 -Port 9100. Rekonektu la VPN kaj ripetu. Se la pordoj respondas kun la VPN malŝaltita kaj tempolimas kun ĝi ŝaltita, vi reproduktis la blokadon kaj la resto estas politika demando. Se ili malsukcesas en ambaŭ statoj, haltu: la printilo, la Wi-Fi-segmento aŭ klienta izolado kulpas, kaj VPN-escepto nur aldonus eksponiĝon.

Tri kondiĉoj, kiuj decidas permeson aŭ blokadon

Plenumu ilin laŭ ordo. La unua kondiĉo, kiu malsukcesas, decidas la rezulton, do la postaj ne bezonas testadon.

Gastaj retoj estas la plej klara ne. En hotelsegmento la loka gamo estas ĉiu alia gasto, do escepto, kiu atingas vian printilon, atingas ankaŭ iliajn tekkomputilojn. Printilo, kiu ne estas via, ne estas kialo malfermi tiun segmenton.

Administrataj aparatoj estas la dua ne. Kiam administranta profilo trudas ĉiam-aktivan VPN kun ŝloso, la kliento reasertas la blokadon post ĉiu loka ŝanĝo, kaj la provizora solvo povas malobservi la politikon, kiun vi akceptis. Petu subtenatan vojon al loka rimedo anstataŭ redakti agordojn, kiuj estos anstataŭigitaj.

La plej malgranda escepto, kiun via kliento subtenas

Vi volas cel-limigitan regulon por unu printila adreso, ne ĝeneralan lok-permesan ŝaltilon. Ĝenerala ŝaltilo kutime kovras la tutan privatan gamon kaj link-local trafikon, kio estas multe pli ol unu presvico bezonas, kaj ĝi igas ĉiun aparaton en la segmento kamarado, kiun vi akceptis.

Windows elmetas split tunnelling, kaj kelkaj buildoj ankaŭ elmetas lokretan opcion. Kie la sola subtenata vojo estas hosta rikordo, aldonu unu adreson tra la fizika pordego post kiam la tunelo staras, ekzemple route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, kaj forigu ĝin kiam la sesio finiĝas. WireGuard funkcias alie: AllowedIPs decidas, kio eniras la tunelon, do plentunela profilo 0.0.0.0/0 portas la preslaboron al la finpunkto krom se pli specifa vojo preteriras ĝin, kaj wg-quick povas instali fajroŝirmilajn regulojn, kiuj blokas ĉion alian.

En Android la ĉiam-aktiva agordo, kiu blokas konektojn sen la VPN, estas la kill switch, kaj printila malkovro el aplikaĵo ene de tiu blokado havas neniun LAN-vojon. La modelo per aplikaĵo kaj esceptoj estas dokumentita en la Android VPN-paĝo, kaj tie vi kontrolu antaŭ ol ŝanĝi ion ajn: Android VPN-konekteca gvidilo. Lastatempaj macOS-eldonoj petas lokretan permeson aparte de la tunelo, kaj iOS faras la samon por loka retaliro, tamen la vico povas ankoraŭ malsukcesi kun la tunelo staranta ĉar la kliento de la vendisto enkursigas la subreton en ĝin.

Kiun ajn klienton vi uzas, tenu la escepton je unu adreso kaj la du aŭ tri pordojn, kiujn la printilo efektive uzas. Rezervu DHCP-luon anstataŭ vastigi la regulon al la tuta subreto, ĉar la adreso povas moviĝi.

Kontrolu la escepton kaj sciu, kiam malfari ĝin

Post la ŝanĝo, rekonektu kaj kontrolu tri aferojn laŭ ordo. La printilo respondas sur siaj pordoj, sendanĝera provpaĝo presiĝas, kaj adresa serĉo ankoraŭ redonas la VPN-finpunkton anstataŭ vian ISP. Se presado funkcias sed la serĉo montras vian ISP, vi malfermis pli ol la printilon kaj devus malfari.

Ripetu la teston post restartigo kaj post ajna klienta aŭ profila ĝisdatigo, ĉar ĝisdatigoj sufiĉe ofte restarigas defaŭltojn por gravi. Escepto, kiu postvivas nur ĝis la sekva rekonekto, ne estas decido, ĝi estas provizora truo. Skribu la precizan regulon, por ke vi povu forigi ĝin intence.

Se la aparato estas destinita nur al tunelo, vojaĝa tekkomputilo aŭ maŝino kun klientaj datumoj, la ĝusta respondo estas teni la blokadon kaj presi aliloke: konservu kiel PDF kaj presu de telefono aŭ alia maŝino, aŭ atingi presservilon, kiun la tunelo povas enkursigi. Malŝalti la kill switch por unu laboro interŝanĝas realan protekton kontraŭ malgranda komforto.