Mae rhwydwaith IPv6 yn unig yn torri’r VPN cyn i’r tiwnel ddechrau

Mae’r gliniadur yn ymuno â Wi-Fi cynhadledd sy’n dosbarthu IPv6 yn unig, mae’r cleient VPN yn troi ac yn methu, ac roedd yr un proffil wedi gweithio mewn gwesty awr ynghynt. Nid oes dim wedi newid yn y manylion mewngofnodi. Yr hyn sydd wedi newid yw bod yn rhaid i’r cleient nawr gyrraedd cyrchfan IPv4 trwy rwydwaith sy’n cario IPv6 yn unig, ac nid yw pob cleient yn gwybod sut i wneud hynny.

Cerddwch yr un pum cam ag y mae’r pecynnau’n eu cerdded.

Cam 1: gwyliwch y chwiliad enw

Os yw’r proffil yn defnyddio enw gwesteiwr, y cwestiwn cyntaf yw beth mae’r datryswr yn ei ddychwelyd. Mae dig AAAA vpn.example.com ar y rhwydwaith IPv6 yn unig yn dychwelyd cofnod AAAA go iawn, un wedi’i syntheseiddio o DNS64, neu ddim byd o gwbl. Mae ateb wedi’i syntheseiddio yn amgodi’r gyrchfan IPv4 y tu mewn i ragddodiad cyfieithu, a dim ond wedyn y gall cleient heb gyrchfan IPv6 gyrraedd yno. Nid yw proffil â chyfeiriad IPv4 wedi’i galedu byth yn cyrraedd mor bell, oherwydd nid oes enw i’w syntheseiddio.

Mae’r un gwahaniaeth hwnnw’n esbonio’r rhan fwyaf o adroddiadau ‘yn gweithio fan acw, yn methu fan hyn’, ac mae un gorchymyn yn ddigon i’w weld.

Cam 2: gwelwch pa deulu y galwodd y cleient arno

Gwyliwch y soced yn hytrach na’r bar cynnydd. Nid oes gan gleient sy’n agor soced IPv4 i gyfeiriad IPv4 ar gyswllt IPv6 yn unig unrhyw le i’w anfon, ac mae’r methiant yn amlygu fel goramser yn hytrach na gwall enw. Mae ss -tanp tra mae’r cleient yn cysylltu yn dangos y cyfeiriad pell a’r teulu a geisiodd. Cymharwch hynny â ip -6 route i gadarnhau bod y llwybr diofyn yn naid nesaf IPv6 go iawn.

Y teulu cyfeiriadau yn nhabl y socedi yw’r ffaith. Mae’r bar cynnydd yn grynodeb a ysgrifennwyd gan rywun arall.

Cam 3: gwahanwch y cyfieithu oddi wrth y tiwnel

NAT64 a DNS64 yw sut mae’r rhwydwaith mynediad yn cyrraedd cyrchfannau IPv4, ac nid ydynt yn gwneud dim i’r tiwnel ar ôl iddo godi. Mae tiwnel a sefydlwyd dros lwybr cyfieithiedig yn dal i negodi ei gyfeirio mewnol ei hun, ac mae’r sylw IPv4 neu IPv6 mewnol yn gwestiwn polisi ar wahân. Os yw’r cleient yn cysylltu ac yna’n methu cyrraedd unrhyw beth, rydych chi wedi mynd heibio’r cyfieithu ac wedi dod i’r llwybro, sef ymchwiliad gwahanol gyda thystiolaeth wahanol.

Mae methiant cyfieithu yn edrych fel peidio â chysylltu byth. Mae methiant sylw mewnol yn edrych fel cysylltu a pheidio â chyrraedd unrhyw beth.

Cam 4: profwch yr un proffil ar rwydwaith arall

Ewch â’r un proffil, fersiwn cleient a manylion mewngofnodi i rwydwaith deu-stac a’i ailadrodd. Os yw’n gweithio yno ac yn methu ar y llwybr IPv6 yn unig, y newidyn yw’r rhwydwaith mynediad yn hytrach na’r proffil. Cofnodwch fersiwn y cleient a chyflwr y rhwydwaith yn y tocyn, oherwydd yr atgyweiriad terfynol yw diweddariad cleient neu gyrchfan wahanol.

Mae adroddiad sy’n dweud bod y VPN wedi torri yn un na ellir gweithredu arno. Mae adroddiad sy’n dweud mai dim ond ar fynediad IPv6 yn unig y mae’n methu yn adroddiad nam.

Cam 5: trwsiwch y llwybr, nid y gosodiadau diogelwch

Mae’r atgyweiriadau temtasiwn i gyd yn gwneud pethau’n waeth. Mae analluogi IPv6 yn dileu’r unig lwybr y mae’r rhwydwaith yn ei gynnig. Mae pwyntio’r cleient at ddatryswr cyhoeddus yn torri syntheseiddiad DNS64, oherwydd rhaid i’r syntheseiddiad hwnnw ddod o’r datryswr y tu ôl i’r cyfieithydd. Mae diffodd dilysu tystysgrifau yn rhoi cysylltiad i chi â rhywbeth na allwch ei adnabod. Nid yw’r un o’r rheini’n atgyweiriad, ac mae dau ohonynt yn regresiwnau diogelwch a fydd yn goroesi’r digwyddiad.

Y gwir opsiynau yw cleient sy’n cefnogi’r model cyfieithu rhwydwaith, neu gyrchfan â chyfeiriad IPv6 y gellir ei chyrraedd. Gofynnwch am un o’r rheini.