Дали вашиот VPN го шифрира DNS или само следниот хоп?

Вклучувањето шифриран DNS на VPN серверот често се опишува како затворање на пропуст, а тој опис го крие тоа која врска се смени. Хопот од клиентот до резолверот и хопот од резолверот до горниот тек се одделни врски со одделни сопственици. Шифрирањето на едната ја остава другата точно каква што била.

Запишете кој го прима барањето во секоја фаза пред да допрете конфигурациска датотека.

Два распореди изгледаат исто на страницата со поставки

Во првиот распоред уредот сам извршува DNS over TLS, а тунелот едноставно го пренесува тоа поврзување до резолверот што сте го избрале. TLS сесијата завршува кај резолверот, што значи дека резолверот го гледа барањето, а VPN излезот гледа шифриран текст што не може да го прочита. Во вториот распоред уредот испраќа обичен DNS низ тунелот до препраќач на VPN хостот, и тој препраќач отвора своја шифрирана врска до горен резолвер. Во списокот со функции и двата изгледаат како "шифриран DNS со VPN", но читливото барање го сместуваат во различни згради.

Разликата е мерлива, а не филозофска. Побарајте TLS сесијата кај клиентот или кај серверот и ќе дознаете кој распоред навистина го имате.

Пред да ја смените, мапирајте го синџирот на резолвери

Избројте ги резолверите на патеката и именувајте ја улогата на секој од нив. Компонентата за препраќање му предава барање на друг резолвер, додека рекурзивниот резолвер ја врши работата да најде одговор и може директно да разговара со авторитативни сервери. Овие улоги се дефинирани одделно токму поради оваа причина, а RFC 9076 дефиниции за резолвери вреди да се прочитаат пред да претпоставите дека постои само една горна дестинација. Хостот што извршува сопствен рекурзивен резолвер нема единствен "горен тек" за шифрирање, што го прави целиот план неважечки.

Потоа прашајте која компонента клиентот е конфигуриран да ја користи. DNS адресата што ја доставува VPN профилот ви кажува каде одат барањата, а не кој процес одговара на нив.

Забележете го и однесувањето при неуспех. Ако шифрираниот горен тек стане недостапен, дали препраќачот паѓа затворено, се враќа на чист текст или се враќа на друг резолвер? Таа одлука треба да биде во записот, бидејќи ја менува гаранцијата за приватност во моментот кога тунелот е најмалку здрав.

Проверете кој хоп е шифриран

Започнете кај клиентот и потврдете дали држи TLS сесија до портата 853. Барање што правилно се решава преку портата 53 не докажува ништо за шифрирањето.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Потоа преминете на VPN хостот и побарајте ја излезната шифрирана врска што ја отворил препраќачот. Табелата со сокети ви кажува дали постои горна TLS сесија и кој процес ја поседува:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Ако клиентот покажува TLS сесија, а серверот не, тогаш сте во првиот распоред и серверот не може да ги чита барањата што ги препраќа на IP слојот. Ако серверот ја покажува TLS сесијата, а клиентот покажува обичен сообраќај на портата 53 внатре во тунелот, сте во вториот распоред: следниот хоп е заштитен, а препраќачот сè уште го чита секое име што уредот го бара. Тој втор резултат не е неуспех, но да се нарече шифрирање од крај до крај е погрешно.

Запишете го сопственикот и однесувањето при неуспех

Сопственоста одредува што смеете да ветите. Сопственикот на уредот ја контролира шифрираната врска на клиентската страна, додека VPN администраторот ја контролира следната врска што ја создава неговиот препраќач. Секој што не управува со ниту една од нив може само да ја опише патеката.

Пред да вклучите нешто, проверете ги внатрешните имиња. Испраќањето организациски имиња до јавен резолвер не е еднаков дизајн, а зоната со разделен хоризонт што постои само во мрежата воопшто нема да се реши горно. По промената тестирајте едно внатрешно и едно јавно име и чувајте го резултатот заедно со конфигурациската промена. Ако шифрираната патека го расипе решавањето за внатрешните хостови, решението е резолверско правило со ограничен опфат, а не поширок тунел.

Завршете со една реченица за секој хоп: која компонента го примила барањето, дали тој хоп бил шифриран и кој може да го прочита името. Кога реченицата за VPN хостот сè уште вели дека може да чита барања, документацијата треба тоа да го каже, бидејќи на дијаграм што тврди спротивното ќе му верува некој што никогаш не ги извршил командите.