’n Netwerk slegs met IPv6 breek die VPN voordat die tonnel begin

Die skootrekenaar sluit by ’n konferensie-Wi-Fi aan wat net IPv6 uitdeel, die VPN-kliënt draai en misluk, en dieselfde profiel het ’n uur vroeër in ’n hotel gewerk. Niks aan die geloofsbriewe het verander nie. Wat verander het, is dat die kliënt nou ’n bestemming IPv4 moet bereik deur ’n netwerk wat net IPv6 dra, en nie elke kliënt weet hoe om dit te doen nie.

Stap deur dieselfde vyf stappe wat die pakkies stap.

Stap 1: kyk na die naamopsoek

As die profiel ’n gasheernaam gebruik, is die eerste vraag wat die resolver teruggee. dig AAAA vpn.example.com op die netwerk slegs met IPv6 gee ’n egte AAAA-rekord, ’n gesintetiseerde een van DNS64, of heeltemal niks. ’n Gesintetiseerde antwoord kodeer die bestemming IPv4 binne ’n vertalingsvoorvoegsel, en eers dan kan ’n kliënt sonder ’n eindpunt IPv6 dit bereik. ’n Profiel met ’n hardgekodeerde adres IPv4 kom nooit so ver nie, want daar is geen naam om te sintetiseer nie.

Daardie enkele verskil verduidelik die meeste verslae van werk-daar-misluk-hier, en dit neem een opdrag om dit te sien.

Stap 2: sien watter familie die kliënt geskakel het

Kyk na die socket eerder as na die vorderingsbalk. ’n Kliënt wat ’n socket IPv4 na ’n adres IPv4 op ’n skakel slegs met IPv6 oopmaak, het nêrens om dit te stuur nie, en die mislukking wys as ’n tydverloop eerder as ’n naamfout. ss -tanp terwyl die kliënt verbind, wys die afgeleë adres en die familie wat dit probeer het. Vergelyk dit met ip -6 route om te bevestig dat die verstek ’n egte volgende sprong IPv6 is.

Die adresfamilie in die sockettabel is die feit. Die vorderingsbalk is ’n opsomming wat iemand anders geskryf het.

Stap 3: skei vertaling van die tonnel

NAT64 en DNS64 is hoe die toegangsnetwerk bestemmings IPv4 bereik, en hulle doen niks vir die tonnel sodra dit op is nie. ’n Tonnel wat oor ’n vertaalde pad opgerig is, onderhandel steeds sy eie binne-adressering, en die binne-dekking IPv4 of IPv6 is ’n aparte beleidsvraag. As die kliënt verbind en dan niks bereik nie, is jy verby vertaling en in roetebepaling, wat ’n ander ondersoek met ander bewyse is.

Vertaling wat misluk lyk soos nooit verbind nie. Binne-dekking wat misluk lyk soos verbind en niks bereik nie.

Stap 4: toets dieselfde profiel op ’n ander netwerk

Neem dieselfde profiel, kliëntweergawe en geloofsbriewe na ’n dubbelstapelnetwerk en herhaal. As dit daar werk en op die pad slegs met IPv6 misluk, is die veranderlike die toegangsnetwerk eerder as die profiel. Teken die kliëntweergawe en die netwerkkondisie in die kaartjie aan, want die uiteindelike oplossing is ’n kliëntopdatering of ’n ander eindpunt.

’n Verslag wat sê die VPN is stukkend, is onaaksioneerbaar. ’n Verslag wat sê dit misluk net op toegang slegs met IPv6, is ’n foutverslag.

Stap 5: herstel die pad, nie die sekuriteitsinstellings nie

Die aanloklike herstellings maak alles slegter. Om IPv6 af te skakel, verwyder die enigste pad wat die netwerk bied. Om die kliënt na ’n openbare resolver te wys, breek DNS64-sintese, want daardie sintese moet van die resolver agter die vertaler kom. Om sertifikaatverifikasie af te skakel, gee jou ’n verbinding na iets wat jy nie kan identifiseer nie. Nie een van dié is ’n oplossing nie, en twee van hulle is sekuriteitsterugslae wat die voorval sal oorleef.

Die werklike opsies is ’n kliënt wat die netwerkvertalingsmodel ondersteun, of ’n eindpunt met ’n bereikbare adres IPv6. Vra vir een van dié.