ਤੁਸੀਂ /etc/ppp/ip-up ਵਿੱਚ route ਹੁਕਮ ਰੱਖਦੇ ਹੋ, ਦਫ਼ਤਰ ਦਾ ਟਨਲ ਦੁਬਾਰਾ ਜੋੜਦੇ ਹੋ, ਅਤੇ ਫ਼ਾਈਲ ਕਦੇ ਨਹੀਂ ਚੱਲਦੀ। ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਕੋਈ ਗੜਬੜ ਨਹੀਂ: ਉਹ ਕਨੈਕਸ਼ਨ PPP ਵਿੱਚੋਂ ਹੀ ਨਹੀਂ ਲੰਘਦਾ। ਅੰਦਰੂਨੀ Cisco IPSec ਅਤੇ IKEv2 ਕਲਾਇੰਟ ਕਦੇ ਵੀ pppd ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਹੁੱਕ ਡਾਇਰੈਕਟਰੀ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹੀ ਜਾਂਦੀ, ਜਦੋਂ ਕਿ PPTP ਅਤੇ IPSec ਉੱਤੇ L2TP ਅਜੇ ਵੀ ਇਸ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ। ਪਤਾ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਕਿਹੜੀ ਸਥਿਤੀ ਹੈ, ਫਿਰ ਗ਼ੈਰ-PPP ਸਥਿਤੀ ਨੂੰ launchd ਨਿਗਰਾਨੀ ਕੰਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।

ਕੋਈ ਵੀ ਹੁੱਕ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇੰਟਰਫ਼ੇਸ ਜਾਂਚੋ

ਦੋ ਹੁਕਮ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਵਿਧੀ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ। ਕਾਨਫ਼ਿਗਰ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਫਿਰ ਟਨਲ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਮੌਜੂਦ ਇੰਟਰਫ਼ੇਸਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਹੀ ਸਬੂਤ ਹੈ; System Settings ਦਾ ਲੇਬਲ ਨਹੀਂ।

scutil --nc list
ifconfig -l | tr ' ' '\n' | grep -E '^(utun|ppp)[0-9]+$'

ppp0 ਪੈਦਾ ਕਰਨ ਵਾਲੀ ਸੇਵਾ PPP ਹੁੱਕ ਚਲਾਉਂਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਫ਼ਾਈਲ ਚਲਾਏਗੀ। Cisco IPSec ਜਾਂ IKEv2 ਸੇਵਾ ਇਸ ਦੀ ਥਾਂ utun ਡਿਵਾਈਸ ਪੈਦਾ ਕਰਦੀ ਹੈ, PPP ਪਰਤ ਤੋਂ ਬਿਨਾਂ ਟਨਲ ਇੰਟਰਫ਼ੇਸ, ਇਸ ਲਈ /etc/ppp ਦੇ ਅੰਦਰ ਕੋਈ ਚੀਜ਼ ਉਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀ। ਜਦੋਂ ਦੋਵੇਂ ਕਿਸਮਾਂ ਦਿਸਣ, ਜਾਂਚੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਸੇਵਾ ਨਾਲ ਜੁੜੇ ਸੀ। ਲੋਕ ਕਲਾਇੰਟ ਦਾ ਨਾਮ ਪੜ੍ਹ ਕੇ ਗ਼ਲਤ ਹੁੱਕ ਉੱਤੇ ਦੁਪਹਿਰ ਗੁਆ ਦਿੰਦੇ ਹਨ।

PPP ਮਾਰਗ ਉੱਤੇ ਫ਼ਾਈਲ root ਦੀ ਮਾਲਕੀ ਵਿੱਚ ਅਤੇ ਚੱਲਣਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ pppd ਕੁਝ ਵੀ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਜਾਂਚਦਾ ਹੈ। install ਇੱਕ ਹੀ ਕਦਮ ਵਿੱਚ ਮਾਲਕ ਅਤੇ ਮੋਡ ਸੈੱਟ ਕਰਦਾ ਹੈ।

sudo install -o root -g wheel -m 0755 /dev/null /etc/ppp/ip-up
sudo ls -l /etc/ppp/ip-up

Finder ਜਾਂ ਗ੍ਰਾਫ਼ਿਕਲ ਐਡੀਟਰ ਰਾਹੀਂ ਬਣੀ ਫ਼ਾਈਲ ਅਕਸਰ ਤੁਹਾਡੇ ਖਾਤੇ ਦੀ ਮਾਲਕੀ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਉਸ ਵਿੱਚ ਚੱਲਣ ਬਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਫਿਰ ਗੁੰਮ ਹੁੱਕ ਵਾਂਗ ਹੀ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਹੁਣ ਉਸ ਦੇ ਕੋਲ ip-down ਰੱਖੋ। ਮਾਲਕ ਕਾਲਮ ਵਿੱਚ root ਅਤੇ wheel ਤੇ ਮੋਡ ਕਾਲਮ ਵਿੱਚ rwxr-xr-x ਉਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।

ਟਨਲ ਦਿਸਣ ਵੇਲੇ launchd ਨੂੰ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਦਿਓ

ਜੋ ਕਲਾਇੰਟ PPP ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂਹਦੇ, ਉਨ੍ਹਾਂ ਲਈ ਟ੍ਰਿਗਰ ਕਿਤੇ ਹੋਰੋਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਸਟੋਰ ਹੀ ਇਮਾਨਦਾਰ ਸਰੋਤ ਹੈ: macOS ਹਰ ਟਨਲ ਤਬਦੀਲੀ ਉੱਤੇ ਇਸ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ। ਉਸ ਡਾਇਰੈਕਟਰੀ ਵੱਲ ਧਿਆਨ ਰੱਖਣ ਵਾਲਾ launchd ਕੰਮ ਟਨਲ ਦਿਸਣ ਜਾਂ ਗ਼ਾਇਬ ਹੋਣ ਵੇਲੇ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ।

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>WatchPaths</key>
  <array><string>/Library/Preferences/SystemConfiguration</string></array>
  <key>Label</key><string>net.example.tunnel-watch</string>
  <key>ProgramArguments</key>
  <array><string>/bin/sh</string><string>/usr/local/sbin/tunnel-hook</string></array>
  <key>RunAtLoad</key><true/>
  <key>ThrottleInterval</key><integer>20</integer>
</dict>
</plist>

ਇਸ ਨੂੰ launch daemon ਵਜੋਂ ਸਥਾਪਿਤ ਕਰੋ, ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ ਏਜੰਟ ਵਜੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਮਾਰਗ ਮੁਰੰਮਤ ਮਸ਼ੀਨ ਦੀ ਹੈ। bootstrap ਮੌਜੂਦਾ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਪੁਰਾਣਾ load -w ਰੂਪ ਬਦਲਦਾ ਹੈ। RunAtLoad ਪਹਿਲੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਦੇਖਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ThrottleInterval Wi-Fi ਜੁੜਨ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਲਹਿਰ ਨੂੰ ਸਕ੍ਰਿਪਟ ਵਾਰ-ਵਾਰ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

sudo install -o root -g wheel -m 0644 tunnel-watch.plist \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist
sudo launchctl bootstrap system \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist

ਜਾਲ ਇਹ ਹੈ ਕਿ ਨਿਗਰਾਨੀ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਤੁਹਾਡੇ VPN ਨਾਲ ਸੰਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਉੱਤੇ ਵੀ ਬਦਲਦੀ ਹੈ: Wi-Fi ਜੁੜਨਾ, DHCP ਨਵੀਨੀਕਰਨ, ਕੇਬਲ ਲੱਗਣਾ। ਹੇਠਾਂ ਦਿੱਤਾ ਪਹਿਰੇਦਾਰ ਸ਼ੋਰ ਭਰੇ ਟ੍ਰਿਗਰ ਨੂੰ ਕੰਮ ਦੇ ਹੁੱਕ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਲਾਗ ਦੀ ਇੱਕ ਲਾਈਨ ਅਜੀਬ ਸਮੇਂ ਦੇ ਮਾਰਗ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।

ਮਾਲਕੀ ਸਕ੍ਰਿਪਟ ਦੇ ਨਾਲ plist ਨੂੰ ਵੀ ਕਵਰ ਕਰਦੀ ਹੈ। ਜੋ ਡੈਮਨ ਅਜਿਹੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਫ਼ਾਈਲ ਚਲਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਆਪਣਾ ਖਾਤਾ ਲਿਖ ਸਕਦਾ ਹੈ, ਉਹ ਉਸ ਖਾਤੇ ਨੂੰ root ਦੇ ਦਿੰਦਾ ਹੈ।

ਸਕ੍ਰਿਪਟ ਦੀ ਰੱਖਿਆ ਕਰੋ ਤਾਂ ਜੋ ਦੂਜੀ ਵਾਰ ਚੱਲਣ ਨਾਲ ਕੁਝ ਨਾ ਬਦਲੇ

ਸਕ੍ਰਿਪਟ ਪਹਿਲਾਂ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਟਨਲ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਨਾ ਹੋਣ ਉੱਤੇ ਚੁੱਪਚਾਪ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦੀ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਦੁਹਰਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਟ੍ਰਿਗਰ ਇੱਕ ਕਨੈਕਸ਼ਨ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਵਾਰ ਚੱਲਦਾ ਹੈ। ਅਗਲੇ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਬਦਲਣ ਵਾਲੇ ਇੰਡੈਕਸ ਨੂੰ ਹਾਰਡਕੋਡ ਕਰਨ ਦੀ ਥਾਂ ਰਨਟਾਈਮ ਉੱਤੇ ਇੰਟਰਫ਼ੇਸ ਹੱਲ ਕਰੋ।

#!/bin/sh
set -u
TUN=$(ifconfig -l | tr ' ' '\n' | grep -m1 '^utun[0-9]' || true)
[ -n "$TUN" ] || exit 0
netstat -rn -f inet | grep -q '^10\.42' && exit 0
route -n add -net 10.42.0.0/16 -interface "$TUN"

route add ਮਾਰਗ ਪਹਿਲਾਂ ਹੀ ਹੋਣ ਉੱਤੇ ਗ਼ੈਰ-ਸਿਫ਼ਰ ਸਥਿਤੀ ਨਾਲ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਗ਼ੈਰ-ਸਿਫ਼ਰ ਸਥਿਤੀ ਨੂੰ ਫੇਲ੍ਹ ਮੰਨਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਸਹੀ ਕੰਮ ਕਰਦਿਆਂ ਵੀ ਹਰ ਵਾਰ ਟੁੱਟੇ ਹੁੱਕ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ। ਉੱਪਰਲਾ netstat ਟੈਸਟ ਉਸ ਸਥਿਤੀ ਨੂੰ ਸਪਸ਼ਟ no-op ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਇੰਟਰਫ਼ੇਸ ਦੀ ਮੌਜੂਦਗੀ ਦਿਸਣ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਸਬੂਤ ਹੈ, ਕਿਉਂਕਿ ਹੋਰ VPN ਕਲਾਇੰਟ ਅਤੇ ਕੁਝ ਕੰਟੇਨਰ ਵਾਤਾਵਰਣ ਵੀ utun ਡਿਵਾਈਸ ਬਣਾਉਂਦੇ ਹਨ। scutil --nc status "Office VPN" ਨਾਲ ਸੇਵਾ ਨੂੰ ਹੀ ਪੁੱਛੋ ਅਤੇ ਰਾਊਟਿੰਗ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜੁੜੀ ਸਥਿਤੀ ਮੰਗੋ। ਜਵਾਬ ਲਾਗ ਦੀ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਉਹੀ ਰਿਕਾਰਡ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕੋ-ਇੱਕ ਵਿਆਖਿਆ ਹੋਵੇਗਾ।

DNS ਤੋੜੇ ਬਿਨਾਂ ਗੇਟਵੇ ਵਾਪਸ ਲਿਆਓ

ਜਦੋਂ ਟਨਲ ਡਿਫ਼ਾਲਟ ਮਾਰਗ ਲੈ ਲੈਂਦਾ ਹੈ, ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦਫ਼ਤਰ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਥਾਨਕ ਇੰਟਰਨੈਟ ਮਾਰਗ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਦਾ ਰਾਊਟਰ ਫੜੋ, ਫਿਰ ਡਿਫ਼ਾਲਟ ਨੂੰ ਮੁੜ ਉਸ ਵੱਲ ਮੋੜੋ। DHCP ਉਸ ਸਾਰਣੀ ਨੂੰ ਪਾਰਸ ਕਰਨ ਨਾਲੋਂ ਵਧੀਆ ਹੈ ਜਿਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਟਨਲ ਦਾ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਹੈ।

PHYS=en0
GW=$(ipconfig getoption "$PHYS" router)
[ -n "$GW" ] && sudo route -n change default "$GW"

ਰਿਜ਼ੌਲਵਰ ਲਈ ਵੱਖਰੇ ਸਾਧਨ ਵਾਲੀ ਵੱਖਰੀ ਪਰਤ ਹਨ, ਅਤੇ ਮਾਰਗ ਦੀ ਮੁਰੰਮਤ ਉਨ੍ਹਾਂ ਦੀ ਨਹੀਂ ਹੁੰਦੀ। scutil --dns ਨਾਲ ਵੇਖੋ ਕਿ ਕੀ ਲਾਗੂ ਹੈ, ਫਿਰ ਜੋ ਇਹ ਪੈਦਾ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਸੋਧੋ: ਸੇਵਾਵਾਂ ਦਾ ਕ੍ਰਮ ਅਤੇ ਭੌਤਿਕ ਸੇਵਾ ਉੱਤੇ DNS ਐਂਟਰੀਆਂ। ਕੈਸ਼ ਖਾਲੀ ਕਰਨਾ ਨੈੱਟਵਰਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਅਟਕੀ ਖੋਜ ਦਾ ਨਿਦਾਨ ਕਰਦਾ ਹੈ; ਇਹ ਤਹਿ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ।

Wi-Fi ਤਬਦੀਲੀ ਸਹਿੰਦਾ ਪਰ DNS ਅਟਕਦਾ ਟਨਲ ਤੀਜਾ ਨੁਕਸ ਹੈ: sudo killall -HUP mDNSResponder ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਇਸ ਦੀ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਮੁੜ ਪੜ੍ਹਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ, ਹੱਥ ਨਾਲ ਵਰਤੋ।

ਸਾਬਤ ਕਰੋ ਕਿ ਕੰਮ ਆਪਣੇ ਆਪ ਚੱਲਦਾ ਹੈ

ਨਿਗਰਾਨੀ ਮਾਰਗ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ kickstart -k ਨਾਲ ਇੱਕ ਚਾਲ ਜ਼ਬਰਦਸਤੀ ਕਰੋ, ਫਿਰ ਕੰਮ ਵੱਲੋਂ ਦਰਜ ਕੀਤੀ ਨਿਕਾਸ ਸਥਿਤੀ ਪੜ੍ਹੋ। ਸਾਫ਼ ਨਿਕਾਸ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟ ਕੰਮ ਕਰਦੀ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਟ੍ਰਿਗਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਿਰ ਕੰਮ ਲੋਡ ਹੋਣ ਵੇਲੇ ਡਿਸਕਨੈਕਟ ਅਤੇ ਦੁਬਾਰਾ ਜੁੜੋ, ਅਤੇ ਤੁਸੀਂ ਨਾ ਮੰਗੀ ਚਾਲ ਵੱਲ ਧਿਆਨ ਦਿਓ।

sudo launchctl kickstart -k system/net.example.tunnel-watch
sudo launchctl print system/net.example.tunnel-watch | grep -E 'last exit code|state ='

ਹਰ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ scutil --nc status ਜਾਂਚੋ। ਟਨਲ ਬੰਦ ਹੁੰਦਿਆਂ ਚੱਲੀ ਸਕ੍ਰਿਪਟ ਕਨੈਕਸ਼ਨ ਮਾਰਗ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।

ਤੋੜਨ ਵਾਲੀ ਸ਼ਾਖਾ ਵੀ ਜੋੜਨ ਵਾਲੀ ਸ਼ਾਖਾ ਵਾਂਗ ਹੀ ਸੰਭਾਲ ਦੀ ਹੱਕਦਾਰ ਹੈ: ਮਾਰਗ ਹੱਥ ਨਾਲ ਹਟਾਓ, ਕੰਮ ਚੱਲਣ ਦਿਓ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਜੋ ਹੁੱਕ ਮਾਰਗ ਜੋੜਦਾ ਹੈ ਅਤੇ ਕਦੇ ਨਹੀਂ ਹਟਾਉਂਦਾ, ਉਹ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਗ਼ਲਤ ਵਿਵਹਾਰ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਛੱਡ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੋ ਘਟਨਾਵਾਂ ਨੂੰ ਕੁਝ ਨਹੀਂ ਜੋੜਦਾ। ਜਦੋਂ ਦੋਵੇਂ ਵਿਵਹਾਰ ਟਿਕੇ ਰਹਿਣ, sudo launchctl bootout system/net.example.tunnel-watch ਕੰਮ ਨੂੰ ਸਾਫ਼ ਢੰਗ ਨਾਲ ਸੇਵਾਮੁਕਤ ਕਰਦਾ ਹੈ। ਲੋਡ ਕੀਤਾ ਛੱਡਿਆ ਨਿਗਰਾਨੀ ਡੈਮਨ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਇੱਕ-ਵਾਰੀ ਮੁਰੰਮਤ ਕਈ ਮਹੀਨਿਆਂ ਬਾਅਦ ਬਿਨਾਂ ਵਿਆਖਿਆ ਵਾਲਾ ਮਾਰਗ ਬਣ ਜਾਂਦੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ