ਸਪਲਿਟ-ਟਨਲ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਹਰ ਰੂਟ ਦੇ ਨਾਲ DNS ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ
ਰੂਟ ਪਤੇ ਨਾਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਰਿਜ਼ਾਲਵਰ ਨਾਮ ਨਾਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਹਰ ਫਲੋ ਲਈ ਦੋਵੇਂ ਚੋਣਕਾਰ ਦਰਜ ਕਰੋ, ਹਰ ਇੱਕ ਨਾਲ ਇੱਕ ਟੈਸਟ, ਨਹੀਂ ਤਾਂ DNS ਬਦਲਣ 'ਤੇ ਨੋਟ ਫੇਲ ਹੋ ਜਾਵੇਗਾ।
"ਦਫ਼ਤਰੀ ਟ੍ਰੈਫਿਕ VPN ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ" ਆਖਣ ਵਾਲਾ ਸਪਲਿਟ-ਟਨਲ ਨੋਟ ਇੱਕ ਫੈਸਲਾ ਦਰਜ ਕਰ ਚੁੱਕਾ ਹੈ ਅਤੇ ਤਿੰਨ ਹੋਰ ਸੰਕੇਤ ਕੀਤੇ ਹਨ। ਪੈਕਟ ਪਰਤ 'ਤੇ ਰੂਟਿੰਗ ਸਾਰਣੀ ਮੰਜ਼ਿਲ ਪਤੇ ਨਾਲ ਇੰਟਰਫੇਸ ਚੁਣਦੀ ਹੈ; ਨਾਮ ਪਰਤ 'ਤੇ ਰਿਜ਼ਾਲਵਰ ਕਵੈਰੀ ਨਾਲ ਸਰਵਰ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਚੋਣਾਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਸੇ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਦਰਜ ਪ੍ਰੀਫਿਕਸ ਅਜੇ ਵੀ ਅਜਿਹੀ ਮਸ਼ੀਨ ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ ਅੰਦਰੂਨੀ ਨਾਮ ਨੂੰ ਜਨਤਕ ਪਤੇ ਵਿੱਚ ਹੱਲ ਕਰੇ, ਜਾਂ ਰੂਟ ਸੰਪੂਰਨ ਦਿਸਦਿਆਂ ਕੁਝ ਵੀ ਹੱਲ ਨਾ ਕਰੇ।
ਦੋ ਚੋਣਕਾਰ, ਇੱਕ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼
ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ files.corp.example ਨਾਲ ਜੁੜਦੀ ਹੈ, ਪੈਕਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਖੋਜਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਰਿਜ਼ਾਲਵਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਸਰਵਰ ਕਵੈਰੀ ਲਵੇਗਾ, ਖੋਜ ਡੋਮੇਨ, ਪ੍ਰਤੀ-ਲਿੰਕ ਰੂਟਿੰਗ ਡੋਮੇਨ ਜਾਂ ਸਪਸ਼ਟ ਪ੍ਰੋਫਾਈਲ ਨਿਯਮ ਵਰਤ ਕੇ। ਫਿਰ ਰੂਟਿੰਗ ਸਾਰਣੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਨਤੀਜਾ ਪਤਾ ਕਿੱਥੇ ਜਾਵੇਗਾ, ਮੰਜ਼ਿਲ ਨਾਲ ਸਭ ਤੋਂ ਲੰਬੇ ਪ੍ਰੀਫਿਕਸ ਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ।
ਉਹਨਾਂ ਦੋ ਫੈਸਲਿਆਂ ਨੂੰ ਕੋਈ ਵੀ ਨਹੀਂ ਜੋੜਦਾ। ਨਿੱਜੀ ਜ਼ੋਨ 10.20.4.11 ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਰੂਟਿੰਗ ਸਾਰਣੀ 10.20.0.0/16 ਟਨਲ ਵਿੱਚ ਭੇਜਦੀ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪਲਟੋ ਅਤੇ ਇਹ ਦੂਜੇ ਵਰਗਾ ਦਿਸਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ: ਸਹੀ DNS ਨੀਤੀ ਅਤੇ ਗੁੰਮ ਰੂਟ ਹੱਲ ਹੋਇਆ ਨਾਮ ਤੇ ਸਮਾਂ ਖਤਮ ਦਿੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸਹੀ ਰੂਟ ਅਤੇ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਸਾਫ਼-ਸੁਥਰੇ ਢੰਗ ਨਾਲ ਗਲਤ ਥਾਂ 'ਤੇ ਰੂਟ ਹੋਣ ਵਾਲਾ ਪਤਾ ਦਿੰਦੇ ਹਨ।
ਵੰਡਿਆ ਕਿਸ਼ਤੀਖਿਤਿਜ DNS ਇਸਨੂੰ ਹੋਰ ਤਿੱਖਾ ਕਰਦਾ ਹੈ। ਇੱਕੋ ਨਾਮ ਅੰਦਰੂਨੀ ਰਿਜ਼ਾਲਵਰ ਤੋਂ ਨਿੱਜੀ ਪਤਾ ਅਤੇ ਇੰਟਰਨੈੱਟ ਵੱਲ ਦੇ ਰਿਜ਼ਾਲਵਰ ਤੋਂ ਜਨਤਕ ਪਤਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਕੇਵਲ ਪ੍ਰੀਫਿਕਸ ਦਰਜ ਕਰਨ ਵਾਲਾ ਨੋਟ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪਤਾ ਵਰਤੇਗਾ। ਰਿਜ਼ਾਲਵਰ ਦਾ ਰਾਹ ਲਿਖੋ, ਨਹੀਂ ਤਾਂ ਪਤਾ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ।
ਕੇਵਲ-ਰੂਟ ਨੋਟ ਕੀ ਛੱਡ ਦਿੰਦਾ ਹੈ
ਕੇਵਲ-ਰੂਟ ਰਿਕਾਰਡ ਸਭ ਤੋਂ ਆਮ ਸਪਲਿਟ-ਟਨਲ ਫੇਲ ਲਈ ਬੇਕਾਰ ਹੈ: ਨਾਮ। ਵਰਤੋਂਕਾਰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ, ਟਨਲ ਚਾਲੂ ਹੈ, ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਮੌਜੂਦ ਹੈ। ਜੋ ਟਿਕਟ ਲੈਂਦਾ ਹੈ ਉਸ ਕੋਲ ਕਿਹੜੇ ਰਿਜ਼ਾਲਵਰ ਨੇ ਜਵਾਬ ਦੇਣਾ ਸੀ ਦਾ ਰਿਕਾਰਡ ਨਹੀਂ, ਗਲਤ ਖੋਜ ਪਿਛੇਤਰ ਨੂੰ ਬਲਾਕ ਕੀਤੇ ਸਰਵਰ ਤੋਂ ਵੱਖ ਪਛਾਣਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ, ਅਤੇ ਤੁਲਨਾ ਲਈ ਆਧਾਰ-ਰੇਖਾ ਨਹੀਂ।
ਦੂਜੀ ਛੱਡਣੀ ਅਪਵਾਦਾਂ ਦੀ ਸੂਚੀ ਹੈ। ਸਪਲਿਟ-ਟਨਲ ਡਿਜ਼ਾਈਨ ਉੱਨਾ ਹੀ ਇਸ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਟਨਲ ਤੋਂ ਬਾਹਰ ਕੀ ਰਹਿੰਦਾ ਹੈ, ਜਿੰਨਾ ਇਸ ਨਾਲ ਕਿ ਅੰਦਰ ਕੀ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਬਾਹਰ ਰੱਖੇ ਖੇਤਰ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਟੁੱਟਦੇ ਹਨ, ਕਿਉਂਕਿ ਵਧੇਰੇ ਖਾਸ ਸਥਾਨਕ ਰੂਟ ਜਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਦਾ ਫਿਲਟਰ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਇਰਾਦੇ ਨੂੰ ਪਲਟ ਸਕਦਾ ਹੈ।
ਤੀਜਾ ਟਨਲ ਦਾ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਹੈ। ਕਲਾਇੰਟ ਰੂਟ ਪੈਕਟ ਨੂੰ ਕੇਵਲ ਤਾਰ 'ਤੇ ਰੱਖਦਾ ਹੈ; ਗੇਟਵੇ ਨੂੰ ਅਜੇ ਵੀ ਇਸਨੂੰ ਅੱਗੇ ਭੇਜਣਾ ਹੈ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਰੱਖਣਾ ਹੈ। strongSwan ਦੀ ਅੱਗੇ ਭੇਜਣ ਦੀ ਗਾਈਡ ਯਾਦ ਦਿਵਾਉਂਦੀ ਹੈ ਕਿ ਗੇਟਵੇ 'ਤੇ ਅੱਗੇ ਭੇਜਣ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਹਿੱਸਾ ਹਨ, ਨਾ ਕਿ ਅਜਿਹੀ ਪਲੰਬਿੰਗ ਦਾ ਹਿੱਸਾ ਜਿਸਨੂੰ ਤੁਸੀਂ ਮੰਨ ਸਕਦੇ ਹੋ।
ਨੋਟ ਨੂੰ ਲਾਗੂਯੋਗ ਬਣਾਉਣ ਵਾਲੇ ਖੇਤਰ
ਹਰ ਫਲੋ ਲਈ ਇੱਕ ਕਤਾਰ, ਅਤੇ ਫਲੋ ਦਾ ਮਤਲਬ ਮੰਜ਼ਿਲ ਜੋੜ ਨਾਮ ਜੋੜ ਮਾਲਕ। ਅਸਲ ਘਟਨਾ ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਟਿਕਣ ਵਾਲੇ ਖੇਤਰ ਇਹ ਹਨ:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"ਇਹ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ" ਕਤਾਰ ਉਹ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਸਰਵਰ ਵੱਲੋਂ ਧੱਕਿਆ ਪ੍ਰੀਫਿਕਸ, ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵੱਲੋਂ ਜੋੜਿਆ ਰੂਟ ਅਤੇ ਸ਼ੈੱਲ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ ਰੂਟ ਇਸ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਕੌਣ ਇਹਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਟਿਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਉਹ ਖੇਤਰ ਨਾ ਹੋਣ 'ਤੇ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਵੇਖ ਰਿਹਾ ਹੈ।
ਹਰ ਨਿਯਮ ਲਈ ਇੱਕ ਟੈਸਟ, ਹਰ ਟਨਲ ਲਈ ਨਹੀਂ
ਹਰ ਕਤਾਰ ਨੂੰ ਦੋ ਨਿਰਦੋਸ਼ ਜਾਂਚਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕ ਰੂਟ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਨਾਮ ਦੀ। ਰੂਟ ਲਈ, ਉਹ ਚੀਜ਼ ਮੰਗੋ ਜੋ ਟਨਲ ਪਾਰ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਪਹੁੰਚ ਦੀ ਥਾਂ ਰਾਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਉਦਾਹਰਨ ਲਈ tracert -d 10.20.4.11 Windows 'ਤੇ ਜਾਂ ip route get 10.20.4.11 Linux 'ਤੇ। ਨਾਮ ਲਈ, ਨਿੱਜੀ ਨਾਮ ਦੀ ਕਵੈਰੀ ਕਰੋ ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਕਿਹੜੇ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਨੋਟ ਵੱਲੋਂ ਦੱਸੇ ਰਿਜ਼ਾਲਵਰ ਦੇ ਵਿਰੁੱਧ resolvectl query files.corp.example ਜਾਂ dig files.corp.example ਵਰਤ ਕੇ।
ਨਕਾਰਾਤਮਕ ਉਮੀਦ ਵੀ ਸ਼ਾਮਲ ਕਰੋ: ਜਦੋਂ ਟਨਲ ਬੰਦ ਹੈ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। VPN ਤੋਂ ਬਿਨਾਂ ਬਲਾਕ ਸਮਰੱਥ Android ਜਾਂ iOS ਡਿਵਾਈਸ 'ਤੇ ਬਾਹਰ ਰੱਖੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੋਈ ਕਨੈਕਟੀਵਿਟੀ ਹੀ ਨਾ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਡੈਸਕਟਾਪ ਕਲਾਇੰਟ ਉਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਟਨਲ ਮੁੜ ਜੁੜਦਿਆਂ ਚੱਲਦਾ ਰਹਿਣ ਦੇ ਸਕਦਾ ਹੈ। ਇਛਿਤ ਜਵਾਬ ਦਰਜ ਕਰਨਾ "VPN ਨੇ ਮੇਰੀ ਐਪ ਤੋੜ ਦਿੱਤੀ" ਨੂੰ ਜਾਂਚਯੋਗ ਬਿਆਨ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਰਿਕਾਰਡ ਨੂੰ ਸੰਰਚਨਾ ਨਾਲ ਰੱਖੋ
ਨੋਟ ਨੂੰ ਉਸ ਪ੍ਰੋਫਾਈਲ ਦੇ ਨਾਲ ਸੰਭਾਲੋ ਜਿਸਦਾ ਇਹ ਵਰਣਨ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਸੰਸਕਰਣ ਦਿਓ। ਵਿਕੀ ਵਿੱਚਲਾ ਦਸਤਾਵੇਜ਼ ਜਿਸਨੂੰ ਕੋਈ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰਦਾ, ਅਫਵਾਹ ਹੈ; ਧੱਕੇ ਗਏ ਰੂਟਾਂ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਨੀਤੀ ਵਾਲੇ ਉਸੇ ਭੰਡਾਰ ਵਿੱਚਲੀ ਸਾਰਣੀ ਉਸੇ ਬਦਲਾਅ ਵਿੱਚ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਹੋਰ ਅਪਵਾਦ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤੇ ਰੂਟ ਅਤੇ ਪ੍ਰਭਾਵੀ ਰਿਜ਼ਾਲਵਰ ਦੀ ਰਿਕਾਰਡ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਤਿੰਨ ਆਮ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਦੋ — ਪੁਰਾਣਾ ਨਾਮਸਥਾਨ ਨਿਯਮ ਅਤੇ ਐਪ ਨੀਤੀ ਤੋਂ ਬਾਹਰਲੀ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ — ਬਿਲਕੁਲ VPN ਖਰਾਬੀ ਵਰਗੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਜੇ ਨੋਟ ਕੇਵਲ ਪ੍ਰੀਫਿਕਸ ਗਿਣਾਵੇ ਤਾਂ ਅਦਿੱਖ ਰਹਿੰਦੇ ਹਨ।
ਨੋਟ ਨੂੰ ਪੂਰਾ ਆਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਇਹਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕਿਹੜਾ ਪ੍ਰੀਫਿਕਸ, ਕਿਹੜੇ ਪਤਾ ਪਰਿਵਾਰ ਲਈ; ਕਿਹੜਾ ਨਿੱਜੀ ਨਾਮਸਥਾਨ, ਕਿਹੜੇ ਰਿਜ਼ਾਲਵਰ ਵੱਲੋਂ ਜਵਾਬ; ਕਿਹੜੇ ਨਾਮ ਜਾਣ-ਬੁੱਝ ਕੇ ਜਨਤਕ ਰਹਿੰਦੇ ਹਨ; ਹਰ ਨਿਯਮ ਕਿੱਥੇ ਸੰਰਚਿਤ ਹੈ ਅਤੇ ਇਸਦਾ ਮਾਲਕ ਕੌਣ ਹੈ; ਅਤੇ ਇੱਕ ਹੁਕਮ ਜੋ ਰੂਟ ਸਿੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਨਾਮ ਸਿੱਧ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਅਗਲੀ ਘਟਨਾ ਦਾ ਨਿਦਾਨ ਸਿਫ਼ਰ ਤੋਂ ਕੀਤਾ ਜਾਵੇਗਾ।