CIFS холболт VPN дээгүүр nsswitch-ийн дарааллаас болж бүтэлгүйтдэг

Туннель ажиллаж байна. Файлын сервер ping-д хаягаар хариулдаг. Дараа нь mount.cifs хостын нэрээр хэсэг хугацаа зогсоод, хост хүрэхгүй гэж мэдэгддэг бөгөөд та хэзээ ч асуудал болж байгаагүй VPN профайлыг дахин бүтээж эхэлдэг. Linux дээр ямар ч SMB пакет үүсэхээс өмнө glibc нэрийг шийддэг бөгөөд тэр resolver дахь дараалал DNS-ээс асуухаас өмнө хайлтыг дуусгаж чадна. Энэ бол миний явдаг зам, клиентээс биш, бүтэлгүйтсэн командаас эхэлдэг.

Алдааг зөв газар уншина уу

Хоёр хэрэгсэл нэг нэр рүү өөр замаар явдаг бөгөөд тэдгээрийг харьцуулахад нэг команд хангалттай. getent тохируулсан нэрийн үйлчилгээний стекийг дамждаг; host болон dig DNS-ээс шууд асууж, тэр стекийг үл харгалздаг. Шууд асуулга хаяг буцааж, getent юу ч буцаахгүй бол DNS сервер хүрэх боломжтой бөгөөд бүтэлгүйтэж байгаа нь таны resolver-ийн тохиргоо юм.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Гурав дахь команд нь шийдвэрлэгч: энэ нь DNS эх сурвалжийг албадаж, стекийн үлдсэнийг алгасдаг. Тэр ажиллаж, энгийн getent ажиллахгүй бол та буруу нь дараалалд байгаа гэдгийг нотолсон, туннельд ч биш, серверт ч биш.

hosts мөр нь эрт зогсдог дараалал юм

glibc resolver /etc/nsswitch.conf-г уншиж, hosts: бичлэгийг зүүнээс баруун тийш туулна. Олон дистрибутив multicast хайлт эхэнд байрлаж, түүнд эрт буцах үйлдэл хавсарсан мөр нийлүүлдэг. Тэр үйлдэл нь чимэглэл биш: mDNS “not found” гэж хариулах үед [NOTFOUND=return] бүх хайлтыг дуусгадаг тул корпорацийн нэр VPN-ийн тулгасан resolver руу хэзээ ч илгээгддэггүй. Үүнийг юу ч логлохгүй, учир нь resolver-ийн татгалзаж болох асуулга огт илгээгдээгүй. Тиймээс холболт өлгөгдсөн мэт харагдаад дараа нь хост хүрэхгүй гэж мэдэгддэг.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

mDNS-ийг устгахын оронд DNS-ийг эрт буцах үйлдлийн өмнө зөөж, үүнийг тохиргооны удирдлагаар өөрчил. Гараар хийсэн засвар дараагийн image бүтээх хүртэл амьдарч, дараа нь мөн тэр тасалбар засварыг санахгүй өөр машинаас ирдэг.

Resolver бол хайлтын домэйн биш

Шийдэхийн тулд нэрийг туршиж үзэх шаардлагатай. fileserver мэт бүрэн бус нэр нь асуулгыг зөөж буй интерфэйсэд хайлтын домэйн хавсарсан үед л fileserver.corp.example болдог. Хайлтын жагсаалтгүйгээр DNS сервер тулгадаг VPN маш тодорхой хуваагдал үүсгэдэг: бүрэн квалификацлагдсан нэр шийдэгдэж, богино нэр бүр бүтэлгүйтдэг.

Профайлыг засахын өмнө хоёр хэлбэрийг туршиж үзээрэй, учир нь хоёр бүтэлгүйтэл өөр чиглэл рүү заадаг. systemd-resolved хост дээр туннелийн холбоос өөрийн сервер, маршрутын домэйнтэй тул глобал файлыг биш, холбоосыг уншина уу.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Асуулга туннелийг зөөдөггүй холбоосд хамаарагдвал DNS хаяг байгаа ч маршрутын домэйн дутагдана. Энэ нь resolved тохиргооны бодлогын асуудал, туннелийн маршрутын асуудал биш.

Контейнерууд хариултын өөрийн хуулбарыг авч явдаг

Ерөнхий image-ээс бүтээсэн контейнер ихэвчлэн тогтмол resolv.conf-г авчирдаг. Хост дээрх resolver-ийн өөрчлөлт түүнд хүрэхгүй, хайлтын домэйн ч хүрэхгүй тул туннелээр хуваалцсан санг холбодог build ажил бүтэлгүйтэж, мөн тэр команд контейнерын гадна ажилладаг. Контейнерт өөрийн DNS болон хайлтын тохиргоог compose файл эсвэл run аргументд өг, зөвхөн хост профайлд биш.

Image-ийг буруутгахын өмнө контейнер дотор шалга. Хоёр команд бүх оношилгоог хэдхэн секундэд дахин гаргаж, хоёр дахь нь аль resolver үнэхээр хариулсныг нотолдог.

Зөвхөн тэгээд л хуваалцсан сан болон шүүлтүүр рүү хар

Нэр шийдэгдсэний дараа үлдсэн бүтэлгүйтлүүд нь энгийн сүлжээний асуудал юм. SMB-д сервер рүү TCP 445 хэрэгтэй, ажлын бүлгийн жагсаалтыг үзэх нь туннель дамжуулахгүй байх нэрийн үйлчилгээнээс хамаардаг. Жагсаалт дүүрэхийг хүлээхийн оронд хостын нэрээр холбож, клиент аль шатанд хүрснээ хэлээрэй. Татгалзсан холболт болон чимээгүй timeout-ыг ялгах нь ч зүйтэй, учир нь эхнийх нь ихэвчлэн ямар нэгэн зүйл хариулсан, хоёр дахь нь юу ч хариулаагүй гэсэн үг.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Шийдэгдсэн хаяг дээр 445 порт татгалзагдсан эсвэл хугацаа нь дууссан бол энэ нь нөгөө талын firewall эсвэл listener-ийн асуудал. Шийдэгдээгүй нэр бол resolver-ийн асуудал. Харин баталгаажуулалт хийгдээд зөвшөөрлийн алдаа буцаадаг холболт нь хоёулаа биш тул сесс тогтсоны дараа сүлжээний асуултыг дахин нээх хэрэггүй.

Дүгнэлтийг нотолгоотой адил нарийн бариарай. Хаяг ажиллаж, нэр ажиллахгүй бол туннель өөрийн ажлыг хийж байгаа бөгөөд засвар нь resolver-ийн дараалал, хайлтын домэйн эсвэл контейнерын өөрийн тохиргоонд хамаарна.