Windows-houer UNC-toegang: eers die naam, dan die identiteit

’n Windows-houer wat ’n deel op die ander kant van jou tonnel nodig het, faal op twee onafhanklike maniere, en die gasheer se Verkenner bewys nie een daarvan nie. Die houer het sy eie netwerk-eindpunt en sy eie prosesidentiteit. ’n Naam wat op die lessenaar opgelos word en ’n sessie wat die lêerbediener daar aanvaar, beskryf die lessenaar, nie die werklading nie.

Die gasheer se Verkenner is nie bewyse nie

Om die deel op die gasheer oop te maak, gebruik die gasheer se DNS-kliënt, die gasheer se roetetabel en die gasheer se aangemelde rekening. ’n Houerproses erf niks daarvan outomaties nie, selfs wanneer die houer op dieselfde masjien loop en die VPN-kliënt ook daar loop. Die eerste grens is die netwerkpad: kan die houer die naam oplos, en kan dit ’n TCP-sessie na die SMB-poort oopmaak. Die tweede is identiteit: aanvaar die lêerbediener wat die houer aanbied, met die regte wat die werklading nodig het.

Om hulle as een probleem te behandel, lewer die bekende lus op waarin firewallreëls verbreed word om iets reg te maak wat eintlik ’n toegang-geweier-antwoord van die deel is.

Volg die houer se eie versoek

Windows-houernetwerking word deur die Host Networking Service bestuur, wat eindpunte met hul eie netwerknaamruimte skep. Die modus wat jy gekies het, bepaal of die eindpunt vertaal, oorbrug of aan ’n netwerk gekoppel word wat met die gasheer gedeel word. Daardie besluit verander twee dinge gelyktydig: wat die houer kan oplos, en watter bronadres die lêerbediener sien.

Bevestig wat die houer self sien voordat jy enigiets verander. ’n Naam wat buite oplos, kan binne faal, want die houer se DNS-opstelling is nie dié van die gasheer nie, en ’n vertaalde eindpunt kan ’n bron aanbied wat die lêerbediener se reëls nie verwag nie.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

As resolusie faal, maak DNS in die netwerkopstelling reg eerder as om ’n adres te vervang. Om die naam met ’n IP te vervang, kan verifikasie en bedieneridentiteit se gedrag verander, wat een probleem in twee verander. Die VPN-kliënt se eie beleid is die volgende ding om na te kyk, want dit kan gasheerprosesse en verkeer wat deur die houer ontstaan anders behandel.

Identiteit is ’n aparte besluit

’n Skyfletter wat deur ’n interaktiewe gebruiker gekoppel is, is nie ’n toepassingkoppelvlak nie. Dit bestaan in een aanmeldingsessie, en ’n houerproses is nie deel daarvan nie. Gebruik die UNC-pad en gee die werklading ’n identiteit wat die ontplooiingsmodel ondersteun. Waar die domein dit ondersteun, verskaf ’n groepbestuurde diensrekening (gMSA) ’n bestuurde identiteit deur ’n spesifikasie van geloofsbriewe.

Microsoft se gids vir houer-gMSA beskryf daardie reëling met die geloofsbriewe-spesifikasie en die voorwaardes daarvan, wat domeinlidmaatskap insluit en ’n gasheer wat die geloofsbriewe kan verkry. Die rekening, die verkryging, die prosesidentiteit binne die houer en die deel se regte moet almal in lyn wees. ’n VPN-aanmelding is nie daardie identiteit nie, en om ’n wagwoord in ’n beeld in te bak om die gasheergebruiker se sessie te herproduseer, skep ’n blywende blootstelling.

Hou die falende stadium sigbaar

’n Resolusiefout, ’n verbindingweiering en ’n toegangweiering het verskillende bewyse nodig. Dit is onderskeidelik ’n DNS-vraag, ’n roeterings- of filtervraag, en ’n verifikasie- of regtevraag. Lees die antwoord wat die houer ontvang het, eerder as die toepassing se algemene fout.

Toets met die werklading se eie identiteit en toets ook ’n weiering.

Beplan vir die herverbinding

VPN-paaie val weg. Wanneer die tonnel terugkom, kan ’n eindpunt met ’n ander vertaalde adres terugkom, en ’n bestaande SMB-sessie kan dood wees sonder dat die toepassing dit agterkom. Hanteer dit in die toepassing: herstel die pad en die identiteit, probeer die bewerking weer, en versoen ’n lêerbewerking met ’n onbekende uitkoms in plaas daarvan om aan te neem niks het gebeur nie.

Teken die netwerkmodus, die DNS-bron en die identiteitsreëling in die ontplooiingsnotas aan. Daardie drie feite is waaroor die volgende fout sal gaan.