Blokkolja a tűzfal a VPN-t? Szakaszos ellenőrzés

Egyetlen VPN-időtúllépés azt bizonyítja, hogy nem érkezett használható válasz, és semmit sem bizonyít az okról. A profil rossz portot nevezhet meg, a kiszolgáló állhat, vagy a kérés működő visszaút nélkül érkezhet. Mindegyik más nyomot hagy, és a nyom mondja meg, melyik szabályhoz kell nyúlni. Járja végig az alábbi négy szakaszt sorrendben. Álljon meg, amint valamelyik megmagyarázza a tünetet.

1. szakasz: erősítse meg a kiszolgálót és az átvitelt

A kiszolgáló nevét, az átvitelt és a portot az üzemeltető aktuális profiljából olvassa ki, ne egy helyi módosításból. A laptopon átírt port nem hozhat létre figyelőt egy nyilvános kiszolgálón, és ez az eltérés a blokkolással azonos időtúllépést ad. Ha a profil támogatott alternatív átvitelt kínál, jegyezze fel tartalékként, nem megoldásként. Oldja fel a nevet, és hasonlítsa össze a választ az üzemeltető által közzétett címmel.

Az elavult DNS-rekord olyan gazdagéphez küldi a klienst, amely soha nem válaszolt. Ez egy újabb hiba, amely szűrőt utánoz, és egyetlen lekérdezésbe kerül kizárni.

Írja mindkét értéket a jegybe. Minden későbbi összehasonlítás ezeket használja, és a nélkülük lévő jegy újraindítja a vizsgálatot.

2. szakasz: bizonyítsa az útvonalat egyetlen ellenőrzött összehasonlítással

Hagyja változatlanul az eszközt és a profilt, és próbáljon ki egy másik megbízható hozzáférési hálózatot. Ha ott feljön az alagút, a különbség az eredeti útvonal vagy annak házirendje. Ha az eredeti hálózaton egy második engedélyezett eszköz működik, a különbség az első eszköz. A két összehasonlítás egyike szinte mindig döntő.

Előbb fejezze be a jogszerű hálózati bejelentkezést, mert a captive portál blokkolásnak látszik, amíg be nem fejeződik.

Azt a portot tesztelje, amelyet ténylegesen használ, és a TCP-eredményt csak TCP-re vonatkozó információként kezelje.

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

Egy sikeres TCP-kézfogás a 443-as porton azt jelenti, hogy ott egy figyelő válaszolt. Semmit sem mond az 51820-as UDP-figyelőről, és arról sem, hogy befejeződött-e az egyeztetés.

3. szakasz: olvassa ki a biztonsági eseményeket a hiba pillanatára

A tűzfal-események a legerősebb rendelkezésre álló bizonyítékok, és van egy fenntartásuk, amelyet érdemes előre kimondani. Sok alapértelmezett profilban a naplózás ki van kapcsolva, ezért ellenőrizze, naplózza-e az érintett profil az eldobásokat, mielőtt üres naplót olvasna ártatlanság bizonyítékaként. Ha a naplózás be van kapcsolva, az esemény megnevezi a szabályt, az irányt és a címeket, ami pontosan az, amire egy szabálymódosításnak szüksége van. Az alkalmazásszabályok és a portszabályok külön objektumok, és a felügyelt házirend felülírhat egy helyi beállítást. Erősítse meg, melyik klienst és melyik szolgáltatást fedi le valójában egy szabály.

A profil állapotát és a legutóbbi eseményeket a meghibásodott gépről gyűjtse, ne egy szomszédos gazdagépről.

Vesse össze az esemény idejét a tesztkísérlet idejével, mert az egyező szabálynév eltérő időbélyeggel véletlen egybeesés.

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

Egy általa felügyelt kiszolgálón kérdezze meg, egyáltalán elérte-e a kérés a figyelőt. A válasz nélkül érkező csomag továbbítási vagy visszaútvonal-probléma. A soha meg nem jelenő kérés szűrési vagy címzési probléma.

4. szakasz: tesztelje a továbbítást az alagút feljövetele után

A tűzfal engedélyezheti a munkamenetet, és mégis megtagadhat mindent, amit a munkamenet el akar érni. A továbbítási sysctl-ek, a NAT-szabályok és a visszaútvonalak mind a hitelesítés után vannak, és a VPN-port széles mentessége egyiket sem javítja. Teszteljen külön egy belső célt és egy internetes célt, mert általában eltérő okokból hibáznak. Ha a belső nevek hibáznak, de a címek működnek, nézze meg a tolt DNS-t bármely szabály előtt.

Futtassa az alábbi három ellenőrzést a kiszolgálón, miközben egy kliens csatlakozva van, és a hibás kérést próbálja.

Az alagút interfészén lévő számlálók a lényeg, mert megmutatják, bejöttek-e a csomagok, és kiment-e valami.

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

Ha csomagok érkeznek az alagútra, és semmi nem megy ki a cél felé, a gyanúsított a továbbítás vagy a NAT. Ha semmi nem érkezik, a munkamenet áll, de a kliens nem küld, és a hely, ahol nézni kell, a kliens útvonaltáblája.

Ellenőrizze a javítást, és távolítsa el, ami nem segített

Egy jóváhagyott javítás után ismételje meg pontosan azt a tesztet, amely hibázott, és rögzítse az eredményt ugyanazon profil és eszköz mellett. Ezután távolítson el minden ideiglenes kivételt, amely nem változtatta meg az eredményt, mert a használatlan kivételek felhalmozódnak, és mindegyik olyan döntés, amelyre senki sem emlékszik. Tartsa szűken, ami marad: egy cél, egy port, egy irány, egy felelős.

Futtassa újra ugyanazt a három parancsot, és hasonlítsa össze a módosítás előtt mentett kimenetekkel.

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

Ha az összehasonlító hálózat működik, az eredeti hálózat továbbra is hibázik, és az események üresek maradnak, a fennmaradó gyanúsított az útvonal, nem a gazdagép. Adja át ezt a hálózat tulajdonosának konkrét állításként, mindkét összehasonlítási eredménnyel. Ez jobb megállási pont, mint egy letiltott tűzfalprofil.