Suebakia VPNa blokeatzen ari al da? Urratsez urratseko egiaztapena

VPN denbora-muga batek erabilgarria den erantzunik iritsi ez zela frogatzen du, eta ez du ezer frogatzen zergatiari buruz. Profilak portu okerra adieraz dezake, zerbitzaria itzalita egon daiteke, edo eskaera itzultze-bide erabilgarririk gabe irits daiteke. Horietako bakoitzak arrasto desberdina uzten du, eta arrastoak esaten dizu zein arau ukitu. Ibili beheko lau etapak hurrenez hurren. Gelditu horietako batek sintoma azaltzen duen unetan.

1. urratsa: berretsi zerbitzaria eta garraioa

Irakurri zerbitzariaren izena, garraioa eta portua operadorearen uneko profiletik, eta ez tokiko aldaketa batetik. Zure eramangailuan aldatutako portu batek ezin du entzulerik sortu zerbitzari publiko batean, eta desadostasun horrek blokeo baten berdinak diren denbora-muga sortzen du. Profilak onartutako garraio alternatiboa eskaintzen badu, erreserba gisa idatzi eta ez konponbide gisa. Ebatz ezazu izena eta alderatu erantzuna operadoreak argitaratutako helbidearekin.

DNS erregistro zaharkitu batek inoiz erantzun ez zuen ostalarira bidaltzen du bezeroa. Hori iragazki bat imitatzen duen beste hutsegite bat da, eta baztertzeak kontsulta bakarra kostatzen du.

Idatzi bi balioak tiketan. Geroagoko alderaketa guztiek erabiltzen dituzte, eta haiek gabe tiketak ikerketa berriro hasten du.

2. urratsa: frogatu bidea alderaketa kontrolatu batekin

Utzi gailua eta profila aldatu gabe eta saiatu konfiantzazko beste sarbide-sare bat. Tunela han altxatzen bada, aldea jatorrizko bidea edo haren politika da. Bigarren gailu onartu batek jatorrizko sarean funtzionatzen badu, aldea lehen gailua da. Bi alderaketa horietako bat ia beti da erabakigarria.

Osatu lehenago edozein sare-saio legitimo, captive atariak blokeoa dirudi amaitu arte.

Probatu benetan erabiltzen duzun portua, eta tratatu TCP emaitza TCPri buruzko informazio soil gisa.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

443 portuan TCP esku-emate arrakastatsu batek han entzule batek erantzun zuela esaten du. Ez du ezer esaten 51820 portuko UDP entzuleari buruz, ezta negoziazioa amaitu zen ere.

3. urratsa: irakurri segurtasun-gertaerak hutsegitearen unerako

Suebakiaren gertaerak eskuragarri dagoen frogarik sendoenak dira, eta aurrez aipatu beharreko ohar bat dakarte. Erregistroa desgaituta dago profil lehenetsi askotan, beraz egiaztatu dagokion profilak jaurtiketak erregistratzen dituen erregistro hutsa errugabetasun-froga gisa irakurri aurretik. Erregistroa aktibo dagoenean, gertaerak araua, norabidea eta helbideak adierazten ditu, eta hori da hain zuzen arau-aldaketa batek behar duena. Aplikazio-arauak eta portu-arauak objektu bereiziak dira, eta kudeatutako politikak tokiko ezarpena gaindi dezake. Berretsi zein bezerori eta zein zerbitzuri estaltzen dion arau batek benetan.

Bildu profilaren egoera eta azken gertaerak huts egin zuen makinatik, ez alboko ostalaritik.

Alderatu gertaeraren ordua zure proba-saiakeraren orduarekin, sinadura desberdineko arau-izen bat kasualitatea baita.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Kudeatzen duzun zerbitzari batean, galdetu eskaerak entzulera iritsi ote zen. Erantzunik gabe iristen den paketea birbidalketa edo itzultze-bide arazoa da. Inoiz agertzen ez den eskaera iragazketa edo helbideratze arazoa da.

4. urratsa: probatu birbidalketa tunela altxatu ondoren

Suebaki batek saioa onar dezake eta saioak iritsi nahi duen guztia ukatu. Birbidalketa-sysctl-ak, NAT arauak eta itzultze-bideak autentifikazioaren ondoren daude, eta VPN porturako salbuespen zabal batek ez du horietako bat ere konpontzen. Probatu barne-helmuga bat eta interneteko helmuga bat bereizita, normalean arrazoi desberdinengatik huts egiten baitute. Barne-izenek huts egiten badute baina helbideek funtzionatzen badute, begiratu bultzatutako DNSa edozein arau baino lehen.

Exekutatu beheko hiru egiaztapenak zerbitzarian, bezero bat konektatuta dagoela eta huts egiten duen eskaera egiten ari dela.

Tunelaren interfazeko kontagailuak dira gakoa, paketeak sartu ziren eta zerbaitek irten zuen erakusten baitute.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Paketeak tunelera iristen dira eta ezer ez da helmugarantz irteten denean, susmagarria birbidalketa edo NATa da. Ezer ez denean iristen, saioa altxatuta dago baina bezeroa ez da bidaltzen ari, eta begiratzeko lekua bezeroaren bide-tabla da.

Egiaztatu konponketa eta kendu lagundu ez zuena

Onartutako zuzenketa baten ondoren, errepikatu huts egin zuen proba zehatza eta erregistratu emaitza profil eta gailu beraren aurka. Gero kendu emaitza aldatu ez zuen aldi baterako salbuespen oro, erabili gabeko salbuespenak pilatu egiten baitira eta bakoitza inork gogoratzen ez duen erabaki bat da. Mantendu geratzen dena estua: helmuga bat, portu bat, norabide bat, arduradun bat.

Exekutatu berriro hiru komando berak eta alderatu aldaketaren aurretik gordetako irteerekin.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Konparazio-sareak funtzionatzen duenean, jatorrizko sareak huts egiten jarraitzen duenean eta gertaerak hutsik daudenean, gainerako susmagarria bidea da, ez ostalaria. Eman hori sarearen arduradunari baieztapen zehatz gisa, bi alderaketa-emaitzak erantsita. Hobe da horretan gelditzea suebaki-profila desgaituta uztea baino.