Ping darbojas tikai vienā virzienā: kāpēc Windows izmet servera atbalsi

Jūsu klients pingē serveri, serveris nevar pingēt klientu, un tunelis abos šajos apgalvojumos acīmredzami pārvieto paketes. Atšķiras nevis ceļš, bet katra testa pirmā pakete: viena ir atbilde uz plūsmu, kuru Windows jau izseko, otra ir jauns ienākošs pieprasījums, kuru nav ielaidis neviens noteikums. Šī atšķirība izskaidro lielāko daļu ziņojumu par vienvirziena ping un tieši norāda uz noteikumu, kas jums jāraksta. Divi testi pretējos virzienos atdala gadījumus aptuveni minūtes laikā.

Divi virzieni, divi dažādi lēmumi

Kad klients nosūta atbalss pieprasījumu, Windows ugunsmūris redz izejošu savienojumu, kuru tas ir nolēmis atļaut. Atbilde atgriežas šīs jau nodibinātās plūsmas ietvaros, tāpēc stāvokli izsekojošais mehānisms to ielaiž, neprasot neviens ienākošais ICMP noteikums. Tā praktiski izpaužas stāvokļbalstītā filtrēšana, un noteikums, kuru neviens neuzrakstīja, šeit nepiedalās. Tāpēc klienta panākumi neko neizsaka par ienākošo politiku.

Kad serveris pieprasījumu nosūta pirmais, tam neatbilst neviens stāvoklis. Windows uzskata pakešu par jaunu ienākošu savienojumu un jautā ienākošajai politikai, kas pēc noklusējuma neko neparedz atbalss pieprasījumiem no patvaļīgiem avotiem.

Tātad klienta panākumi pierādīja, ka izejošais ICMP un atgriešanās ceļš darbojas. Tas nekad nepārbaudīja ienākošo lēmumu, un dabiskais secinājums, ka ugunsmūris ir kārtībā, ir saprātīgs un nepareizs. Tāpēc šī kļūda atkārtojas pieteikumos, kuros jau ir pierādījums.

Izsekojiet pakešu līdz tas pazūd

Pirms kaut ko mainīt, apstipriniet adreses: izmantojiet tuneļa adresi, kas klientam tiešām ir, un pārbaudiet, vai serveris maršrutē tieši uz to, nevis uz LAN adresi aiz klienta. Abas kļūmes no servera komandrindas izskatās vienādi, jo abas beidzas ar taimautu. Tas, kur pakete mirst, ir vienīgais fakts, kas nosaka, ko mainīt.

Ja pieprasījums sasniedz tuneļa saskarni un nekas neiziet, iespējamais iemesls ir vietējais ugunsmūris. Ja tas saskarni nekad nesasniedz, atbilde ir augstāk: maršruts serverī, izejošā politika vai paša VPN savstarpējā piegāde starp vienaudžiem.

Ierakstiet klienta tuneļa saskarnē, kamēr serveris pingē. Redzēt pieprasījumu ienākam bez atbildes blakus ir pierādījums, kas attaisno Windows noteikuma rakstīšanu. Neredzēt neko aizved augstāk, un šajā stāvoklī pievienots noteikums tikai padara mašīnu pieļāvīgāku pret paketi, kas nekad nav ieradusies. Jebkurā gadījumā ierakstīšana izmaksā mazāk nekā minējumi, ko tā aizstāj.

Ierobežojiet vienu noteikumu, nevis atveriet ICMP

Pirms kaut ko rakstīt, nosakiet adapteri un tā pašreizējo kategoriju, jo abi parādās tvērumā, kuru tūlīt iestatīsiet. Šis aizstājvārds ir Windows saskarnes nosaukums, kas ne vienmēr ir importētā VPN profila nosaukums. Tālāk dotās komandas uzskaita, kas pastāv, un pēc tam parāda ierobežota noteikuma priekšskatījumu, to nepiemērojot.

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 tips 8 ir atbalss pieprasījums, vienīgā ziņa, uz kuru serverim vajadzīga atbilde. Ierobežojiet to ar servera tuneļa adresi un tuneļa saskarni, un atstājiet profilu tādu, kāds adapteris tiešām ir. Tīkla pārdēvēšana, lai tas atbilstu piemēram, ir atsevišķa izmaiņa ar savām sekām.

Ko noteikums neaptver

IPv6 atbalss ir cits protokols ar citu ziņas tipu, tāpēc ICMPv4 noteikums par to neko neizsaka, un tunelim, kas pārvieto abas saimes, vajadzīgs savs noteikums otrai. Šis noteikums arī neko citu neatver: RDP, failu koplietošana un visi citi pakalpojumi joprojām ir atkarīgi no savas politikas. Tā ir visa jēga ierobežot vienu šauru noteikumu, nevis iespējot plašu ICMP atļauju. Plašā atļauja ir vieglais labojums un tas, kas saglabājas visilgāk, jo pēc tam neviens to nepamana.

Pārvaldītā ierīcē noteikums var tikt aizstāts nākamajā politikas atjauninājumā, tāpēc līdzvērtīga izmaiņa jāveic politikas īpašniekam, nevis vietējam administratoram. Ierakstiet nodomu biļetenā kopā ar komandu, jo atjauninājums izdzēsīs komandu un atstās prasību nemainīgu. Tie nav viens un tas pats artefakts, un izdzīvo tikai viens no tiem.

Lasiet rezultātu pareizajā virzienā

Kad noteikums stājas spēkā, pingējiet no servera un apstipriniet, ka atbilde sasniedz klientu, pēc tam pingējiet no avota, kuram vēl jāpaliek izslēgtam, un apstipriniet, ka tas nesasniedz. Atkārtojiet sasniedzamības testu otrā adrešu saimē, ja tunelis to pārvieto.

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

Izdrukāt noteikumu, kas stājās spēkā, ir lietderīgāk nekā uzticēties komandai, kas to izveidoja, jo priekšskatījums un piemērots noteikums ir dažādi stāvokļi. Ja adrešu filtrs rāda paredzēto avotu un izslēgtais avots joprojām beidzas ar taimautu, noteikums dara tieši to, ko saka tā tvērums. Veiksmīgs ping no klienta to nekad nebūtu parādījis, tāpēc katra testa virziens pieder ierakstam blakus tā rezultātam. Turiet abus virzienus pieteikumā, citādi nākamais lasītājs atkārtos testu, kas nevar neizdoties.