ستاسو CIFS ماؤنټ د nsswitch د ترتیب له امله د VPN له لارې ناکامېږي

شریکول د پت له مخې ځواب ورکوي او د نوم له مخې ځوړند پاتې کېږي، نو لټون د SMB له پیل مخکې مړ کېږي. getent له host سره پرتله کړئ، بیا د hosts کرښه په ترتیب سره ولولئ.

تونل فعال دی. د فایل سرور د پت له مخې ping ته ځواب ورکوي. بیا mount.cifs د هوسټ نوم سره یو څه وخت هلته ناست وي او راپور ورکوي چې هوسټ ته رسېدل ناشونی دی، او تاسو هغه VPN پروفایل بیا جوړول پیل کړئ چې هېڅکله ستونزه نه وه. په Linux کې glibc نوم د هر SMB بنډل له رامنځته کېدو مخکې حل کوي، او په هغه ریزولور کې ترتیب کولی شي لټون د DNS له پوښتنې مخکې پای ته ورسوي. دا هغه لار ده چې زه ځم، د کلینټ نه، بلکې د هغې کمانډې نه پیل کېږي چې ناکامه شوه.

ناکامي په سم ځای کې ولولئ

دوه وسیلې یو نوم ته بېلې لارې ځي، او د دوی پرتله کول یوه کمانډ لګښت لري. getent د ترتیب شوي نوم خدمتونو سټیک څخه تېرېږي؛ host او dig DNS ته مستقیم پوښتنه کوي او هغه سټیک نه غږېږي. که مستقیمه پوښتنه پت راوړي او getent هېڅ نه راوړي، DNS سرور ته رسېدل شونی دی او ستاسو د ریزولور ترتیب هغه دی چې ناکامېږي.

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

درېیمه کمانډ پرېکړه کوونکې ده: دا د DNS سرچینې ته زور ورکوي او پاتې سټیک پرېږدي. کله چې هغه کار وکړ او ساده getent ونه کړي، تاسو ثابته کړه چې ګناه په ترتیب کې ده، نه په تونل او نه په سرور.

د hosts کرښه هغه ترتیب دی چې ژر ودريږي

د glibc ریزولور /etc/nsswitch.conf لولي او د hosts: ننوتل له کیڼ نه ښي خوا ته تېروي. ډېری ویشنې هغه کرښه وړاندې کوي چې multicast لټون لومړی راځي او د ژر بېرته راتلو کړنه ورسره تړلې ده. هغه کړنه ښکلا نه ده: کله چې mDNS “not found” ځواب ورکړي، [NOTFOUND=return] ټول لټون پای ته رسوي، نو کارپوریټ نوم هېڅکله هغه ریزولور ته نه لېږل کېږي چې VPN تپلی دی. هېڅ شی یې لاګ نه کوي، ځکه چې هېڅ پوښتنه ونه لېږل شوه چې ریزولور یې رد کولی شوی. نو ځکه ماؤنټ ځوړند ښکاري او بیا راپور ورکوي چې هوسټ ته رسېدل ناشونی دی.

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

DNS د ژر بېرته راتلو کړنې مخې ته یوسئ نه دا چې mDNS ړنګ کړئ، او دا د ترتیب مدیریت له لارې بدل کړئ. لاسي سمون د بلې image جوړولو پورې ژوندی پاتې کېږي، او بیا هماغه ټکټ له بل ماشین نه راځي چې سمون نه یادېږي.

ریزولور د لټون ډومین نه دی

حل کول دا هم غواړي چې نوم وآزمایل شي. fileserver په څېر نیمګړی نوم یوازې هغه وخت fileserver.corp.example کېږي چې د پوښتنې وړونکي انټرفېس سره لټون ډومین وتړل شي. هغه VPN چې پرته له لټون لیست DNS سرور تپي، ډېر ځانګړی وېش رامنځته کوي: بشپړ وړ نوم حل کېږي او هر لنډ نوم ناکامېږي.

د پروفایل له سمولو مخکې دواړه بڼې وآزمایئ، ځکه چې دواړه ناکامۍ بېلو خواوو ته اشاره کوي. په systemd-resolved هوسټ کې د تونل لینک خپل سرورونه او روټینګ ډومینونه لري، نو لینک ولولئ نه نړیوال فایل.

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

که پوښتنه هغه لینک ته منسوبه شي چې تونل نه وړي، د روټینګ ډومین ورک دی که څه هم DNS پت شته. دا په resolved ترتیب کې د پالیسۍ ستونزه ده، نه په تونل کې د روټینګ ستونزه.

کانټینرونه د ځواب خپله کاپي وړي

له عمومي image څخه جوړ شوی کانټینر معمولاً یو ثابت resolv.conf راوړي. په هوسټ کې شوي ریزولور بدلونونه هلته نه رسېږي، او نه لټون ډومین، نو هغه build کار چې شریکول د تونل له لارې ماؤنټ کوي ناکامېږي، پداسې حال کې چې هماغه کمانډ د کانټینر څخه بهر کار کوي. کانټینر ته خپل DNS او لټون تنظیمات په compose فایل یا په run دلیلونو کې ورکړئ، نه یوازې په هوسټ پروفایل کې.

د image په تورنولو مخکې د کانټینر په داخل کې وګورئ. دوه کمانډې ټوله تشخیص په څو ثانیو کې بیا جوړوي، او دوهمه ثابتوي چې کوم ریزولور واقعاً ځواب ورکړی.

بیا یوازې شریکول او فلټر وګورئ

کله چې نوم حل شي، پاتې ناکامۍ عادي شبکې ستونزې دي. 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 ستونزه ده. ناحل شوی نوم د ریزولور ستونزه ده. او هغه ماؤنټ چې تصدیق کېږي خو د اجازې غلطۍ راګرځوي، د دواړو نه دی، نو د غونډې له جوړېدو وروسته د شبکې پوښتنه بیا مه خلاصوئ.

پایله د شاهدانو په اندازه تنګه وساتئ. کله چې پت کار وکړ او نوم ونه کړي، تونل خپله دنده ترسره کوي، او سمون د ریزولور ترتیب، لټون ډومین یا د کانټینر خپل ترتیب پورې اړه لري.

اړوندې مقالې