In netwurk allinnich IPv6 brekt de VPN foar’t de tunnel begjint

De laptop makket ferbining mei in konferinsje-Wi-Fi dy’t allinnich IPv6 útdielt, de VPN-klant draait en mislearret, en datselde profyl wurke in oere earder yn in hotel. Oan de oanmeldgegevens is neat feroare. Wat feroare is, is dat de klant no in bestimming IPv4 berikke moat fia in netwurk dat allinnich IPv6 draacht, en net elke klant wit hoe’t dat moat.

Gean deselde fiif stappen dy’t de pakketten gean.

Stap 1: sjoch nei de nammeable

As it profyl in hostnamme brûkt, is de earste fraach wat de resolver weromjout. dig AAAA vpn.example.com jout op it netwurk allinnich IPv6 in echte AAAA-record, ien dy’t út DNS64 syntetisearre is, of hielendal neat. In syntetisearre antwurd kodearret de bestimming IPv4 yn in oersetprefix, en pas dan kin in klant sûnder bestimming IPv6 der komme. In profyl mei in hurdcodearre adres IPv4 komt nea sa fier, want der is gjin namme om te syntetisearjen.

Dat iene ferskil ferklearret de measte rapporten fan wurket-dêr-mislearret-hjir, en it kostet ien opdracht om it te sjen.

Stap 2: sjoch hokker famylje de klant skille hat

Sjoch nei de socket ynstee fan de foarútgongsbalke. In klant dy’t in socket IPv4 nei in adres IPv4 iepenet op in keppeling allinnich IPv6 hat nearne om it hinne te stjoeren, en de mislearring docht bliken as in timeout ynstee fan in namflater. ss -tanp wylst de klant ferbynt, lit it fiere adres en de famylje sjen dy’t it besocht hat. Fergelykje dat mei ip -6 route om te befêstigjen dat de standert in echte folgjende hop IPv6 is.

De adresfamylje yn ’e sockettabel is it feit. De foarútgongsbalke is in gearfetting dy’t immen oars skreaun hat.

Stap 3: skied de oersetting fan de tunnel

NAT64 en DNS64 binne hoe’t it tagongsnetwurk bestimmingen IPv4 berikt, en se dogge neat foar de tunnel as dy ienris oerein is. In tunnel oprjochte oer in oerset paad ûnderhannelet noch altyd syn eigen ynterne adressearring, en de ynterne dekking IPv4 of IPv6 is in apart beliedsfraach. As de klant ferbynt en dan neat berikt, binne jo foarby de oersetting en yn ’e routing, wat in oar ûndersyk is mei oare bewizen.

Oersetting dy’t mislearret liket as ferbynt nea. Ynterne dekking dy’t mislearret liket as ferbynt en berikt neat.

Stap 4: test itselde profyl op in oar netwurk

Nim itselde profyl, klantferzje en oanmeldgegevens nei in dûbelstacknetwurk en werhelje. As it dêr wurket en mislearret op it paad allinnich IPv6, is de fariabele it tagongsnetwurk ynstee fan it profyl. Skriuw de klantferzje en de netwurkstân yn it ticket, want de úteinlike oplossing is in klantfernijing of in oare bestimming.

In rapport dat seit dat de VPN stikken is, is net útfierber. In rapport dat seit dat it allinnich mislearret op tagong allinnich IPv6, is in flerrapport.

Stap 5: reparearje it paad, net de feilichheidsynstellingen

De ferloklike reparaasjes meitsje alles minder. IPv6 útskeakelje hellet it iennichste paad fuort dat it netwurk biedt. De klant nei in iepenbiere resolver wize brekt DNS64-synteze, want dy synteze moat fan de resolver efter de oersetter komme. Sertifikaatferifikaasje útskeakelje jout jo in ferbining nei eat dat jo net identifisearje kinne. Net ien fan dy is in reparaasje, en twa fan har binne feilichheidsregresjes dy’t it foarfal oerlibje sille.

De echte opsjes binne in klant dy’t it netwurkoersettingmodel stipet, of in bestimming mei in berikber adres IPv6. Freegje om ien fan dy.