Приватни 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 на клијенту.

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

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

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

Резолвер и даље мора да дозволи преведени извор на UDP и TCP, а његови одговори морају моћи да се врате. Промена извора не може да створи зону или запис који недостаје.

Одлучите да ли упит шаље сервер или клијент

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

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

Тестирајте приватну претрагу, а не јавну веб страницу

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

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

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