Ping-ak norabide bakarrean funtzionatzen du: zergatik botatzen duen Windowsek zerbitzariaren oihartzuna

Zure bezeroak zerbitzariari ping egiten dio, zerbitzariak ezin dio bezeroari ping egin, eta tunelak argi eta garbi garraiatzen ditu paketeak bi esaldi horietan. Aldentzen dena ez da bidea, proba bakoitzaren lehen paketea baizik: bat Windowsek jada jarraitzen duen fluxu bati emandako erantzuna da, bestea inongo arauk onartu gabeko sarrerako eskaera berria. Alde horrek norabide bakarreko ping txosten gehienak azaltzen ditu eta idatzi behar duzun araura zuzenean seinalatzen du. Kontrako norabideetan egindako bi probak minutu inguruan bereizten dituzte kasuak.

Bi norabide, bi erabaki desberdin

Bezeroak oihartzun eskaera bidaltzen duenean, Windowseko suebakiak baimena eman duen irteerako konexio bat ikusten du. Erantzuna ezarritako fluxu horren barruan itzultzen da, beraz egoera jarraitzen duen motorrak onartzen du, ICMPrako sarrerako inolako arauri galdetu gabe. Hori da egoeran oinarritutako iragazketak praktikan esan nahi duena, eta inork idatzi ez zuen araua ez dago horretan sartuta. Beraz, bezeroaren arrakastak ez du ezer esaten sarrerako politikari buruz.

Zerbitzariak eskaera lehenengo bidaltzen duenean, inolako egoerak ez dio bat egiten. Windowsek paketea sarrerako konexio berri gisa hartzen du eta sarrerako politikari galdetzen dio, eta horrek, lehenespenez, ez du ezer aurreikusten jatorri arbitrarioko oihartzun eskaeretarako.

Beraz, bezeroaren arrakastak frogatu zuen irteerako ICMPak eta itzulera bideak funtzionatzen dutela. Sarrerako erabakia ez zuen inoiz probatu, eta ondorio naturala, suebakia ondo dagoela, zentzuzkoa eta okerra da. Horregatik errepikatzen da akatsa froga jada baduten tiketetan.

Jarraitu paketeari desagertu arte

Berretsi helbideak ezer aldatu aurretik: erabili bezeroak benetan duen tunel helbidea, eta egiaztatu zerbitzariak horretara bideratzen duela eta ez bezeroaren atzeko LAN helbide batera. Bi huts egiteek berdinak dirudite zerbitzariaren gonbitetik, biak denbora-mugak dira eta. Paketea non hiltzen den da zer aldatu erabakitzen duen gertaera bakarra.

Eskaerak tunel interfazera iristen bada eta ezer ez bada irteten, tokiko suebakia da arrazoi litekeena. Interfazera inoiz iristen ez bada, erantzuna gorago dago: zerbitzariko bide bat, irteerako politika bat edo VPNaren beraren parekoen arteko entrega.

Hartu kaptura bezeroaren tunel interfazean zerbitzariak ping egiten duen bitartean. Eskaera erantzunik gabe iristen ikustea da Windows arau bat idaztea justifikatzen duen froga. Ezer ez ikusteak gorago bidaltzen zaitu, eta egoera horretan gehitutako arauak makina soilik toleranteago egiten du inoiz iritsi ez zen pakete batentzat. Edonola ere, kapturak txikiagoa du ordezkatzen duen usteak baino.

Mugatu arau bat ICMP ireki beharrean

Identifikatu egokigailua eta haren egungo kategoria ezer idatzi aurretik, biak ezartzeko zoazen esparruan agertzen baitira. Ezizen hori Windows interfazearen izena da, eta ez da nahitaez inportatu duzun VPN profilaren izena. Beheko komanduek existitzen dena zerrendatzen dute, eta gero arau mugatu bat aurrez ikusten dute, aplikatu gabe.

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 8 mota oihartzun eskaera da, zerbitzariak erantzuna behar duen mezu bakarra. Mugatu zerbitzariaren tunel helbidera eta tunel interfazera, eta utzi profila egokigailua benetan den bezala. Sarea adibide batera egokitzeko berrizendatzea berezko ondorioak dituen aldaketa aparta da.

Arauak estaltzen ez duena

IPv6ren oihartzuna mezu mota desberdineko protokolo desberdina da, beraz ICMPv4 arau batek ez du ezer esaten hari buruz, eta bi familiak daramatzan tunelak bestearentzako bere araua behar du. Arau honek ez du beste ezer irekitzen: RDPk, fitxategi partekatzeak eta gainerako zerbitzu guztiek beren politikaren mende jarraitzen dute. Hori da arau estu bat mugatzearen eta ICMP baimen zabal bat gaitzearen arteko zentzu osoa. Baimen zabala konponbide erraza da eta denbora gehien irauten duena, inork geroago nabaritzen ez duelako.

Kudeatutako gailu batean araua hurrengo politika eguneratzean ordezkatu daiteke, beraz politikaren jabeak egin behar du aldaketa baliokidea, eta ez tokiko administratzaile batek. Idatzi asmoa tiketan komanduarekin batera, eguneratzeak komandua ezabatuko baitu eta baldintza osorik utziko. Biak ez dira artefaktu bera, eta horietako bat baino ez da bizirik ateratzen.

Irakurri emaitza norabide egokian

Araua aplikatu ondoren, egin ping zerbitzaritik eta berretsi erantzun bat bezeroarenera iristen dela, gero egin ping kanpoan geratu behar duen iturri batetik eta berretsi ez dela iristen. Errepikatu irisgarritasun proba beste helbide familian, tunelak bat badarama.

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

Indarrean sartu den araua inprimatzea sortu zuen komanduan konfiatzea baino erabilgarriagoa da, aurrebista eta aplikatutako araua egoera desberdinak baitira. Helbide iragazkiak nahi zenuen iturria erakusten badu eta baztertutako iturriak denbora-muga gainditzen badu oraindik, arauak zehazki bere esparruak dioena egiten du. Bezerotik abiatutako ping arrakastatsu batek ez zuen inoiz hori erakutsiko, eta horregatik proba bakoitzaren norabidea bere emaitzaren ondoan dagoen erregistroan dagokio. Gorde bi norabideak tiketan, bestela hurrengo irakurleak huts ezin duen proba errepikatuko du.