VPN ਪਤਾ ਥਾਂ ਹੰਡਾਈ ਮੁਤਾਬਕ ਚੁਣੋ, ਧੁੰਦਲਾਪਣ ਮੁਤਾਬਕ ਨਹੀਂ
ਬੈਂਚਮਾਰਕ, ਸਾਂਝੇ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਰੇਂਜਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਾ ਮਾਲਕ ਅਤੇ ਉਦੇਸ਼ ਹੈ। ਰਜਿਸਟਰੀ ਤੋਂ VPN ਥਾਂ ਚੁਣੋ, ਫਿਰ ਉਸ ਓਵਰਲੈਪ ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਹਟਾ ਨਹੀਂ ਸਕਦੇ।
ਅਜੀਬ ਦਿਸਣ ਵਾਲਾ ਪ੍ਰੀਫਿਕਸ ਘਰ ਅਤੇ ਦਫ਼ਤਰ ਦੇ ਪਤਾ ਟਕਰਾਅ ਤੋਂ ਬਚ ਨਿਕਲਣ ਦਾ ਰਾਹ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਨਹੀਂ। IPv4 ਖ਼ਾਸ ਮਕਸਦ ਰਜਿਸਟਰੀ ਵਿੱਚ ਹਰ ਬਲਾਕ ਦਾ ਇੱਕ ਮਾਲਕ, ਇੱਕ ਉਦੇਸ਼ ਅਤੇ ਇਸ ਦੇ ਹੋਣ ਦਾ ਕਾਰਨ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਇਸ ਲਈ ਉਧਾਰ ਲੈਣਾ ਕਿ ਇਹ ਸ਼ਾਂਤ ਦਿਸਦਾ ਹੈ ਟਕਰਾਅ ਨੂੰ ਹਟਾਉਣ ਦੀ ਬਜਾਏ ਉਸ ਨੂੰ ਥਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਕ੍ਰਮ ਵਜੋਂ ਚਲਾਓ: ਹੰਡਾਈ ਪੜ੍ਹੋ, ਪਹਿਲਾਂ ਹੀ ਓਵਰਲੈਪ ਹੋ ਰਹੇ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਮੁੜ-ਨੰਬਰੀ ਕਰ ਰਹੇ ਹੋ, ਅਨੁਵਾਦ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਨਵੀਂ ਥਾਂ ਬਣਾ ਰਹੇ ਹੋ। ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਤੀਜਾ ਕਦਮ ਪਹਿਲੇ ਦੋ ਨੇ ਕੀ ਲੱਭਿਆ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਰੇਂਜ ਉਧਾਰ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਹੰਡਾਈ ਪੜ੍ਹੋ
IANA ਦੀ ਖ਼ਾਸ ਮਕਸਦ ਰਜਿਸਟਰੀ ਮੁੜ-ਵਰਤੋਂ ਯੋਗ ਨਿੱਜੀ ਥਾਂ ਵਾਲੀਆਂ ਰੇਂਜਾਂ ਨੂੰ ਇੱਕ ਖ਼ਾਸ ਤਕਨੀਕੀ ਮਕਸਦ ਪੂਰਾ ਕਰਨ ਵਾਲੀਆਂ ਰੇਂਜਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਨਿੱਜੀ ਵਰਤੋਂ, ਸਾਂਝੀ ਪਤਾ ਥਾਂ, ਬੈਂਚਮਾਰਕ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਲਾਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਰੂਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬਿਲਕੁਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ।
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
ਸਿਰਫ਼ ਦੂਜੇ ਆਕਟੈਟ ਵਿੱਚ ਵੱਖਰੇ ਦੋ ਪ੍ਰੀਫਿਕਸ ਇੱਕੋ ਬਲਾਕ ਨਹੀਂ ਹਨ: 198.18.0.0/15 ਬੈਂਚਮਾਰਕ ਰਾਖਵਾਂ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ 192.18.0.0/16 ਅਜਿਹਾ ਕੁਝ ਨਹੀਂ ਰੱਖਦਾ। ਸਿਰਫ਼ ਰਾਖਵੀਂ ਰੇਂਜ ਵਰਗਾ ਦਿਸਣ ਵਾਲਾ ਅੰਕ ਉਸ ਦਾ ਅਰਥ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਪਾਉਂਦਾ। ਇਹ ਉਲਝਣ ਫਾਇਰਵਾਲ ਨਿਯਮ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੀ ਨਜ਼ਰ ਦੇ ਯੋਗ ਹੋਣ ਜਿੰਨੀ ਆਮ ਹੈ।
ਉਤਪਾਦ ਕਈ ਵਾਰ ਤਾਲਮੇਲ ਵਾਲੇ ਓਵਰਲੇ ਅੰਦਰ ਖ਼ਾਸ ਰੇਂਜ ਜਾਣ-ਬੁੱਝ ਕੇ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਹ ਉਨ੍ਹਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰਨ ਯੋਗ ਡਿਜ਼ਾਈਨ ਹੈ। ਇਸ ਨਾਲ ਉਹੀ ਰੇਂਜ ਕਿਸੇ ਅਸੰਬੰਧਿਤ LAN ਲਈ ਖਾਲੀ ਥਾਂ ਨਹੀਂ ਬਣ ਜਾਂਦੀ। ਜਨਤਕ ਥਾਂ ਵੀ ਲੁਕਣ ਦੀ ਥਾਂ ਨਹੀਂ ਹੈ: ਕਿਸੇ ਹੋਰ ਦੇ ਪਤੇ ਵੱਲ ਨਿੱਜੀ ਰਸਤਾ ਉਸ ਦੇ ਕਾਨੂੰਨੀ ਮੰਜ਼ਿਲ ਲਈ ਭੇਜੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਮੋੜ ਦਿੰਦਾ ਹੈ।
ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਓਵਰਲੈਪਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ
ਪ੍ਰੀਫਿਕਸ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਉਸ ਨੈੱਟਵਰਕ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜੋ ਸੁਰੰਗ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਵੇਗਾ। ਸਾਈਟਾਂ, ਕਲਾਇੰਟ ਪੂਲ, ਕਲਾਊਡ VPC ਅਤੇ ਭਾਈਵਾਲ ਲਿੰਕ ਸਾਰੇ ਗਿਣੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਪਹਿਲੀ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਫੇਲ੍ਹ ਹੋਣ ਤੱਕ ਲੋਕ ਜਿਸ ਨੂੰ ਭੁੱਲਦੇ ਹਨ ਉਹ ਭਾਈਵਾਲ ਲਿੰਕ ਹੀ ਹੈ।
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
ਨਤੀਜਿਆਂ ਨੂੰ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਹਰ ਰੇਂਜ ਦੇ ਮਾਲਕ ਨਾਲ ਬਾਜ਼ੂ ਰੱਖੋ। ਜਿਸ ਰੇਂਜ ਦਾ ਮਾਲਕ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਉਹ ਰੇਂਜ ਬਾਅਦ ਵਿੱਚ ਮੁੜ-ਨੰਬਰੀ ਨਹੀਂ ਕਰ ਸਕੋਗੇ, ਅਤੇ «ਅਜੀਬ» ਪ੍ਰੀਫਿਕਸਾਂ ਬਾਰੇ ਬਹਿਸ ਨੂੰ ਠੋਸ ਅੰਕਾਂ ਬਾਰੇ ਫ਼ੈਸਲੇ ਵਿੱਚ ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ ਇਹੀ ਸੂਚੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਦੱਸਦੀ ਹੈ ਕਿ ਜਿਸ ਟਕਰਾਅ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਅਸਲੀ ਹੈ ਜਾਂ ਕਾਲਪਨਿਕ।
ਜੇ ਦੂਰਲੇ ਕਰਮਚਾਰੀ ਦਾ ਘਰੇਲੂ ਨੈੱਟਵਰਕ ਦਫ਼ਤਰ ਦੇ LAN ਵਾਂਗ ਹੀ ਪ੍ਰੀਫਿਕਸ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਉਹ ਟਕਰਾਅ ਸੂਚੀ ਵਿੱਚ ਦਿਸਦਾ ਹੈ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਬੈਂਚਮਾਰਕ ਬਲਾਕ ਸਿਆਣਾ ਚੋਣ ਹੋਵੇਗਾ, ਅਤੇ ਇਸ ਨੂੰ ਇੰਝ ਲੈਣਾ ਹੀ ਅਗਲੀ ਟੱਕਰ ਪੈਦਾ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ।
ਪ੍ਰੀਫਿਕਸ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਵਿਲੱਖਣ ULA ਬਣਾਓ
IPv6 ਮੁੜ-ਵਰਤੋਂ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਵਧੇਰੇ ਸੋਹਣੇ ਅੰਕ ਦੀ ਬਜਾਏ ਵੱਖਰੀ ਕਾਰਜ-ਵਿਧੀ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ। RFC 4193 ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਅਲਾਟ ਕੀਤੇ ਵਿਲੱਖਣ ਸਥਾਨਕ ਪਤਿਆਂ ਨੂੰ ਸਿਊਡੋ-ਰੈਂਡਮ 40-bit ਵਿਸ਼ਵਵਿਆਪੀ ਪਛਾਣਕਰਤਾ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਸਾਈਟ /48 ਦਿੰਦਾ ਹੈ ਜਿਸ ਦਾ ਕਿਸੇ ਹੋਰ ਨਾਲ ਟਕਰਾਉਣ ਦੀ ਸੰਭਾਵਨਾ ਬਹੁਤ ਘੱਟ ਹੈ। ਸੰਭਾਵਨਾ ਉੱਚੀ ਹੈ, ਪੂਰਨ ਨਹੀਂ, ਅਤੇ ULA ਪ੍ਰੀਫਿਕਸ ਅਜੇ ਵੀ ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦਾ।
openssl rand -hex 5
ਦਸ ਹੈਕਸਾਡੈਸੀਮਲ ਅੰਕ ਚਾਲੀ ਬਿੱਟ ਹਨ। ਉਨ੍ਹਾਂ ਅੱਗੇ fd ਲਾਓ ਅਤੇ /48 ਵਿੱਚ ਸਮੂਹ ਬਣਾਓ: 3f9c1a7b02 ਦਾ ਆਉਟਪੁੱਟ fd3f:9c1a:7b02::/48 ਬਣਦਾ ਹੈ। ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਬਣਾਓ ਅਤੇ ਦਰਜ ਕਰੋ, ਹਰ ਤੈਨਾਤੀ ਵਿੱਚ ਉਹੀ ਸੁਵਿਧਾਜਨਕ fd00::/48 ਚਿਪਕਾਉਣ ਦੀ ਬਜਾਏ।
ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੂਰਾ ਰਾਹ ਸੱਚਮੁੱਚ IPv6 ਬੋਲਦਾ ਹੈ। ਕਲਾਇੰਟ, ਗੇਟਵੇ, ਰਸਤੇ, ਨਿੱਜੀ DNS ਅਤੇ ਸੇਵਾ ਨੀਤੀ ਸਾਰਿਆਂ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਦੇਣ ਨਾਲ ਸਿਰਫ਼ IPv4 ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਨੂੰ ਵਰਤਣ ਲੱਗਦੀ ਨਹੀਂ।
ਉਸ ਓਵਰਲੈਪ ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਹਟਾ ਨਹੀਂ ਸਕਦੇ
ਕੁਝ ਓਵਰਲੈਪ ਸਥਾਈ ਹੁੰਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਕਿਉਂਕਿ ਭਾਈਵਾਲ ਮੁੜ-ਨੰਬਰੀ ਨਹੀਂ ਕਰੇਗਾ ਅਤੇ ਤੁਸੀਂ ਉਸ ਨੂੰ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਤਦ ਤੁਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਸਮਰਥਿਤ ਕਾਰਜ-ਵਿਧੀ ਚੁਣਦੇ ਹੋ: ਆਪਣੇ ਪਾਸੇ ਮੁੜ-ਨੰਬਰੀ, ਵੱਖਰਾ ਰੂਟਿੰਗ ਸੰਦਰਭ, ਜਾਂ ਸੀਮਾ 'ਤੇ ਸਪਸ਼ਟ ਅਨੁਵਾਦ। ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣਨ ਦਾ ਅਰਥ ਹੈ ਲਿਖਣਾ ਕਿ ਕਿਹੜਾ ਚੁਣਿਆ ਅਤੇ ਬਾਕੀ ਦੋ ਕਿਉਂ ਰੱਦ ਕੀਤੇ ਗਏ। ਉਹੀ ਨੋਟ ਭਵਿੱਖ ਦੀ ਤਬਦੀਲੀ ਸਮੀਖਿਆ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹੇਗੀ।
ਅਨੁਵਾਦ ਨੂੰ ਵਾਪਸੀ ਰਾਹ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ ਅਸਲ ਅਤੇ ਪੇਸ਼ ਕੀਤੇ ਦੋਵੇਂ ਪ੍ਰੀਫਿਕਸ ਦਰਜ ਕਰਕੇ ਉਨ੍ਹਾਂ ਵਿੱਚ ਹੱਲ ਹੋਣ ਵਾਲੇ ਨਿੱਜੀ DNS ਨਾਵਾਂ ਨਾਲ ਮਿਲਾਉਣਾ। ਮੈਪ ਕੀਤਾ ਉਪਨਾਮ ਇੱਕ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਪਸ਼ਟ ਕਰ ਸਕਦਾ ਹੈ; ਇਹ ਅਸਲ ਪਤਿਆਂ ਨੂੰ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਵਿਲੱਖਣ ਨਹੀਂ ਬਣਾਉਂਦਾ ਅਤੇ ਦੂਜੇ ਮੈਪਿੰਗ ਤੋਂ ਬਿਨਾਂ ਦੂਜੇ ਓਵਰਲੈਪਿੰਗ ਭਾਈਵਾਲ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰ ਸਕੇਗਾ।
ਹੰਡਾਈ ਨੂੰ ਉਸ ਦੇ ਛੋਟ ਨਾਲ ਲਿਖੋ
ਹਰ ਪ੍ਰੀਫਿਕਸ, ਉਸ ਦੀ ਸ਼੍ਰੇਣੀ, ਉਸ ਦਾ ਮਾਲਕ ਅਤੇ ਚੋਣ ਦਾ ਕਾਰਨ ਦੱਸਣ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਸਮਾਪਤ ਕਰੋ। ਛੋਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਅਨੁਵਾਦ ਜਾਂ ਮੁੜ-ਨੰਬਰੀ ਨਿਯਮ ਅਤੇ ਕਿਸੇ ਵੱਲੋਂ ਮਨਜ਼ੂਰੀ ਦੀ ਤਾਰੀਖ ਨਾਲ ਜੋੜੋ। ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੇ ਕੋਲ ਰੱਖੋ, ਨਾ ਕਿ ਅਜਿਹੀ ਵਿਕੀ ਵਿੱਚ ਜੋ ਘਟਨਾ ਵੇਲੇ ਕੋਈ ਨਹੀਂ ਖੋਲ੍ਹਦਾ। ਦਸਤਾਵੇਜ਼ ਹੀ ਡਿਲੀਵਰੇਬਲ ਹੈ, ਉਸ ਦਾ ਸਾਰ ਨਹੀਂ।
ਉਹੀ ਰਿਕਾਰਡ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਹੋਰ ਅਜੀਬ ਦਿਸਣ ਵਾਲਾ ਅੰਕ ਲੱਭਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਮੱਸਿਆ ਹਰ ਕੁਝ ਸਾਲਾਂ ਬਾਅਦ ਨਵੇਂ ਨਾਮ ਹੇਠ ਮੁੜ ਲੱਭਣ ਦਾ ਤਰੀਕਾ ਵੀ ਇਹੋ ਹੈ। ਇਹ ਤਬਦੀਲੀ ਸਮੀਖਿਆ ਨੂੰ ਪ੍ਰੀਫਿਕਸਾਂ ਬਾਰੇ ਰਾਏ ਦੀ ਬਜਾਏ ਮਨਜ਼ੂਰੀ ਦੇਣ ਲਈ ਠੋਸ ਕੁਝ ਦਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ, ਹੰਡਾਈ ਦੇ ਅੰਤ ਵਿੱਚ ਲਿਖੋ, ਜਦੋਂ ਤਰਕ ਅਜੇ ਤੁਹਾਡੇ ਸਾਮ੍ਹਣੇ ਹੈ।