Mae’r switsh diogelwch yn dal i rwystro traffig ar ôl i’r VPN ddatgysylltu

Mae’r twnnel wedi mynd, mae’r eicon rhwydwaith yn edrych yn normal, ac nid oes dim yn llwytho. Fe wnaethoch ddatgysylltu’r VPN, neu ei ddadosod, neu ailgychwyn, ac mae’r bloc a oedd i’ch amddiffyn yn ystod cwymp yn dal i sefyll. Ni all ffenestr y cleient esbonio hyn, oherwydd nid y cleient sy’n eich rhwystro: ysgrifennwyd y penderfyniad i’r cnewyllyn yn eich enw, ac ni adawyd dim ar ôl i’w dynnu. Ar Windows mae’r cyflwr hwnnw’n byw yn Llwyfan Hidlo Windows; ar Linux mae’n set o reolau yn iptables neu nftables, yn aml gyda chipolwg a ailchwyrir wrth gychwyn. Dyma’r drefn a ddefnyddiaf: darllen y cyflwr, dileu’r eitem gulaf sy’n esbonio’r methiant, yna darganfod beth bynnag sy’n ei roi yn ôl.

Cyflwr cnewyllyn yw switsh diogelwch, nid gosodiad

Mae cleientiaid bwrdd gwaith yn gweithredu rhwystro drwy ychwanegu hidlyddion sy’n gwrthod traffig y tu allan i’r twnnel. Ar Windows mae’r rheini’n hidlyddion WFP ar haenau ailgyfeirio cysylltiad a chludiant, ac mae rhai ohonynt yn barhaol: cânt eu cofnodi ym mhorthfa polisi Base Filtering Engine ac fe’u hadferir pan fydd y peiriant yn cychwyn, cyn i unrhyw feddalwedd VPN redeg. Mae cleientiaid yn wahanol o ran pa bryd y maent yn glanhau. Mae rhai’n tynnu hidlyddion wrth ddatgysylltu, eraill dim ond ar allanfa lân, ac eraill dim ond pan ddiffoddir y switsh diogelwch yn gyntaf. Dadosodwch tra bo’r bloc yn weithredol, neu lladdwch y broses, ac mae’r hidlyddion yn aros.

Y cyfateb ar Linux yw rheol gollwng neu wrthod yn y llwybr allbwn, weithiau rheol anfon ymlaen, weithiau polisi cadwyn a newidiwyd. Mae’r rheolau hynny’n goroesi’r broses a’u hychwanegodd oherwydd eu bod yn gyflwr cnewyllyn: lladdwch y cleient, gwnewch iddo chwalu, neu dorrwch y pŵer, ac mae’r cnewyllyn yn parhau i ollwng pecynnau heb ddim ar ôl i’w dad-wneud. Mae pecyn parhad yn ychwanegu ail haen o barhad drwy gymryd ciplun o’r set reolau gyfredol a’i adfer wrth gychwyn, felly mae’r cychwyn nesaf yn dechrau gyda’r bloc eisoes wedi’i osod.

Darllenwch gyflwr WFP cyn dileu unrhyw beth

Mae Windows yn dod â’r offer y mae ei angen arnoch. Rhedwch brydlun wedi’i ddyrchafu a dympwch gyflwr y llwyfan; mae’r dymp yn glanio fel wfpstate.xml yn y cyfeiriadur gwaith.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Chwiliwch yn yr XML am enw’r gwerthwr a adawodd, am weithred Block, ac am yr haen. Hidlyddion ar ailgyfeirio cysylltiad a chludiant yw’r rhai sy’n torri traffig cyffredin; nid yw hidlydd ar haen derbyn yn aml yn eich achos chi. Os nad yw Base Filtering Engine yn rhedeg o gwbl, edrychwch yn rhywle arall, oherwydd ni all dim arall orfodi’r hidlyddion hynny.

Gwiriwch olwg arferol y mur gwarchod hefyd, gan mai dim ond un o’r ddau y mae’r rhan fwyaf o bobl yn ei archwilio:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Pan fydd y proffiliau adeiledig ymlaen ac nad oes unrhyw reol yn cyfateb i’r traffig sy’n methu, mae’r bloc yn dod o ddarparwr trydydd parti yn hytrach nag o wal dân Windows. Y gwahaniaeth hwnnw sy’n penderfynu pa offeryn a ddefnyddiwch ar gyfer yr atgyweiriad.

Darllenwch reolau Linux yn y gystrawen y byddwch yn dileu â hi

Mae iptables -S yn argraffu rheolau yn yr un ffurf a ddefnyddir i’w hychwanegu, sy’n gwneud yr allbwn yn union y gellir ei ailddefnyddio ar gyfer dileu. Mae iptables -L -v -n yn ychwanegu cyfrifwyr pecynnau, ac mae’r cyfrifwyr hynny’n dweud wrthych a yw rheol yn cyfateb i’ch ceisiadau sy’n methu ai peidio, neu’n syml yn eistedd yn y gadwyn.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Darllenwch bolisïau’r cadwyni, nid y rheolau’n unig: mae -P OUTPUT DROP yn blocio traffig hyd yn oed pan nad oes unrhyw reol yn cyfateb. Archwiliwch IPv6 ar wahân, oherwydd gall cleient sy’n gosod y ddau deulu adael y bloc IPv6 yn ei le ar ôl i reolau IPv4 ddiflanu, ac yna mae’r symptom yn dibynnu ar ba deulu y mae rhaglen yn ei ffafrio. Lle defnyddir nftables, rhedwch nft list ruleset hefyd; mae’r ddau offeryn yn cyd-fyw drwy haen gydnaws, ac nid yw un rhestriad o reidrwydd yn dangos pob rheol a all ollwng pecyn.

Dilëwch yr eitem gulaf sy’n esbonio’r methiant

Ar Windows mae’r cam cyntaf o hyd yn llwybr tynnu’r gwerthwr ei hun: ailredwch y gosodwr a defnyddiwch atgyweirio neu ddadosod, neu rhedwch yr offeryn glanhau os yw’r gwerthwr yn cyhoeddi un. Mae gwasanaethau a thasgau wedi’u hamserlennu dros ben yn gyffredin, ac mae tasg sy’n cychwyn y cleient wrth fewngofnodi yn ailosod ei hidlyddion yn y cychwyn nesaf. Ystyr dadosod sy’n methu wrth ddarllen allwedd gofrestr y cleient fel arfer yw bod gwasanaeth neu dasg yn dal i’w ddal, nid bod y gofrestr wedi’i llygru.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Hidlyddion parhaol yw’r dewis olaf. Maent yn byw o dan HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, un gwerth i bob hidlydd wedi’i allweddu gan GUID. Allforiwch yr allwedd yn gyntaf, cofnodwch y GUIDau a dynnwch, dilewch yn unig y gwerthoedd sy’n perthyn i’r cleient a adawodd, yna ailgychwynnwch fel bod yr injan yn ailadeiladu ei chyflwr. Peidiwch â dileu’r allwedd gyfan a pheidiwch ag analluogi Base Filtering Engine: mae wal dân Windows a Defender yn dibynnu arno, a byddech yn cyfnewid un methiant am un gwaeth.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Ar Linux, cymerwch y llinell a argreffir gan iptables -S a disodli -A ag -D. Mae dileu’r un rheol a nodwyd gennych yn well na fflysio cadwyn, oherwydd mae’n gadael eich polisi eich hun yn gyfan.

sudo iptables -D OUTPUT -p udp -j REJECT

Os yw’r gollwng yn byw mewn cadwyn a ddiffinnir gan y defnyddiwr, dilëwch y naid i’r gadwyn honno’n gyntaf a thynnwch y gadwyn ag -X wedyn. Nid yw gosod polisi cadwyn i ACCEPT tra bo rheolau gollwng yn dal yn bresennol ond yn helpu pecynnau sy’n cyrraedd y penderfyniad polisi o gwbl. Mae fflysio pob tabl yn ddewis olaf: mae hefyd yn tynnu rheolau a ychwanegwyd gennych am resymau eraill, a chydag ufw ymlaen mae’n gadael y gwasanaeth yn credu ei fod yn berchen ar gadwyni nad ydynt yn bodoli mwyach.

Darganfyddwch y perchennog sy’n ei roi yn ôl

Ar ôl yr atgyweiriad ar unwaith, chwiliwch am unrhyw beth a fyddai’n adfer y cyflwr. Ar Linux, gwiriwch a yw uned parhad yn cael ei galluogi, a oes gan y cleient osodiad adfer mur gwarchod wrth fewngofnodi, ac a oes ffeil reolau wedi’i chadw o dan /etc. Ar Windows, gwiriwch gofnodion cychwyn, gwasanaethau a thasgau wedi’u hamserlennu eto, yna ailgychwynnwch ac ail-ddarllenwch y cyflwr gyda’r un gorchmynion ag o’r blaen.

Os daw’r bloc yn ôl, nid y dileu oedd y cywiriad; y perchennog oedd. Cofnodwch pa gleient neu wasanaeth sy’n ei osod a diffoddwch y nodwedd yno, yn lle ymladd ag ef ar haen y mur gwarchod ar ôl pob datgysylltiad.

Gwiriwch â thraffig go iawn, nid un ping

Profwch brawf enw, cysylltiad TCP a sesiwn porwr newydd, yna ailgychwynnwch ac ailadroddwch yr un tri gwiriad. Mae ping sy’n gweithio tra bo HTTPS yn methu yn pwyntio at hidlydd haen cludiant yn hytrach nag at y rhwydwaith, ac mae bloc sy’n ailymddangos dim ond ar ôl yr ailgychwyn yn pwyntio at berchennog nad ydych wedi’i ddarganfod eto.

Cadwch y dystiolaeth: yr allwedd BFE a allforiwyd, neu allbwn iptables -S a gafwyd cyn y newid. Cyn ei alw’n gywiredig, cadarnhewch yr haen y gwnaethoch dynnu’r eitem ohoni, y perchennog a allai ei ailosod, y cyflwr ar ôl un ailgychwyn glân, a bod pori cyffredin yn gweithio heb unrhyw broses VPN yn rhedeg. Mae tudalen lawlyfr iptables(8) yn cynnwys yr union gystrawen dileu a pholisi os ydych yn sgriptio’r glanhau.