Pam mae kill switch yn gollwng traffig pan fyddwch yn newid gweinydd
Pam mae kill switch yn blocio traffig yn ystod newid gweinydd, beth mae'r cleient yn ei wneud yn y ffenestr honno, a sut i wahaniaethu bwlch arferol oddi wrth floc sydd wedi glynu.
Rydych chi'n dewis gweinydd sy'n edrych yn agosach, yn pwyso cysylltu, ac mae'r porwr yn stopio llwytho cyn i'r twnnel newydd godi. Mae'r eicon yn troi i gyflwr cysylltu ac yn aros yno tra bo pob tab yn amseru allan. Mae'r saib hwnnw fel arfer yn kill switch yn gweithio fel y'i cynlluniwyd: mae traffig yn cael ei flocio tra nad oes gan y cleient dwnnel i'w anfon drwyddo. A yw'r saib yn dderbyniol yn dibynnu ar yr hyn mae'r cleient yn ei wneud yn y eiliadau hynny, ac ar a yw'r bloc yn cael ei godi pan fydd yn dweud ei fod.
Beth mae'r cleient yn ei wneud rhwng dau weinydd
Mae newid pwynt terfyn yn sawl cam, nid un togl. Mae'r cleient yn dymchwel y twnnel presennol, yn diweddaru ei reolau blocio, yn datrys ac yn cyrraedd y pwynt terfyn newydd y tu allan i'r twnnel, yna'n gosod y llwybrau newydd ac yn codi'r bloc. Mae'r bwlch rydych chi'n ei deimlo rhwng y cam cyntaf a'r olaf.
Mae trefn yn bwysicach na chyflymder yma. Os yw'r rheolau blocio'n mynd i mewn cyn yr eithriad ar gyfer y pwynt terfyn newydd, ni all y cleient gwblhau'r gydlawithiad ac mae'n aros yn cysylltu tan amserlen. Os yw'r eithriad yn gopi o gyfeiriad yr hen weinydd, mae'r gydlawithiad newydd yn edrych fel unrhyw becyn allanol arall ac yn cael ei ollwng. Mae'r ddau achos yn edrych yr un fath o'r porwr, a dyna pam y gall newid sy'n gwella ar ôl chwe eiliad a'r un na wella byth rannu un achos.
Mae angen twll yn y bloc ar y pwynt terfyn newydd
I adeiladu'r twnnel, rhaid i'r cleient anfon pecynnau i gyfeiriad a phorth y gweinydd newydd ar y rhyngwyneb ffisegol, er enghraifft UDP 51820 ar gyfer proffil WireGuard nodweddiadol neu 1194 a 443 ar gyfer OpenVPN, beth bynnag mae eich proffil eich hun yn ei nodi. Nid yw'r traffig hwnnw y tu mewn i'r twnnel y mae ar fin ei greu, felly mae bloc ar gyfer y ddyfais gyfan yn ei lyncu oni bai bod rheol ganiatáu sy'n cyfateb.
Mae proffiliau sy'n seiliedig ar enw gwesteiwr yn ychwanegu ail ofyniad: y chwiliad ei hun. Os yw'r cleient yn datrys y pwynt terfyn cyn i'r bloc godi, gall ddefnyddio cyfeiriad cadw yn y storfa, ond unwaith y bydd y proffil yn cylchdroi cyfeiriadau neu'r cofnod cadw yn mynd yn hen, mae'r gydlawithiad yn anelu at gyfeiriad nad yw'r rheol ganiatáu yn ei gynnwys. Mae IPv6 yn gwneud hyn yn weladwy, oherwydd gall pwynt terfyn deu-stac gyhoeddi cofnod A a choffnod AAAA, ac mae rheol ganiatáu sy'n cynnwys cyfeiriad v4 yn unig yn gadael y cleient yn ceisio eto yn erbyn cyfeiriad v6 sydd wedi'i flocio.
Mae enwau opsiynau a gwerthoedd diofyn yn amrywio yn ôl cleient a fersiwn, felly darllenwch y rhestr ddogfennedig ar gyfer eich un chi yn lle dyfalu o sgrinluniau. Mae cyfeirlyfr gosodiadau OpenVPN Connect ar openvpn.net/connect-docs/app-settings-windows yn un enghraifft o sut mae cleient yn disgrifio ei opsiynau blocio a thwnnel hollt.
Mae fail-closed yn beiriant cyflwr, nid yn togl
Mae'r rhan fwyaf o gleientiaid yn mynegi'r bloc fel polisi mur tân mewn tri chyflwr: twnnel i fyny, gyda thraffig yn mynd drwy'r twnnel a dim bloc; twnnel i lawr, gyda'r bloc yn weithredol; a throsglwyddo, gyda'r bloc yn weithredol ynghyd ag eithriadau dros dro ar gyfer y pwynt terfyn. Yn y trydydd cyflwr mae'r bygiau'n byw, oherwydd rhaid iddo newid ddwywaith o fewn ychydig eiliadau, ac mae methu â gadael yn edrych yn union fel bloc parhaol.
Mae'r mecanwaith yn amrywio yn ôl platfform, ac felly mae'r methiant. Mae hidlwyr Windows Filtering Platform yn cario pwysau, felly mae hidlydd bloc sy'n trechu eich caniatâd yn parhau i ollwng pecynnau er bod y caniatâd yn bodoli, ac mae hidlwyr a adawyd gan broses cleient a laddwyd yn gallu cadw'r peiriant all-lein ar ôl i'r ap fynd. Mae cleientiaid macOS fel arfer yn ysgrifennu rheolau pf i anchor, lle mae trefn rheolau a phenderfyniadau cyflym yn penderfynu pa reol sy'n berthnasol. Mae cleientiaid Linux fel arfer yn rheoli cadwyn nftables neu iptables gyda pholisi drop a chaniatadau penodol ar gyfer y pwynt terfyn, rhyngwyneb y twnnel a loopback. VPN bob-amser Android gyda'r opsiwn i flocio cysylltiadau heb VPN yw'r mwyaf llym o'r grŵp, oherwydd mae'r OS yn cymhwyso'r bloc i'r ddyfais gyfan yn hytrach nag i bob ap.
Mae WireGuard angen nodyn ei hun, oherwydd mae AllowedIPs yn ddewisydd llwybro, nid yn flociwr. Mae'n penderfynu pa gyrchfannau sy'n mynd i'r twnnel; nid yw'n gwneud dim i atal pecyn heb dwnnel rhag gadael dros Wi-Fi. Mewn setup WireGuard yn unig heb reol mur tân, y kill switch mewn gwirionedd yw absenoldeb llwybr, a gall pecyn go iawn adael dros y rhyngwyneb ffisegol ar ôl gydlawithiad a ollyngwyd.
Mesurwch y bwlch yn lle gwylio'r eicon
Gwyliwch becynnau, nid y golau statws. Ar Linux, cychwynnwch ping araf at gyfeiriad cyhoeddus mewn un terfynell a chipio porth cludo'r twnnel ar y rhyngwyneb ffisegol mewn un arall:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Newidiwch weinyddwyr yn y cleient tra bo'r ddau yn rhedeg. Mae tri pheth yn bwysig: pa mor hir mae'r pings yn stopio, a yw'r cipiad yn dangos y gydlawithiad yn cyrraedd y pwynt terfyn newydd, ac a yw traffig yn ailafael cyn neu ar ôl i gyflwr y cleient newid i gysylltiedig. Os yw bwlch y ping yn gorffen gyntaf, naill ai mae'r bloc wedi'i godi'n gynnar neu mae'r twnnel i fyny cyn i'r dangosydd gyfaddef hynny. Os yw'r bwlch yn gorffen yn hwyrach, mae'r dangosydd yn obeithiol.
Ar Windows, mae netsh wfp show state yn ysgrifennu ciplun y gallwch chwilio ynddo am hidlwyr bloc sy'n dal i fodoli tra bo'r cleient yn honni ei fod wedi datgysylltu. Ar macOS, mae sudo pfctl -sr yn rhestru'r rheolau a lwythwyd a'u trefn. Parwch naill ai ciplun â log y cleient ei hun; mae'r llinell amser o'ch ping yn dweud a yw'r bloc wedi gorffen yn hwyr neu erioed wedi gorffen.
Pylu arferol yn erbyn bloc sydd wedi glynu
Mae rhywfaint o ymyrraeth yn bwynt y nodwedd, felly triagwch cyn i chi newid unrhyw osodiad:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Os byddwch yn glanio yn yr ail neu'r pumed rhes, peidiwch â diffodd y kill switch i brofi, oherwydd mae hynny'n troi nam llwybro yn ollyngiad. Ailgychwynnwch wasanaeth y cleient, neu ailgychwynnwch y peiriant lle mae hidlwyr yn goroesi lladd proses, yna gwelwch a yw'r bloc yn clirio. Os ydyw, y nam yw'r glanhau yn ystod y newid yn hytrach na'r bloc ei hun.
Cyn eich newid nesaf, cadarnhewch bedwar peth: mae caniatâd y pwynt terfyn yn cynnwys pob teulu cyfeiriadau y mae eich proffil yn ei ddatrys, mae log y cleient yn dangos y trosglwyddiad wedi'i gwblhau, mae eich prawf ping yn mesur y bwlch yn hytrach na'r eicon, ac mae cau'r cleient yn adfer cysylltedd arferol. Mae kill switch sy'n dal yn ystod y newid ac yn rhyddhau wedyn yn gwneud ei waith. Mae un sy'n rhyddhau'n gynnar, neu byth, yn werth dadfygio.