Ĉu la fajroŝirmilo blokas la VPN? Kontrolo paŝo post paŝo

Unu VPN-tempolimo pruvas, ke neniu uzebla respondo alvenis, kaj pruvas nenion pri la kialo. La profilo povas nomi la malĝustan pordon, la servilo povas esti malŝaltita, aŭ la peto povas alveni sen funkcianta revena vojo. Ĉiu el tiuj lasas alian spuron, kaj la spuro estas tio, kio diras al vi, kiun regulon tuŝi. Trapasu la kvar stadiojn sube laŭ ordo. Haltu tuj kiam unu el ili klarigas la simptomon.

Paŝo 1: konfirmu la servilon kaj la transporton

Legu la servilan nomon, la transporton kaj la pordon el la nuna profilo de la funkciiganto, ne el loka ŝanĝo. Pordo ŝanĝita sur via tekkomputilo ne povas krei aŭskultanton sur publika servilo, kaj tiu malkongruo produktas tempolimon identan al blokado. Se la profilo proponas subtenatan alternativan transporton, notu ĝin kiel rezervan eblon, ne kiel solvon. Solvu la nomon kaj komparu la respondon kun la adreso, kiun la funkciiganto publikigis.

Malnova DNS-rikordo sendas la klienton al gastiganto, kiu neniam respondis. Tio estas alia paneo, kiu imitas filtrilon, kaj ĝi kostas unu demandon por ekskludi.

Skribu ambaŭ valorojn en la bileton. Ĉiu pli posta komparo uzas ilin, kaj bileto sen ili rekomencas la esploron.

Paŝo 2: pruvu la vojon per unu kontrolita komparo

Lasu la aparaton kaj la profilon senŝanĝaj kaj provu alian fidindan alirreton. Se la tunelo leviĝas tie, la diferenco estas la origina vojo aŭ ĝia politiko. Se dua aprobita aparato funkcias sur la origina reto, la diferenco estas la unua aparato. Unu el tiuj du komparoj preskaŭ ĉiam estas decidiga.

Unue finu ĉiun legitiman retan ensaluton, ĉar kaptita portalo aspektas kiel blokado ĝis ĝi finiĝos.

Testu la pordon, kiun vi efektive uzas, kaj traktu TCP-rezulton kiel informon nur pri TCP.

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

Sukcesa TCP-manpremo sur pordo 443 diras, ke aŭskultanto respondis tie. Ĝi diras nenion pri UDP-aŭskultanto sur 51820, nek pri tio, ĉu la intertraktado finiĝis.

Paŝo 3: legu la sekurecajn eventojn por la momento de malsukceso

Fajroŝirmilaj eventoj estas la plej forta disponebla pruvo, kaj ili portas kaŭcion, kiun indas diri unue. Protokolado estas malŝaltita en multaj defaŭltaj profiloj, do kontrolu, ĉu la koncerna profilo registras forĵetojn, antaŭ ol legi malplenan protokolon kiel pruvon de senkulpeco. Kiam protokolado estas ŝaltita, la evento nomas la regulon, la direkton kaj la adresojn, kio estas ĝuste tio, kion ŝanĝo de regulo bezonas. Aplikaj reguloj kaj pordaj reguloj estas apartaj objektoj, kaj administrata politiko povas superregi lokan agordon. Konfirmu, kiun klienton kaj kiun servon regulo efektive kovras.

Kolektu la profilstaton kaj la lastajn eventojn el la maŝino, kiu malsukcesis, ne el najbara gastiganto.

Komparu la eventan horon kun la horo de via testprovo, ĉar kongrua regula nomo kun malsama tempindiko estas hazardo.

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

Sur servilo, kiun vi administras, demandu, ĉu la peto entute atingis la aŭskultanton. Alvenanta paketo sen respondo estas problemo de plusendado aŭ de revena vojo. Peto, kiu neniam aperas, estas problemo de filtrado aŭ de adresado.

Paŝo 4: testu plusendadon post kiam la tunelo leviĝis

Fajroŝirmilo povas permesi la seancon kaj tamen rifuzi ĉion, kion la seanco volas atingi. Plusendaj sysctl, NAT-reguloj kaj revenaj vojoj ĉiuj staras post aŭtentikigo, kaj vasta escepto por la VPN-pordo riparas neniun el ili. Testu unu internan celon kaj unu interretan celon aparte, ĉar ili kutime malsukcesas pro malsamaj kialoj. Se internaj nomoj malsukcesas sed adresoj funkcias, rigardu la puŝitan DNS antaŭ iu ajn regulo.

Rulu la tri kontrolojn sube sur la servilo dum kliento estas konektita kaj provas la malsukcesantan peton.

La nombriloj sur la tunela interfaco estas la punkto, ĉar ili montras, ĉu paketoj eniris kaj ĉu io eliris.

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

Kiam paketoj alvenas sur la tunelon kaj nenio eliras al la celo, la suspektato estas plusendado aŭ NAT. Kiam nenio alvenas, la seanco estas levita sed la kliento ne sendas, kaj la loko por rigardi estas la enkursiga tabelo de la kliento.

Kontrolu la ripeton kaj forigu tion, kio ne helpis

Post aprobita korekto, ripetu precize la teston, kiu malsukcesis, kaj registru la rezulton kontraŭ la sama profilo kaj aparato. Poste forigu ĉiun provizoran escepton, kiu ne ŝanĝis la rezulton, ĉar neuzitaj esceptoj amasiĝas kaj ĉiu estas decido, kiun neniu memoras. Tenu la restaĵon mallarĝa: unu celo, unu pordo, unu direkto, unu posedanto.

Rerulu la samajn tri komandojn kaj komparu ilin kun la eligoj, kiujn vi konservis antaŭ la ŝanĝo.

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

Kiam la kompara reto funkcias, la origina reto ankoraŭ malsukcesas kaj la eventoj restas malplenaj, la restanta suspektato estas la vojo, ne la gastiganto. Transdonu tion al la retposedanto kiel konkretan aserton, kun ambaŭ komparaj rezultoj aligitaj. Tiu estas pli bona loko por halti ol malŝaltita fajroŝirmila profilo.