WireGuard میں DNS ٹھیک کریں: 3 عام خرابیاں

WireGuard ٹنل فعال ہوتے ہی DNS کیوں خراب ہو جاتا ہے

WireGuard کے ذریعے DNS تین طریقوں سے ناکام ہوتا ہے، اور ہر طریقے کا الگ حل ہے۔ کبھی کچھ بھی resolve نہیں ہوتا، کبھی نام resolve ہو جاتے ہیں لیکن queries ٹنل سے باہر آپ کی مشین سے روانہ ہوتی ہیں، اور کبھی کلائنٹ کا اپنا resolver manager interface شروع ہونے کے چند سیکنڈ بعد setting کو overwrite کر دیتا ہے۔ تقریباً کبھی بھی مسئلہ ٹنل نہیں ہوتا۔ مسئلہ وہ ایک سطر ہوتی ہے جو کلائنٹ کو بتاتی ہے کہ کس resolver سے پوچھنا ہے، اور routing یہ طے کرتی ہے کہ اس resolver تک packets کس راستے سے جائیں گے۔

WireGuard IP packets منتقل کرتا ہے اور DNS کے بارے میں کچھ نہیں جانتا (domain name system، یعنی وہ سروس جو example.com جیسے ناموں کو IP addresses میں تبدیل کرتی ہے)۔ کلائنٹ کے [Interface] block میں موجود DNS = سطر WireGuard setting نہیں ہے۔ اسے wg-quick پڑھتا ہے، جو interface کو فعال کرنے والا shell wrapper ہے، اور wg-quick ٹنل فعال رہنے کے دوران کلائنٹ کی resolver configuration میں ترمیم کرتا ہے اور wg-quick down پر اسے بحال کر دیتا ہے۔ اس لیے ذیل کا ہر مسئلہ routing یا wg-quick کا مسئلہ ہے، cryptography کا نہیں۔ اگر ٹنل ابھی قائم نہیں کیا گیا تو پہلے اپنے VPS پر self-hosted WireGuard VPN سے آغاز کریں، پھر اس صفحے پر واپس آئیں۔

DNS کو چھونے سے پہلے ٹنل کی صحت کی تصدیق کریں۔

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show میں peer کے ساتھ حالیہ latest handshake دکھائی دینا چاہیے، اور دونوں ping کا جواب آنا چاہیے۔ اگر ping 1.1.1.1 timeout ہو جائے تو غالباً مسئلہ DNS کے بجائے forwarding یا NAT (network address translation) کا ہے، اور resolver configuration کی کوئی بھی تبدیلی مدد نہیں کرے گی۔ ICMP کو drop کرنے والا firewall بھی یہی timeout پیدا کر سکتا ہے، اس لیے forwarding rules تبدیل کرنے سے پہلے curl -sI https://1.1.1.1 سے تصدیق کریں۔ اگر ping کا جواب آتا ہو لیکن حقیقی traffic شروع ہوتے ہی throughput بہت کم ہو جائے تو یہ الگ مسئلہ ہے، اور WireGuard کی سست رفتار تقریباً ہمیشہ MTU سے متعلق ہوتی ہے، نہ کہ اس صفحے پر بیان کردہ کسی چیز سے۔ یہاں ہر مثال میں 10.8.0.0/24 کو tunnel subnet اور 10.8.0.1 کو server کے tunnel address کے طور پر استعمال کیا گیا ہے۔ اپنی values استعمال کریں۔

پہلی خرابی: کچھ بھی resolve نہیں ہوتا، کیونکہ resolver کبھی جواب نہیں دیتا

علامت واضح ہے۔ ping 1.1.1.1 کام کرتا ہے، جبکہ curl https://example.com یہ نتیجہ دیتا ہے:

curl: (6) Could not resolve host: example.com

کلائنٹ سے tunnel resolver کو براہِ راست query کریں۔ Ubuntu اور Debian میں dig، dnsutils package کا حصہ ہے۔

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

پہلی command ایک address واپس کرتی ہے، جس سے ثابت ہوتا ہے کہ packets tunnel کے ذریعے internet تک پہنچ رہے ہیں۔ دوسری command کچھ واپس نہیں کرتی اور ;; communication timed out; no servers could be reached دکھاتی ہے۔ یہی مکمل تشخیص ہے: آپ کا client 10.8.0.1 کی طرف متوجہ ہے، اور 10.8.0.1 UDP port 53 پر جواب نہیں دے رہا۔

اس کی دو وجوہات ہو سکتی ہیں۔ یا تو server پر کوئی resolver چل نہیں رہا، یا server firewall query کو پہنچنے سے پہلے drop کر رہا ہے۔ Server پر دونوں چیزیں چیک کریں۔

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

جو resolver چل رہا ہو اور درست طور پر bind ہو، اس میں 10.8.0.1:53 یا 0.0.0.0:53 والی line دکھائی دیتی ہے۔ Ubuntu پر عموماً مسئلہ 127.0.0.53:53 ہوتا ہے: یہ systemd-resolved کا stub listener ہے، جو loopback address پر bind ہوتا ہے اور جان بوجھ کر دوسری machines سے ناقابل رسائی رہتا ہے۔ ایسے server کی طرف VPN client کو متوجہ کرنے سے، جس کا واحد resolver یہی stub ہو، عین یہی timeout پیدا ہوتا ہے۔

حل یہ ہے کہ ایسا resolver استعمال کریں جو tunnel address پر listen کرے، اور ایک firewall rule شامل کریں جو peers کو اس تک پہنچنے دے۔

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

اس کے بعد port کو صرف tunnel traffic کے لیے کھولیں۔ nftables کے ساتھ /etc/nftables.conf میں input chain کے اندر یہ دو lines شامل کریں، پھر sudo systemctl reload nftables سے reload کریں۔

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

ufw کے ساتھ sudo ufw allow in on wg0 to any port 53 یہی کام کرتا ہے۔ port 53 کو public internet کے لیے کبھی نہ کھولیں۔ Open recursive resolver چند دنوں میں scanners کو مل جاتا ہے اور denial of service attacks کو amplify کرنے کے لیے استعمال ہوتا ہے۔ آپ کا provider یہ traffic آپ سے پہلے محسوس کر لے گا۔

Client سے dig +short @10.8.0.1 example.com دوبارہ چلائیں۔ Output میں address آنے کا مطلب ہے کہ resolver path کام کر رہا ہے، اس لیے اب client کو صرف اسے استعمال کرنا ہے۔ یہ line client کے [Interface] block میں شامل کریں اور sudo wg-quick down wg0 && sudo wg-quick up wg0 سے interface restart کریں۔

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

خرابی دوم: DNS leaks، کیونکہ split tunnel resolver کو route نہیں کرتا

یہ مسئلہ زیادہ سنگین ہے، کیونکہ بظاہر سب کچھ درست کام کرتا ہے۔ Names resolve ہوتے ہیں، صفحات load ہوتے ہیں، اور queries اس local network سے cleartext میں گزرتی ہیں جس پر آپ اعتماد نہیں کرنا چاہتے تھے۔

اس کی دو configurations وجہ بنتی ہیں۔ پہلی configuration ایسے client کی ہے جس میں AllowedIPs = 0.0.0.0/0, ::/0 موجود ہو اور DNS = line نہ ہو۔ wg-quick اپنی routing table میں default route install کرتا ہے اور suppress_prefixlength 0 کے ساتھ ایک rule شامل کرتا ہے۔ اس سے زیادہ specific local routes جان بوجھ کر برقرار رہتی ہیں تاکہ machine اب بھی اپنے printer تک پہنچ سکے۔ Client نے DHCP کے ذریعے جو resolver حاصل کیا، عموماً 192.168.1.1 پر موجود router، وہ انہی local routes میں سے ایک route سے match کرتا ہے۔ آپ کا traffic tunnel سے گزرتا ہے، لیکن local network کو ان تمام names کی مکمل فہرست موصول ہوتی رہتی ہے جنہیں آپ lookup کرتے ہیں۔

دوسری configuration split tunnel ہے: AllowedIPs = 10.8.0.0/24 کے ساتھ DNS = 9.9.9.9۔ چونکہ 9.9.9.9، AllowedIPs کے اندر نہیں ہے، اس لیے client کے پاس اسے tunnel کے ذریعے پہنچنے کا کوئی route نہیں ہوتا۔ چنانچہ query بالکل پہلی صورت کی طرح local link سے باہر نکل جاتی ہے۔

ثابت کریں کہ واقعی کون سا resolver جواب دے رہا ہے۔ whoami.akamai.net ایک public test name ہے جو اس recursive resolver کے IP address کے ساتھ جواب دیتا ہے جس نے query بھیجی ہو۔ اس طرح آپ اس کے جواب کا اپنے server کے public address سے موازنہ کر سکتے ہیں۔

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status ہر link کے لیے ایک الگ block دکھاتا ہے۔ اگر آپ کے ethernet یا wireless link کے block میں اب بھی Current DNS Server: 192.168.1.1 دکھائی دے، جبکہ wg0 block میں کچھ نہ ہو، تو یہی leak ہے۔ dig +short whoami.akamai.net کا آپ کے server کے address کے بجائے گھر کے broadband address کے ساتھ جواب دینا remote end سے بھی اس کی تصدیق کرتا ہے۔ tcpdump line وہ حتمی ثبوت ہے جو اختلاف ختم کرتی ہے: درست output میں machine سے باہر جانے والا ہر port 53 packet wg0 پر ہونا چاہیے، جبکہ leak کی صورت میں وہ wlan0 یا enp3s0 پر ہوتا ہے۔ lo پر 127.0.0.53 سے یا اس کی طرف جانے والے packets ایسی applications کے ہوتے ہیں جو local systemd-resolved stub سے بات کر رہی ہوتی ہیں، اور یہ leak نہیں ہے۔

اس کا حل دو حصوں پر مشتمل ہے، اور دونوں ضروری ہیں۔ DNS کو ایسے address پر set کریں جو tunnel کے اندر موجود ہو، اور یقینی بنائیں کہ وہ address AllowedIPs کے اندر بھی شامل ہو۔

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1، 10.8.0.0/24 کے اندر موجود ہے، اس لیے query encrypted ہو کر server کو بھیجی جاتی ہے۔ اگر آپ split tunnel پر public resolver استعمال کرنے پر اصرار کرتے ہیں تو اسے host route کے طور پر شامل کریں: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32۔ اس کے بعد packets tunnel کے ذریعے بھیجے جاتے ہیں، اگرچہ local network اب بھی سابقہ sessions سے یہ دیکھ سکتا ہے کہ آپ نے کس provider کا انتخاب کیا ہے۔ اپنا resolver خود چلانے سے یہ مسئلہ ختم ہو جاتا ہے۔

Resolver assignment، ہاتھ سے تیار کردہ WireGuard اور coordinated mesh کے درمیان نمایاں فرقوں میں سے ایک ہے، اور یہ WireGuard کا Tailscale سے موازنہ میں بیان کردہ tradeoff کا حصہ ہے۔ خود hosted Headscale control server چلانے سے آپ کو یہ coordination حاصل ہوتی ہے، جبکہ اپنا key material کسی third party کے حوالے نہیں کرنا پڑتا۔ اگر یہی آخری بات آپ کے لیے باعث تشویش ہے تو یاد رکھیں کہ Tailscale آپ کے traffic کو encrypt کرنے والی keys کبھی اپنے پاس نہیں رکھتا۔ زیادہ اہم سوال یہ ہے کہ compromised coordination server یا چوری شدہ identity account آپ کے network میں کیا اضافی رسائی حاصل کر سکتا ہے۔

لینکس کلائنٹس پر resolvconf اور systemd-resolved میں ٹکراؤ

macOS، Windows، iOS اور Android کلائنٹس سرکاری ایپ کے ذریعے DNS = لاگو کرتے ہیں اور عموماً کوئی خاص مسئلہ پیدا نہیں کرتے۔ مسئلہ Linux میں ہوتا ہے، جہاں یہ setting ایک shell script کے ذریعے لاگو ہوتی ہے۔ اس script کو اندازہ لگانا پڑتا ہے کہ آپ کئی ممکنہ resolver managers میں سے کون سا استعمال کر رہے ہیں۔

پہلی خرابی واضح ہوتی ہے۔ sudo wg-quick up wg0 اس پیغام کے ساتھ رک جاتا ہے:

resolvconf: command not found

wg-quick، resolvconf کو چلاتا ہے، لیکن یہ binary نصب نہیں ہے۔ Debian 12 اور Ubuntu 24.04 یا بعد کے ورژنز میں systemd-resolved سے بات کرنے والی resolvconf command، systemd-resolved package میں شامل ہوتی ہے۔ اس package کو نصب کریں، پھر interface کو دوبارہ فعال کریں۔ Ubuntu 22.04 میں اس کے لیے الگ package نہیں ہے۔ وہاں sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf کے ذریعے compatibility link خود بنائیں اور install والی line چھوڑ دیں۔

sudo apt install -y systemd-resolved
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

دوسری خرابی خاموش ہوتی ہے، اور یہی ایک شام ضائع کر دیتی ہے۔ interface فعال ہو جاتا ہے، resolvectl status wg0 درست طور پر DNS Servers: 10.8.0.1 دکھاتا ہے، لیکن lookups اب بھی پرانے resolver تک پہنچتے ہیں۔ systemd-resolved، wg0 کو نظر انداز نہیں کر رہا۔ جو نام کسی routing domain سے match نہ ہو، وہ ہر اس link کے DNS servers کو بھیجا جاتا ہے جسے default route شمار کیا جاتا ہے۔ جس link پر DNS servers موجود ہوں اور route-only domain نہ ہو، اسے default طور پر default route شمار کیا جاتا ہے۔ اس لیے query ایک ہی وقت میں 10.8.0.1 اور wireless link کے router کو بھیجی جاتی ہے، اور جو جواب پہلے کامیاب ہو، وہ استعمال ہوتا ہے۔ Router صرف ایک hop دور ہوتا ہے اور عموماً پہلے جواب دیتا ہے۔ دونوں صورتوں میں query پہلے ہی cleartext میں باہر جا چکی ہوتی ہے۔ wireless link کے اپنے search domain کے تحت نام، مثلاً lan، صرف اسی link کو بھیجے جاتے ہیں، کیونکہ سب سے زیادہ مخصوص routing domain کو ترجیح ملتی ہے۔

جب wg-quick، systemd کے اپنے resolvconf wrapper کے ذریعے DNS = لاگو کرتا ہے، تو وہ پہلے ہی catch-all routing domain کی درخواست کرتا ہے۔ اس لیے یہ خرابی عموماً اس وقت سامنے آتی ہے جب کسی دوسرے resolvconf implementation یا network manager نے setting لاگو کی ہو۔ اسے واضح طور پر set کرنے سے اندازے کی ضرورت ختم ہو جاتی ہے۔

اسی مرحلے میں resolver set کریں اور catch-all routing domain بھی مقرر کریں۔ %i interface name میں تبدیل ہو جاتا ہے، اس لیے یہ block کسی بھی interface پر بغیر تبدیلی کے کام کرتا ہے۔

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

جب آپ PostUp کو اس طریقے سے استعمال کریں تو DNS = والی line حذف کر دیں، کیونکہ بصورت دیگر دو mechanisms resolver state لکھیں گے اور بعد میں صرف ایک ہی اسے صاف کرے گا۔ ~. argument اس کا اہم حصہ ہے۔ یہ wg0 کو ہر نام کے لیے route-only domain بناتا ہے۔ اس کے نتیجے میں systemd-resolved ایسے نام، جن سے کوئی زیادہ مخصوص domain match نہ ہو، دوسرے links کو بھیجنا بند کر دیتا ہے۔ کسی دوسرے link کے اپنے domain کے تحت نام، مثلاً lan، پھر بھی اسی link کو بھیجے جاتے ہیں، جو عموماً local hosts کے لیے مطلوب ہوتا ہے۔ اس کی تصدیق کریں۔

resolvectl status wg0

درست output میں DNS Servers: 10.8.0.1 اور DNS Domain: ~. شامل ہوتے ہیں۔ اگر ~. موجود نہ ہو تو resolvectl domain والا حصہ نہیں چلا، اور wg0 دوبارہ دوسرے links کے ساتھ مقابلہ کر رہا ہے۔ check کے طور پر default route flag استعمال نہ کریں۔ یہ yes دکھاتا ہے، یا systemd version کے مطابق Protocols line پر +DefaultRoute دکھاتا ہے، حتیٰ کہ ~. موجود نہ ہو۔ اس کی وجہ یہ ہے کہ route-only domain کے بغیر link خود بخود default route شمار ہوتا ہے۔

ایک اور صورت کا ذکر ضروری ہے۔ اگر /etc/resolv.conf، /run/systemd/resolve/stub-resolv.conf کی طرف symlink کے بجائے ایک حقیقی file ہو تو اس کا مالک کوئی دوسرا component ہے، عموماً NetworkManager یا container runtime۔ کسی اور debugging سے پہلے ls -l /etc/resolv.conf چلائیں، کیونکہ جو tool ہر network change پر اس file کو دوبارہ لکھتا ہو، وہ سب سے نامناسب وقت پر آپ کی تبدیلی ختم کر دے گا۔

ٹَنل کے ذریعے اپنا filtering resolver: اپ گریڈ

جب queries قابلِ اعتماد طور پر ٹنل سے گزرنے لگیں تو دوسری طرف موجود resolver ایک control point بن جاتا ہے۔ وہاں AdGuard Home چلانے سے ہر connected device کو blocklist filtering اور query log ملتا ہے، جبکہ client software یا فی device configuration کی ضرورت نہیں رہتی۔ اکتوبر 2026 میں checked official install script صرف ایک لائن پر مشتمل ہے۔

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

پہلی بار چلنے پر setup wizard port 3000 پر requests سنتا ہے۔ اس تک public طور پر وہ port کھولنے کے بجائے ٹنل کے ذریعے http://10.8.0.1:3000 پر پہنچیں، اور wizard میں DNS listen address اور admin listen address دونوں کو 10.8.0.1 پر set کریں۔ اگر failure one سے unbound اب بھی اسی address کو استعمال کر رہا ہو تو پہلے اسے sudo systemctl disable --now unbound کے ذریعے stop کریں، کیونکہ ایک ہی address پر UDP port 53 کے لیے دونوں میں تصادم ہوگا اور AdGuard Home listen udp 10.8.0.1:53: bind: address already in use کے ساتھ exit ہو جائے گا۔

اگر client configs میں پہلے ہی DNS = 10.8.0.1 درج ہے تو ان میں کسی تبدیلی کی ضرورت نہیں۔ اب query log ہر peer سے اس تک پہنچنے والی ہر lookup دکھائے گا، الا یہ کہ آپ کسی client کو logging سے خارج کریں۔ یہ واقعی privacy کا فیصلہ ہے، کوئی بلا معاوضہ فائدہ نہیں۔ اس صورت میں trust آپ کے internet provider سے منتقل ہو کر آپ کی اپنی ذمہ داری بن جاتا ہے، اور اس box کو patched رکھنا بھی آپ ہی کا کام ہے۔ internet کے سامنے exposed server پر پہلے بنیادی security اقدامات مکمل ہونے چاہییں، اور نئے VPS کے پہلے دس منٹ میں ان کا احاطہ کیا گیا ہے۔

FAQ

میرے WireGuard tunnel کا connection قائم ہو جاتا ہے، لیکن نام resolve کیوں نہیں ہوتے؟

Tunnel packets منتقل کرتا ہے اور ناموں کو بالکل handle نہیں کرتا۔ اس لیے اگر tunnel کام کر رہا ہو لیکن lookups ناکام ہوں، تو اس کا مطلب ہے کہ جس resolver کی طرف آپ اشارہ کر رہے ہیں وہ جواب نہیں دے رہا۔ Client سے dig +short @10.8.0.1 example.com کے ذریعے test کریں۔ communication timed out کا جواب اس بات کی نشاندہی کرتا ہے کہ یا تو tunnel کے اس address پر کوئی resolver listening نہیں کر رہا، جو اکثر اس لیے ہوتا ہے کہ systemd-resolved stub صرف 127.0.0.53 پر bind ہے، یا server firewall، wg0 پر آنے والی UDP port 53 کی traffic drop کر رہا ہے۔ پہلے listener کو درست کریں، پھر صرف wg0 کے لیے port کھولیں۔

میں کیسے جانچوں کہ میرا DNS، WireGuard کے ذریعے leak ہو رہا ہے؟

Client پر sudo tcpdump -ni any -c 10 port 53 چلائیں اور browsing کے دوران interface column کو monitor کریں۔ Machine سے باہر جانے والا ہر packet wg0 پر ہونا چاہیے۔ lo پر 127.0.0.53 تک یا وہاں سے جانے والے packets مقامی systemd-resolved stub کے ہیں اور معمول کے مطابق ہیں۔ اگر packets آپ کے wireless یا ethernet interface پر نظر آئیں، تو queries cleartext میں باہر جا رہی ہیں۔ dig +short whoami.akamai.net دوسری تصدیق فراہم کرتا ہے، کیونکہ یہ اس recursive resolver کا public address دکھاتا ہے جس نے query بھیجی تھی۔ اس لیے اگر جواب آپ کے server کا address نہ ہو تو یہ leak کی تصدیق ہے۔

اگر میں split tunnel استعمال کرتا ہوں تو کیا DNS = line ضروری ہے؟

جی ہاں، اور resolver address بھی AllowedIPs کے اندر ہونا چاہیے، ورنہ client کے پاس اس تک پہنچنے کے لیے کوئی route نہیں ہوگا۔ AllowedIPs = 10.8.0.0/24 کے ساتھ 10.8.0.1 پر موجود resolver شامل ہو جاتا ہے اور query encrypted رہتی ہے۔ 9.9.9.9 جیسا public resolver شامل نہیں ہوتا، اس لیے query local link کے ذریعے باہر چلی جاتی ہے، اگرچہ DNS line درست دکھائی دیتی ہو۔

resolvectl درست server دکھاتا ہے، لیکن lookups پھر بھی کہیں اور کیوں جا رہے ہیں؟

systemd-resolved ایسے name کو، جو کسی routing domain سے match نہیں کرتا، تمام default-route links کو بیک وقت بھیجتا ہے، جس میں wg0 بھی شامل ہے، اور پہلی کامیاب response واپس کرتا ہے۔ یہ response عموماً local router کی طرف سے آتی ہے۔ Client کے [Interface] block میں PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. شامل کریں اور DNS = line ہٹا دیں۔ اس کے بعد resolvectl status wg0 کو DNS Domain: ~. report کرنا چاہیے، اور ہر وہ name جسے کوئی دوسرا link زیادہ specific domain کے ذریعے claim نہیں کرتا، صرف wg0 کو بھیجا جائے گا۔

متعدد clients خراب ہوں تو پہلے کس client کو درست کروں؟

ایک Linux client کو پہلے درست کریں، کیونکہ یہی واحد platform ہے جو mechanism دکھاتا ہے۔ resolvectl status اور tcpdump آپ کو بتاتے ہیں کہ کس resolver نے جواب دیا اور packet کس interface سے گزرا۔ Phone اور desktop apps انہی DNS اور AllowedIPs values کو استعمال کرتی ہیں، لیکن اندرونی configuration دکھائی نہیں دیتی۔ اس لیے جب Linux client درست ہو جائے تو آپ ایسی configuration copy کر رہے ہوں گے جسے پہلے ہی verify کیا جا چکا ہے۔