Vai ugunsmūris bloķē VPN? Pārbaude soli pa solim

Viens VPN taimauts pierāda, ka nav saņemta lietojama atbilde, un neko nepierāda par iemeslu. Profils var norādīt nepareizu portu, serveris var būt izslēgts, vai pieprasījums var ierasties bez strādājoša atgriešanās ceļa. Katrs no tiem atstāj citu pēdu, un tieši pēda pasaka, kuram noteikumam pieskarties. Izstaigājiet četrus zemāk minētos posmus secībā. Apstājieties, tiklīdz kāds no tiem izskaidro simptomu.

1. posms: apstipriniet serveri un transportu

Lasiet servera nosaukumu, transportu un portu no operatora pašreizējā profila, nevis no lokāla labojuma. Ports, kas mainīts jūsu klēpjdatorā, nevar izveidot klausītāju publiskā serverī, un šī neatbilstība rada taimautu, kas ir identisks bloķēšanai. Ja profils piedāvā atbalstītu alternatīvu transportu, atzīmējiet to kā rezerves variantu, nevis kā risinājumu. Atrisiniet nosaukumu un salīdziniet atbildi ar adresi, ko operators publicējis.

Novecojis DNS ieraksts nosūta klientu uz resursdatoru, kas nekad nav atbildējis. Tas ir vēl viens defekts, kas atdarina filtru, un tā izslēgšana maksā vienu vaicājumu.

Ierakstiet abas vērtības biļetē. Katrs vēlākais salīdzinājums tās izmanto, un biļete bez tām sāk izmeklēšanu no jauna.

2. posms: pierādiet ceļu ar vienu kontrolētu salīdzinājumu

Atstājiet ierīci un profilu nemainītus un izmēģiniet citu uzticamu piekļuves tīklu. Ja tur tuneļa savienojums paceļas, atšķirība ir sākotnējais ceļš vai tā politika. Ja sākotnējā tīklā darbojas otra apstiprināta ierīce, atšķirība ir pirmā ierīce. Viens no šiem diviem salīdzinājumiem gandrīz vienmēr ir izšķirošs.

Vispirms pabeidziet jebkuru likumīgu tīkla pieteikšanos, jo gūsta portāls izskatās kā bloķēšana, līdz tas ir pabeigts.

Pārbaudiet portu, kuru faktiski lietojat, un TCP rezultātu uztveriet kā informāciju tikai par TCP.

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

Veiksmīga TCP rokasspiediena 443 portā nozīmē, ka tur atbildēja klausītājs. Tas neko nesaka par UDP klausītāju 51820 portā un par to, vai sarunas ir pabeigtas.

3. posms: izlasiet drošības notikumus par atteices brīdi

Ugunsmūra notikumi ir spēcīgākie pieejamie pierādījumi, un tiem ir piezīme, ko ir vērts pateikt vispirms. Daudzos noklusējuma profilos reģistrēšana ir izslēgta, tāpēc pārbaudiet, vai attiecīgais profils reģistrē nomešanas, pirms lasāt tukšu žurnālu kā nevainības pierādījumu. Kad reģistrēšana ir ieslēgta, notikums nosauc noteikumu, virzienu un adreses, un tas ir tieši tas, kas nepieciešams noteikuma maiņai. Lietotņu noteikumi un portu noteikumi ir atsevišķi objekti, un pārvaldīta politika var pārspēt lokālu iestatījumu. Apstipriniet, kuru klientu un kuru pakalpojumu noteikums patiešām aptver.

Apkopojiet profila stāvokli un jaunākos notikumus no mašīnas, kas cieta neveiksmi, nevis no blakus resursdatora.

Salīdziniet notikuma laiku ar sava testa mēģinājuma laiku, jo sakrītošs noteikuma nosaukums ar citu laika zīmogu ir nejaušība.

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

Serverī, kuru pārvaldāt, pajautājiet, vai pieprasījums vispār sasniedza klausītāju. Pakešu, kas ierodas bez atbildes, ir pārsūtīšanas vai atgriešanās maršruta problēma. Pieprasījums, kas nekad neparādās, ir filtrēšanas vai adresēšanas problēma.

4. posms: pārbaudiet pārsūtīšanu pēc tam, kad tunelis ir pacēlies

Ugunsmūris var atļaut sesiju un tomēr liegt visu, ko sesija vēlas sasniegt. Pārsūtīšanas sysctl, NAT noteikumi un atgriešanās maršruti visi atrodas pēc autentifikācijas, un plašs izņēmums VPN portam nesalabo nevienu no tiem. Atsevišķi pārbaudiet vienu iekšējo galamērķi un vienu interneta galamērķi, jo tie parasti neizdodas dažādu iemeslu dēļ. Ja iekšējie nosaukumi neizdodas, bet adreses darbojas, pirms jebkura noteikuma apskatiet piespiesto DNS.

Izpildiet trīs zemāk minētās pārbaudes serverī, kamēr klients ir pievienots un mēģina neveiksmīgo pieprasījumu.

Tuneļa saskarnes skaitītāji ir galvenais, jo tie parāda, vai paketes iegāja un vai kaut kas izgāja.

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

Kad paketes ierodas tunelī un nekas neiziet galamērķa virzienā, aizdomās turamais ir pārsūtīšana vai NAT. Kad nekas neierodas, sesija ir pacelta, bet klients nesūta, un vieta, kur skatīties, ir klienta maršrutu tabula.

Pārbaudiet labojumu un noņemiet to, kas nepalīdzēja

Pēc apstiprināta labojuma atkārtojiet tieši to testu, kas neizdevās, un ierakstiet rezultātu pret to pašu profilu un ierīci. Pēc tam noņemiet jebkuru pagaidu izņēmumu, kas nemainīja rezultātu, jo neizmantoti izņēmumi uzkrājas un katrs ir lēmums, ko neviens neatceras. Saglabājiet atlikušo šauru: viens galamērķis, viens ports, viens virziens, viens atbildīgais.

Palaidiet tās pašas trīs komandas vēlreiz un salīdziniet tās ar izvadēm, ko saglabājāt pirms izmaiņas.

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

Kad salīdzināšanas tīkls darbojas, sākotnējais tīkls joprojām neizdodas un notikumi paliek tukši, atlikušais aizdomās turamais ir ceļš, nevis resursdators. Nododiet to tīkla īpašniekam kā konkrētu apgalvojumu, pievienojot abus salīdzināšanas rezultātus. Tā ir labāka vieta, kur apstāties, nekā atspējots ugunsmūra profils.