Зашто се одговори DNS64 мењају чим се VPN повеже?

Одговор DNS64 кодира претпоставку о превођењу. Проверите који је резолвер одговорио, да ли је префикс рутиран и да ли на вашој путањи стоји преводилац.

Одговори DNS64 описују мрежни распоред, а не својство сервера. Резолвер синтетизује адресу IPv6 из адресе IPv4, и резултат ради само тамо где на крају тог префикса стоји преводилац. Уведите VPN у путању и тај распоред може да остане, да се промени или да престане да буде истинит у зависности од три услова.

Ти услови су резолвер који је одговорио, рута коју ваш уређај има до синтетизованог префикса и то да ли ишта на тој рути обавља превођење. Сваки је уочљив, и управо то квара чини дијагностикованим.

На шта синтетизовани AAAA запис заправо показује

Резолвер DNS64 одговара на AAAA упит за име које подржава само IPv4 тако што адресу IPv4 уграђује у префикс који је конфигурисан да користи, а познати префикс за тај посао је 64:ff9b::/96 како је описано у RFC 6147. Запис апликацији изгледа као и сваки други AAAA запис, и у томе је поента: клијент који подржава само IPv6 може да покуша везу и не знајући да одредиште никада није имало IPv6. Та веза затим зависи од функције NAT64 која негде на путу преводи између двеју фамилија. Без тог преводиоца, синтетизована адреса је уверљиво одредиште које никуда не води.

Запис дакле кодира две ствари одједном: изворну адресу IPv4 и претпоставку да је преводилац доступан. Само је прва видљива у самом одговору.

Три услова одлучују ради ли још

Први је услов који је резолвер произвео запис, јер онај без конфигурисаног DNS64 не враћа ништа за то име и апликација пада на другачији начин. Други је има ли ваш уређај руту до синтетизованог префикса, јер одговор може бити валидан док пут до њега недостаје. Трећи је је ли преводилац који поседује тај префикс на путу који бисте користили, јер тунел који носи 64:ff9b::/96 негде другде стиже до друге функције или ни до чега. Сва три могу да важе пре тунела и да закажу после њега, и зато симптом изгледа као изненадна регресија.

Проверите их тим редом. Одговор који недостаје и рута која недостаје изгледају једнако у прегледачу, а посве различито у дневнику резолвера.

Кад се резолвер промени, одговор се промени

VPN клијент често намеће свој резолвер или преузима цео пут упита, а тај резолвер можда ништа не синтетише. Упити за имена која подржавају само IPv4 тада не враћају AAAA запис, што клијент који подржава само IPv6 доживљава као име до којег не може да дође. Догађа се и обрнуто: резолвер који доиста синтетише може да вам да префикс који ваш тунелирани пут не носи.

Кеширање ово чини теже видљивим. Синтетизовани запис добијен на канцеларијској мрежи може да надживи контекст који га је произвео, па се клијент наставља да повезује на адресу чији преводилац више није доступан. Гледајте резолвер који одговара сада, а не онај који је одговорио кад је унос сачуван. Пражњење кеша без бележења старог и новог одговора уништава доказ који вам треба.

Испитајте претрагу и пут одвојено

Питајте име изравно пре него што укључите апликацију, и забележите који је сервер одговорио. Наредбе испод показују AAAA запис, резолвер који се користи и постоји ли рута до синтетизованог префикса. Покрените их са искљученим тунелом, па поново са укљученим.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Читајте резултате као ланац. AAAA запис који недостаје значи да резолвер пред вама не синтетише, па пут који подржава само IPv6 неће радити за то име, шта год клијент радио. Запис постоји а руте нема значи да префикс не носи тренутни пут, и то је одлука о рутирању, а не квар резолвера. Рута постоји док захтев још пада — то упућује на сам преводилац, а то припада још једном власнику.

Забележите резолвер, мрежни контекст и фамилију адреса уз сваки резултат. Управо та белешка омогућује следећем поређењу да одвоји промену резолвера од промене рутирања.

Повезани чланци