Ping toimii vain yhteen suuntaan: miksi Windows pudottaa palvelimen kaiun

Asiakkaasi pingaa palvelinta, palvelin ei voi pingata asiakasta, ja tunneli selvästi kuljettaa paketteja molemmissa noista väitteistä. Ero ei ole reitissä vaan kunkin testin ensimmäisessä paketissa: toinen on vastaus virtaan, jota Windows jo seuraa, toinen on uusi saapuva pyyntö, jota mikään sääntö ei ole päästänyt läpi. Tämä ero selittää useimmat yksisuuntaista pingiä koskevat raportit ja osoittaa suoraan sääntöön, joka sinun on kirjoitettava. Kaksi vastakkaisiin suuntiin tehtyä testiä erottaa tapaukset noin minuutissa.

Kaksi suuntaa, kaksi eri päätöstä

Kun asiakas lähettää kaikupyynnön, Windowsin palomuuri näkee lähtevän yhteyden, jonka se on päättänyt sallia. Vastaus palaa tämän jo muodostetun virran sisällä, joten tilaa seuraava moottori päästää sen läpi kysymättä mitään saapuvaa ICMP-sääntöä. Tätä tilallinen suodatus tarkoittaa käytännössä, eikä sääntöä, jota kukaan ei kirjoittanut, ole tässä mukana. Asiakkaan onnistuminen ei siis kerro mitään saapuvan liikenteen käytännöstä.

Kun palvelin lähettää pyynnön ensin, mikään tila ei vastaa sitä. Windows kohtelee pakettia uutena saapuvana yhteytenä ja kysyy saapuvan liikenteen käytännöltä, joka ei oletuksena varaa mitään mielivaltaisista lähteistä tuleville kaikupyynnöille.

Asiakkaan onnistuminen siis osoitti, että lähtevä ICMP ja paluureitti toimivat. Se ei koskaan koetellut saapuvaa päätöstä, ja luonnollinen johtopäätös, että palomuuri on kunnossa, on järkevä ja väärä. Siksi virhe toistuu tiketeissä, joissa todiste on jo mukana.

Seuraa pakettia, kunnes se katoaa

Vahvista osoitteet ennen kuin muutat mitään: käytä tunneliosoitetta, joka asiakkaalla todella on, ja tarkista, että palvelin reitittää siihen eikä asiakkaan takana olevaan LAN-osoitteeseen. Molemmat viat näyttävät samoilta palvelimen komentokehotteessa, koska molemmat päättyvät aikakatkaisuun. Missä paketti kuolee, on ainoa tosiasia, joka ratkaisee, mitä muutetaan.

Jos pyyntö saavuttaa tunneliliitännän eikä mitään lähde, paikallinen palomuuri on todennäköinen syy. Jos se ei koskaan saavuta liitäntää, vastaus on ylempänä: palvelimen reitti, lähtevän liikenteen käytäntö tai VPN:n oma vertaisten välinen toimitus.

Kaappaa asiakkaan tunneliliitännällä, kun palvelin pingaa. Pyynnön saapuminen ilman vieressä olevaa vastausta on todiste, joka oikeuttaa Windows-säännön kirjoittamisen. Tyhjä näkymä lähettää sinut ylemmäs, ja siinä tilassa lisätty sääntö tekee koneesta vain sallivamman paketille, joka ei koskaan saapunut. Kummassakin tapauksessa kaappaus maksaa vähemmän kuin arvailu, jonka se korvaa.

Rajaa yksi sääntö sen sijaan että avaat ICMP:n

Tunnista sovitin ja sen nykyinen luokka ennen kuin kirjoitat mitään, koska molemmat esiintyvät laajuudessa, jonka aiot asettaa. Tuo alias on Windowsin liitännän nimi, joka ei välttämättä ole tuodun VPN-profiilin nimi. Alla olevat komennot listaavat, mitä on olemassa, ja esikatselevat sitten rajatun säännön sitä soveltamatta.

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 tyyppi 8 on kaikupyyntö, ainoa viesti, johon palvelimen on saatava vastaus. Rajaa se palvelimen tunneliosoitteeseen ja tunneliliitäntään, ja jätä profiili sellaiseksi kuin sovitin todella on. Verkon uudelleennimeäminen esimerkkiin sopivaksi on erillinen muutos, jolla on omat seurauksensa.

Mitä sääntö ei kata

IPv6:n kaiku on toinen protokolla ja toinen viestityyppi, joten ICMPv4-sääntö ei kerro siitä mitään, ja molempia perheitä kuljettava tunneli tarvitsee oman sääntönsä toiselle. Tämä sääntö ei avaa mitään muutakaan: RDP, tiedostojen jakaminen ja kaikki muut palvelut riippuvat edelleen omasta käytännöstään. Juuri tässä on koko pointti rajailla yksi kapea sääntö sen sijaan että ottaisi käyttöön laajan ICMP-sallinnan. Laaja sallinta on helppo korjaus ja se, joka säilyy pisimpään, koska kukaan ei huomaa sitä jälkeenpäin.

Hallitulla laitteella sääntö voidaan korvata seuraavassa käytännön päivityksessä, joten vastaavan muutoksen on tehtävä käytännön omistaja eikä paikallinen ylläpitäjä. Kirjoita aikomus tikettiin komennon lisäksi, koska päivitys pyyhkii komennon ja jättää vaatimuksen ennalleen. Ne eivät ole sama artefakti, ja vain toinen niistä säilyy.

Lue tulos oikeassa suunnassa

Kun sääntö on voimassa, pingaa palvelimelta ja vahvista, että vastaus tavoittaa asiakkaan, pingaa sitten lähteestä, jonka pitäisi yhä olla ulkopuolella, ja vahvista, ettei se tavoita. Toista tavoitettavuustesti toisella osoiteperheellä, jos tunneli kuljettaa sitä.

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

Voimaan tulleen säännön tulostaminen on hyödyllisempää kuin sen luoneeseen komentoon luottaminen, koska esikatselu ja sovellettu sääntö ovat eri tiloja. Jos osoitesuodatin näyttää aiottua lähdettä ja ulkopuolelle jätetty lähde yhä aikakatkeaa, sääntö tekee täsmälleen sen, mitä sen laajuus sanoo. Asiakkaasta aloitettu onnistunut ping ei olisi koskaan näyttänyt sitä, ja siksi kunkin testin suunta kuuluu kirjaukseen tuloksensa viereen. Pidä molemmat suunnat tikissä, tai seuraava lukija toistaa testin, joka ei voi epäonnistua.