Biðlarinn þinn pingar netþjóninn, netþjónninn getur ekki pingað biðlarann, og göngin flytja greinilega pakka í báðum þessum fullyrðingum. Það sem er ólíkt er ekki leiðin heldur fyrsti pakkinn í hverri prófun: annar er svar við straumi sem Windows fylgist þegar með, hinn er ný innkomin beiðni sem engin regla hefur hleypt inn. Sá munur skýrir flestar skýrslur um einstefnu-ping og bendir beint á regluna sem þú þarft að skrifa. Tvær prófanir í gagnstæðum áttum aðskilja tilfellin á um einni mínútu.

Tvær áttir, tvær ólíkar ákvarðanir

Þegar biðlarinn sendir bergmálsbeiðnina sér Windows-eldveggurinn útleiðandi tengingu sem hann hefur ákveðið að leyfa. Svarið kemur til baka innan þessa þegar mynduðu straums, svo vélin sem fylgist með stöðu hleypir því inn án þess að spyrja nokkra innkomna reglu fyrir ICMP. Það er merking stöðutengdrar síunar í reynd, og reglan sem enginn skrifaði kemur ekki við sögu. Árangur biðlarans segir því ekkert um innkomna stefnu.

Þegar netþjónninn sendir beiðnina fyrst passar engin staða við hana. Windows meðhöndlar pakkann sem nýja innkomna tengingu og spyr innkomnu stefnuna, sem að sjálfgefnu gerir enga ráðstöfun fyrir bergmálsbeiðnir frá handahófskenndum uppsprettum.

Árangur biðlarans sannaði því að útleiðandi ICMP og endurkomuleiðin virki. Hann prófaði aldrei innkomnu ákvörðunina, og eðlileg ályktun, að eldveggurinn sé í lagi, er skynsamleg og röng. Þess vegna endurtekur mistökið sig í málum sem þegar innihalda sönnunina.

Fylgdu pakkanum þar til hann hverfur

Staðfestu vistföngin áður en þú breytir einhverju: notaðu það gönguvistfang sem biðlarinn hefur í raun, og athugaðu að netþjónninn beini þangað en ekki að LAN-vistfangi bak við biðlarann. Bæði mistökin líta eins út frá skipanalínu netþjónsins, því bæði enda í tímamörkum. Hvar pakkinn deyr er eina staðreyndin sem ræður því hvað á að breyta.

Ef beiðnin nær gönguviðmótinu og ekkert fer út er staðbundni eldveggurinn líklegasta orsökin. Ef hún nær aldrei viðmótinu er svarið ofar: leið á netþjóninum, útleiðandi stefna eða eigin afhending jafningja VPN-sambandsins.

Taktu upp á gönguviðmóti biðlarans meðan netþjónninn pingar. Að sjá beiðnina koma án svars við hliðina er sönnunin sem réttlætir að skrifa Windows-reglu. Að sjá alls ekkert sendir þig ofar, og regla sem bætt er við í því ástandi gerir vélina bara eftirlátari gagnvart pakka sem kom aldrei. Í báðum tilfellum kostar upptakan minna en ágiskunin sem hún kemur í staðinn fyrir.

Takmarkaðu eina reglu í stað þess að opna ICMP

Greindu millistykkið og núverandi flokk þess áður en þú skrifar eitthvað, því bæði birtast í því sviði sem þú ert að fara að setja. Það samnefni er heiti Windows-viðmótsins, sem er ekki endilega heiti VPN-sniðsins sem þú fluttir inn. Skipanirnar hér að neðan telja upp hvað er til og sýna síðan forskoðun á takmarkaðri reglu án þess að beita henni.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 tegund 8 er bergmálsbeiðnin, eina skeytið sem netþjónninn þarf að fá svar við. Takmarkaðu hana við gönguvistfang netþjónsins og við gönguviðmótið, og látu sniðið vera eins og millistykkið er í raun. Að endurnefna net svo það passi við dæmi er sérstök breyting með eigin afleiðingum.

Hvað reglan nær ekki yfir

Bergmál IPv6 er önnur samskiptaregla með aðra skeytategund, svo ICMPv4-regla segir ekkert um hana, og göng sem flytja báðar fjölskyldur þurfa sína eigin reglu fyrir hina. Þessi regla opnar ekkert annað heldur: RDP, skráardeiling og hver önnur þjónusta er enn háð eigin stefnu. Þetta er allur tilgangurinn með að takmarka eina þrönga reglu í stað þess að virkja breitt ICMP-leyfi. Breiða leyfið er auðvelda lagfæringin og sú sem varir lengst, því enginn tekur eftir henni á eftir.

Á stýrðu tæki getur reglan verið skipt út við næstu stefnuuppfærslu, svo eigandi stefnunnar verður að gera samsvarandi breytingu en ekki staðbundinn stjórnandi. Skrifaðu ætlunina í málið ásamt skipuninni, því uppfærsla mun eyða skipuninni og láta kröfuna ósnerta. Þetta tvennt er ekki sama gervið, og aðeins annað þeirra lifir af.

Lestu niðurstöðuna í réttri átt

Eftir að reglan gildir skaltu pinga frá netþjóninum og staðfesta að svar nái til biðlarans, pingaðu síðan frá uppsprettu sem á enn að vera útilokuð og staðfestu að það nái ekki. Endurtaktu aðgengisprófið á hinni vistfangafjölskyldunni ef göngin flytja hana.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Að prenta regluna sem tók gildi er nytsamlegra en að treysta skipuninni sem bjó hana til, því forskoðun og beitt regla eru ólík ástand. Ef vistfangasían sýnir uppsprettuna sem þú ætlaðir og útilokuða uppsprettan endar enn í tímamörkum, gerir reglan nákvæmlega það sem svið hennar segir. Árangursríkt ping frá biðlaranum hefði aldrei sýnt það, og þess vegna á stefna hverrar prófunar heima í skránni við hlið niðurstöðunnar. Haltu báðum áttum í málinu, annars endurtekur næsti lesandi prófunina sem getur ekki mistekist.

Tengdir greinar