Retkomunigoj ne aperas sur VPN? Malkovro haltas

La komunigo malfermiĝas kiam vi tajpas ĝian vojon, kaj la reta foliumilo montras tute nenion. Tiu kombino oftas tra tunelo kaj kutime ne estas difekto. Malkovro demandas al la loka segmento; atingeblo demandas al unu gastiganto. Rutigita tunelo portas la duan kaj ne la unuan.

Malkovro kaj atingeblo estas apartaj

Foliumliston produktas protokoloj, kiuj anoncas servojn al loka segmento kaj aŭskultas tiujn anoncojn. Malfermi komunigon laŭ nomo estas rekta konekto al unu gastiganto. La unua bezonas dissendan aŭ multdissendan domajnon; la dua bezonas vojon kaj pordon.

Tra tunelo la dua povas funkcii perfekte dum la unua redonas malplenan fenestron. Se vi traktas la malplenan fenestron kiel la difekton, vi serĉos rompitan tunelon, kiu faras sian taskon.

Kial la foliumlisto restas malplena

Windows retiris la servon Computer Browser kaj malŝaltis SMB-version 1 defaŭlte, kio forigis la maŝinaron malantaŭ la malnova Network Neighborhood. Anstataŭaĵoj kiel WS-Discovery, SSDP kaj multdissenda DNS adresas dissendajn aŭ multdissendajn grupojn, kiuj ekzistas nur sur loka ligilo. Punkto-al-punkta tunelo ne havas tian ligilon, kaj enkursigiloj ne plusendas tiujn grupojn defaŭlte. Ĉiu gastiganto povas esti atingebla kaj la listo povas resti malplena.

Iuj programoj aldonas sian propran malkovran helpanton. Kiam tiu helpanto funkcias, ĝi estas trajto de la programo, ne eco de la tunelo.

Uzu eksplicitajn nomojn, poste konfirmu aliron

UNC-vojo, mapita disko aŭ Finder-konekto al SMB-adreso funkcias tra la tunelo post kiam la nomo solviĝas kaj la pordo estas malfermita. Solvo povas veni de DNS, de serĉa sufikso, kiun la VPN provizas, aŭ de centre administrata hosts-rikordo. En domajno, dosieruja demando povas listigi komputilajn objektojn, kaj tiu listo kutime estas la plej proksima anstataŭaĵo por foliuma vido en rutigita reto. Portoskanado de konataj prefiksoj estas akceptebla nur en retoj, kiujn vi administras aŭ por kiuj vi estas eksplicite rajtigita testi.

Gastiganto, kiu respondas, ne promesas, ke la komunigo malfermiĝos. NAS povas havi permesliston limigitan al sia propra subreto, kiu rifuzas adresojn de la VPN-baseno. Fajroŝirma regulo de dosier-servilo povas nomi nur la lokan subreton. La konto, kiun vi provizas por la komunigo, povas esti loka konto, kiu neniam estis kreita sur tiu servilo, kaj konektiĝi tra la VPN ne kreas ĝin.

Iuj kompaniaj programoj intence blokas lokan trafikon kaj trafikon de virtualaj maŝinoj dum la tunelo estas aktiva. Tiu mankanta aliro estas politiko, kaj la riparo apartenas al la administranto, ne al la enkursiga tabelo de la programo.

Diagnoza ordo inda je ripeto

Iru la tavolojn en ordo: atingi la adreson, solvi la nomon, malfermi pordon 445, aŭtentigi, poste legi la komunigajn permesojn. Ĉiu respondo estas aparta, kaj antaŭenirado produktas memfidan malĝustan konkludon. Nur post kiam ĉiuj pasas, malkovro indas je esploro.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Lasu noton kun la servila nomo, la komuniga vojo, la adreso al kiu ĝi solviĝis kaj la konto, kiu funkciis. Se la foliumlisto poste pleniĝos post relanĉo de servo, traktu tion kiel malkovran kapricon, ne kiel pruvon, ke la antaŭa vojo estis malĝusta. La noto estas tio, kio lasas la sekvan personon preterpasi la malplenan fenestron.