Частен DNS в Pritunl не работи? Добавете тесен маршрут за резолвера

Частните имена се резолвват за всички в корпоративната мрежа и изтичат за всички във VPN. Резолверът отговаря на шлюза, маршрутът до него съществува, а заявката така и не получава отговор. Липсва не друг публичен резолвер или по-широк маршрут, а адрес на източник, на който частният DNS сървър е готов да отговори.

Потвърдете, че резолверът отказва вашия клиентски пул

Започнете с доказателство, че проблемът е в източника, а не в достъпността. От свързан клиент задайте заявка директно към частния резолвер и наблюдавайте дали тя изтича, или се връща като отказ. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 изтича, докато същата заявка от шлюза успява, което сочи политика за достъп на резолвера. Отговор SERVFAIL сочи съвсем другаде, обикновено към зоната или горния препращач.

Отбележете адреса на клиента преди теста. ip -4 addr show tun0 на клиента или лизингът, показан в конзолата, ви казва кой пул вижда резолверът.

След това потвърдете, че пътят изобщо съществува. Маршрут, който изпраща адреса на резолвера в тунела, е предпоставка, а не решение; ако пакетите никога не пристигат, политиката за източника дори не се разглежда. Проверете го с ip route get 10.40.0.53 на клиента.

Добавете един маршрут до хост вместо да транслирате всичко

Ръководството на Pritunl за частен DNS описва тясното решение: маршрут /32 с включен NAT за адреса на резолвера, като този адрес е избран за DNS сървър на клиентите. Маршрутът променя източника, който резолверът вижда, само за DNS трафика. Приложният трафик запазва запазващия източника дизайн, който сте избрали за него.

Конфигурирайте го през поддържания собственик на маршрути на сървъра, след като прегледате съществуващите маршрути за застъпване. В примера по-горе дестинацията е 10.40.0.53/32 с включен NAT, а клиентският пул остава 10.90.0.0/24. Не транслирайте целия частен диапазон, за да поправите една услуга, защото всяка последваща политика, която разчита на реалния адрес на клиента, ще започне да вижда вместо това шлюза. Потвърдете адреса, който резолверът действително получава, като наблюдавате журнала му на заявките по време на тестово търсене. Само маршрут до хост не доказва нищо за транслацията или разрешението.

Резолверът все още трябва да разрешава транслирания източник по UDP и TCP, а отговорите му трябва да могат да се върнат. Промяната на източника не може да създаде липсваща зона или запис.

Решете дали сървърът или клиентът изпраща заявката

Pritunl документира и схема с DNS прокси, свързана с VPN Client DNS Mapping, при която сървърът препраща горни заявки от името на клиентите. В този модел горният източник принадлежи на собствения мрежов контекст на сървъра и изключение от страна на клиента е грешното решение.

Определете кой модел е активен, преди да добавите нещо. Три припокриващи се поправки, прокси, замяна на резолвера на клиента и ръчен NAT скрипт обикновено означават, че никой не е установил: кой компонент трябва да изпраща заявката. Проверете и bootstrap: частният резолвер не може да е единственият начин да намерите крайната точка преди тунелът да съществува, а постоянно изменение на резолвера не бива да надживява връзката.

Тествайте частно търсене, а не публична уеб страница

След като приложите промяната и се свържете отново, прегледайте ефективната конфигурация на резолвера на клиента, след което резолвнете име, за което знаете, че съществува само в частната зона. dig intranet.example.net без изричен сървър показва какво клиентът всъщност използва. Последвайте го със заявка към адреса, който това търсене върна, защото резолвването и достъпът до услугата са отделни стъпки. Браузър, който зарежда публични сайтове през DNS-over-HTTPS, не доказва нищо за пътя на частния резолвер на операционната система. Публичен вторичен резолвер също не е авторитет за вътрешна зона.

Запишете адреса на резолвера, маршрута /32 и DNS настройката на клиента заедно в бележките на сървъра. Половината от тази конфигурация, възстановена сама, възпроизвежда първоначалния проблем.

Накрая потвърдете, че тунелът все още маршрутизира дестинацията на приложението, след като DNS успее. Маршрутът, достъпът до услугата и удостоверяването остават независими от резолвването на имена и работещото търсене не казва нищо за пропускателната способност. Ако частната страница е бавна, но се резолвва, резолверът си е свършил работата и проблемът се е преместил в пътя.