Приватниот DNS на Pritunl не работи? Додајте тесна resolver-рута

Приватните имиња се решаваат за сите на корпоративната мрежа и истекуваат за сите на VPN. Resolver-от одговара на портата, рутата до него постои, а барањето сепак никогаш не добива одговор. Не недостига друг јавен resolver или поширока рута: недостига изворна адреса на која приватниот DNS сервер е подготвен да одговори.

Потврдете дека resolver-от го одбива вашиот клиентски базен

Започнете со доказ дека дефектот е поврзан со изворот, а не со достапноста. Од поврзан клиент, прашајте го приватниот resolver директно и гледајте дали барањето истекува или се враќа како одбивање. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 што истекува додека истото барање од портата успева укажува на политика за пристап на resolver-от. Одговорот SERVFAIL укажува на сосема друго место, обично на зоната или на горниот препраќач.

Забележете ја адресата на клиентот пред тестирањето. ip -4 addr show tun0 на клиентот или закупот прикажан во конзолата ви кажува кој базен го гледа resolver-от.

Потоа потврдете дека патеката воопшто постои. Рута што ја испраќа адресата на resolver-от во тунелот е предуслов, а не решение; ако пакетите никогаш не пристигнат, политиката за извор воопшто не се разгледува. Проверете го со ip route get 10.40.0.53 на клиентот.

Додајте една host-рута наместо да преведете сето

Упатството на Pritunl за приватен DNS го опишува тесното решение: рута /32 со вклучен NAT за адресата на resolver-от, при што таа адреса е избрана како DNS сервер на клиентите. Рутата го менува изворот што resolver-от го гледа само за DNS сообраќај. Сообраќајот на апликациите го задржува дизајнот што го зачувува изворот што сте го избрале за него.

Конфигурирајте ја преку поддржаниот сопственик на рути на серверот, откако ќе ги прегледате постојните рути за преклопување. Во примерот погоре целта е 10.40.0.53/32 со вклучен NAT, а клиентскиот базен останува 10.90.0.0/24. Не преведувајте го целиот приватен опсег за да поправите една услуга, бидејќи секоја низводна политика што се потпира на вистинската адреса на клиентот ќе почне да ја гледа портата наместо неа. Потврдете ја адресата што resolver-от навистина ја прима со набљудување на неговиот дневник на барања при тест пребарување. Самата host-рута не докажува ништо за преводот или дозволата.

Resolver-от сѐ уште мора да го дозволи преведениот извор на UDP и TCP, а неговите одговори мора да можат да се вратат. Менувањето на изворот не може да создаде зона или запис што недостига.

Одлучете дали серверот или клиентот го испраќа барањето

Pritunl документира и поставеност со DNS-прокси поврзана со VPN Client DNS Mapping, каде серверот препраќа горни барања за клиентите. Во тој модел горниот извор му припаѓа на сопствениот мрежен контекст на серверот, а исклучокот на клиентската страна е погрешно решение.

Определете кој модел е активен пред да додадете нешто. Три преклопувачки поправки, прокси, замена на resolver-от на клиентот и рачна NAT-скрипта обично значат дека никој не утврдил: која компонента треба да го испраќа барањето. Проверете го и bootstrap: само-приватен resolver не може да биде единствениот начин да се најде крајната точка пред тунелот да постои, а трајната измена на resolver-от не треба да ја надживее врската.

Тестирајте приватно пребарување, а не јавна веб-страница

Откако ќе ја примените измената и ќе се поврзете повторно, прегледајте ја ефективната конфигурација на resolver-от на клиентот, потоа решете име за кое знаете дека постои само во приватната зона. dig intranet.example.net без експлицитен сервер покажува што клиентот всушност користи. Потоа испратете барање до адресата што ја врати тоа пребарување, бидејќи решавањето и пристапот до услугата се одделни чекори. Прелистувач што вчитува јавни страници преку DNS-over-HTTPS не докажува ништо за приватната resolver-патека на оперативниот систем. Ниту јавен секундарен resolver не е авторитет за внатрешна зона.

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

На крајот потврдете дека тунелот сѐ уште ја насочува дестинацијата на апликацијата откако DNS ќе успее. Рутата, пристапот до услугата и автентикацијата остануваат независни од решавањето имиња, а пребарувањето што работи не кажува ништо за пропусната моќ. Ако приватната страница е бавна но се решава, resolver-от ја завршил својата работа и проблемот се преселил на патеката.