ਦੋ ਸਾਈਟ, ਇੱਕ ਸਬਨੈੱਟ, ਇੱਕ WireGuard ਹੱਬ: ਇਸ ਨੂੰ ਕੰਮ ਕਰਾਓ

ਦੋਵੇਂ ਸਾਈਟਾਂ ਇੱਕੋ LAN ਰੇਂਜ ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ ਓਵਰਲੈਪ ਹੀ ਅਸਲ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਤੋੜਨ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ ਹੈ। ਹੱਬ ਨੂੰ ਸਿਰਫ਼ ਮੰਜ਼ਿਲ ਪਤੇ ਨਾਲ ਸਾਈਟ ਚੁਣਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਦੋ ਇੱਕੋ ਜਿਹੀਆਂ ਮੰਜ਼ਿਲਾਂ ਉਸ ਨੂੰ ਚੁਣਨ ਲਈ ਕੁਝ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਚੱਲਦੇ ਦਫ਼ਤਰ ਨੂੰ ਟਨਲ ਦੀ ਲੋੜ ਪੂਰੀ ਕਰਨ ਲਈ ਮੁੜ ਨੰਬਰ ਦੇਣਾ ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਪ੍ਰਕਾਸ਼ਿਤ ਸੇਵਾ ਨੂੰ ਟਨਲ ਢੋ ਸਕਣ ਵਾਲਾ ਵੱਖਰਾ ਪਤਾ ਦੇਣ ਨਾਲੋਂ ਮਾੜਾ ਸੌਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਡਿਜ਼ਾਈਨ ਹਰ ਸਾਈਟ ਤੋਂ ਇੱਕ HTTPS ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ।

ਓਵਰਲੈਪ ਅਸਲ ਸਮੱਸਿਆ ਕਿਉਂ ਨਹੀਂ ਹੈ

WireGuard ਮੰਜ਼ਿਲ ਅਨੁਸਾਰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ: ਇੱਕ peer ਦੇ AllowedIPs ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ peer ਪੈਕਟ ਲਵੇਗਾ। ਦੋ peer ਇਕੱਠੇ 10.10.7.0/24 ਦਾ ਐਲਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਜਦ ਤੱਕ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਰ ਖੋਜ ਨਾ ਜਿੱਤੇ। ਇਹ peer ਸਾਰਣੀ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਟਨਲ ਦੀ ਨਹੀਂ, ਇਸ ਲਈ ਇੱਥੇ ਹੱਲ ਪਤਾ ਯੋਜਨਾ ਹੈ, ਰਾਊਟਿੰਗ ਦੀ ਚਾਲ ਨਹੀਂ।

ਯੋਜਨਾ ਇਹ ਹੈ ਕਿ LAN ਦਾ ਐਲਾਨ ਬਿਲਕੁਲ ਬੰਦ ਕੀਤਾ ਜਾਵੇ। ਇਸ ਦੀ ਥਾਂ ਹਰ ਸੇਵਾ ਲਈ alias ਦਾ ਐਲਾਨ ਕਰੋ, ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਪਤਾ, ਅਤੇ ਹਰ ਸਾਈਟ ਦਾ ਗੇਟਵੇ ਉਸ alias ਨੂੰ ਆਪਣੀ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰੇ।

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

ਹਰ ਸਾਈਟ ਨੂੰ ਉਹ alias ਦਿਓ ਜੋ ਵਰਤੋਂਕਾਰ ਰਾਊਟ ਕਰ ਸਕੇ

ਅਜਿਹੀ ਰੇਂਜ ਵਿੱਚੋਂ ਪਤੇ ਚੁਣੋ ਜੋ ਵਰਤੋਂਕਾਰ ਦੀ ਮਸ਼ੀਨ, ਹੱਬ ਜਾਂ ਦੋਵੇਂ LAN ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨਾਲ ਟਕਰਾਉਂਦੇ ਨਾ ਹੋਣ। ਇੱਥੇ ਹੱਬ 10.66.0.1 ਹੈ, ਵਰਤੋਂਕਾਰ 10.66.0.10, ਗੇਟਵੇ 10.66.0.21 ਅਤੇ 10.66.0.22 ਹਨ, ਅਤੇ ਦੋ alias 10.77.1.20 ਅਤੇ 10.77.2.20 ਹਨ। ਹੱਬ ਹਰ alias ਨੂੰ ਉਸ peer ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਦਾ ਮਾਲਕ ਹੈ, ਇਸ ਲਈ ਇੱਕ alias ਵੱਲ ਭੇਜਿਆ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕਟ ਸਿਰਫ਼ ਮੇਲ ਖਾਂਦੀ ਸਾਈਟ ਰਾਹੀਂ ਹੀ ਨਿਕਲ ਸਕਦਾ ਹੈ:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

ਵਰਤੋਂਕਾਰ ਵਾਲੇ ਪਾਸੇ ਸਿਰਫ਼ ਦੋ alias ਲੋੜੀਂਦੇ ਹਨ, ਜੋ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਨੂੰ ਦੋਵੇਂ LAN ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਮੁਕਤ ਰੱਖਦਾ ਹੈ। ਉਸ ਸੰਰਚਨਾ ਵਿੱਚ ਕੋਈ ਵੀ ਅਸਲ LAN ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ ਹੈ:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

ਹਰ ਗੇਟਵੇ ਹੱਬ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਸਰੋਤ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ, ਇਸ ਲਈ ਇੱਕ ਸਾਈਟ ਕਦੇ ਦੂਜੀ ਸਾਈਟ ਦਾ LAN ਨਹੀਂ ਜਾਣਦੀ। Keepalive ਸਾਈਟ ਦੇ ਅੱਪਲਿੰਕ ਉੱਤੇ NAT ਮੈਪਿੰਗ ਕਾਇਮ ਰੱਖਦਾ ਹੈ; ਇਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮਨਜ਼ੂਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਫਾਇਰਵਾਲ ਅਜੇ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸਵੀਕਾਰ ਹੋਵੇਗਾ। ਇੱਕ ਗੇਟਵੇ ਦੀ ਸੰਰਚਨਾ ਦੂਜੇ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਠੀਕ ਹੈ ਜੇ ਨਿੱਜੀ ਕੁੰਜੀ, ਇੰਟਰਫੇਸ ਪਤਾ ਅਤੇ alias ਸਾਰੇ ਬਦਲਣ।

ਹੱਬ ਨੂੰ ਆਪਣੇ ਦੋ peer ਵਿਚਕਾਰ ਕੀ ਮਨਜ਼ੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਹੱਬ ਆਪਣੇ ਹੀ ਦੋ peer ਵਿਚਕਾਰ ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਜੋ forward ਲੜੀ ਦਾ ਫੈਸਲਾ ਹੈ, ਇਨਪੁਟ ਫੈਸਲਾ ਨਹੀਂ। ਪਲੇਟਫਾਰਮ ਦੇ ਆਮ ਤਰੀਕੇ ਨਾਲ IPv4 ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰੋ, ਫਿਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਲੋੜੀਂਦੀਆਂ ਜੋੜੀਆਂ ਨੂੰ ਹੀ ਮਨਜ਼ੂਰੀ ਦਿਓ।

ਹੇਠਾਂ ਦਿੱਤਾ ਨਿਯਮ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇੱਕ alias ਅਤੇ ਇੱਕ ਪੋਰਟ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਰਾਹੀਂ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ। ਇਹ forward ਰਾਹ ਵਿੱਚ ਬਾਕੀ ਸਭ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਗੱਲ ਹੈ:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

ਦੋ ਗੱਲਾਂ ਦੱਸਣਯੋਗ ਹਨ ਕਿਉਂਕਿ ਇਹ ਚੁੱਪ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਆਧਾਰ ਲੜੀ ਵਿੱਚ accept ਦੂਜੀ ਵਿੱਚ drop ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਮੌਜੂਦਾ ਨੀਤੀ ਨਾਲ ਮਿਲਾਓ, ਇਸ ਦੇ ਕੋਲ ਲੋਡ ਨਾ ਕਰੋ। ਅਤੇ ਸਰੋਤ ਪਤਾ ਵਿਅਕਤੀ ਨਹੀਂ, ਡਿਵਾਈਸ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ; ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਨੈੱਟਵਰਕ ਮਨਜ਼ੂਰੀ ਤੋਂ ਵੱਖ ਰੱਖੋ।

ਜਿੱਥੇ alias ਅਸਲ ਪਤਾ ਬਣਦਾ ਹੈ

ਸਾਈਟ A ਨੂੰ 10.77.1.20 ਲਈ ਬੇਨਤੀ ਮਿਲਦੀ ਹੈ, ਮੰਜ਼ਿਲ ਨੂੰ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਸਰੋਤ ਨੂੰ ਆਪਣੇ LAN ਪਤੇ ਵਿੱਚ ਮੁੜ ਲਿਖਦਾ ਹੈ ਤਾਂ ਜੋ ਜਵਾਬ ਟਨਲ ਤੱਕ ਰਾਹ ਤੋਂ ਬਿਨਾਂ ਵਾਪਸ ਆ ਸਕੇ। ਦੋਵੇਂ ਅਨੁਵਾਦ ਇੱਕ ਥਾਂ ਕਰਨ ਨਾਲ ਬਾਕੀ ਨੈੱਟਵਰਕ alias ਤੋਂ ਅਣਜਾਣ ਰਹਿੰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਯਮ ਪੂਰੀ ਕਾਰਵਿਧੀ ਹਨ:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

ਫਿਰ ਸਾਈਟ A ਦੀ forward ਨੀਤੀ ਨੂੰ ਅਨੁਵਾਦਿਤ ਪ੍ਰਵਾਹ ਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ਤੋਂ LAN ਇੰਟਰਫੇਸ ਤੱਕ, ਨਾਲ ਹੀ ਵਾਪਸੀ ਦਿਸ਼ਾ ਮਨਜ਼ੂਰ ਕਰਨੀ ਪਵੇਗੀ। forward hook ਮੰਜ਼ਿਲ ਨੂੰ ਮੰਜ਼ਿਲ ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਅਤੇ ਸਰੋਤ ਮੁੜ-ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਪਤਾ ਦੱਸਦਾ ਹੈ। ਜਦੋਂ ਵੀ ਕੋਈ ਨਿਯਮ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਨਾ ਖਾਂਦਾ ਲੱਗੇ, ਉਹ ਦੋ hook ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ। alias ਵਿਰੁੱਧ ਲਿਖਿਆ forward ਨਿਯਮ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦਾ, ਕਿਉਂਕਿ ਉਸ hook ਉੱਤੇ alias ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ।

ਸਾਈਟ B ਇਸ ਨੂੰ ਆਪਣੇ alias ਅਤੇ ਆਪਣੀ ਕੁੰਜੀ ਨਾਲ ਦੁਹਰਾਉਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਸਾਈਟ A ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਮੁੜ ਵਰਤਣੀ ਨਹੀਂ ਚਾਹੀਦੀ, ਕਿਉਂਕਿ ਦੋ peer ਦਾ ਇੱਕ ਪਛਾਣ ਸਾਂਝੀ ਕਰਨਾ ਸੰਰਚਨਾ ਗਲਤੀ ਹੈ ਜੋ ਦੇਖਣੀ ਔਖੀ ਅਤੇ ਫਾਈਲ ਕਾਪੀ ਕਰਕੇ ਬਣਾਉਣੀ ਸੌਖੀ ਹੈ। ਦੋਵੇਂ ਗੇਟਵੇ ਦਸਤਾਵੇਜ਼ ਵੱਖਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਮੁੱਲਾਂ ਤੋਂ ਬਿਨਾਂ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ, ਤਾਂ ਜੋ ਸਮੀਖਿਆ ਵਿੱਚ ਫ਼ਰਕ ਸਪਸ਼ਟ ਦਿਸੇ। ਕਾਪੀ ਕੀਤੀ ਫਾਈਲ ਉਸ ਨੁਕਸ ਦਾ ਆਮ ਸਰੋਤ ਹੈ।

ਸਰੋਤ ਮੁੜ-ਲਿਖਣ ਦੀ ਇੱਕ ਕੀਮਤ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਗੇਟਵੇ ਨੂੰ ਆਪਣਾ ਕਲਾਇੰਟ ਮੰਨਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਦੇ ਲੌਗ ਹੁਣ ਨਹੀਂ ਦਿਖਾਉਂਦੇ ਕਿ ਕਿਹੜਾ ਵਰਤੋਂਕਾਰ ਜੁੜਿਆ। ਗੇਟਵੇ ਦਾ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ, ਅਤੇ ਅਨੁਵਾਦ ਨੇ ਹਟਾਈ ਨੈੱਟਵਰਕ ਪਛਾਣ ਦੀ ਭਰਪਾਈ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਇਨ ਕਮਜ਼ੋਰ ਨਾ ਕਰੋ।

ਦੋਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾਮ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਇਹ ਕਿਵੇਂ ਸਾਬਤ ਕਰਨਾ

ਹਰ alias ਨੂੰ DNS ਨਾਮ ਦਿਓ ਅਤੇ ਉਸ ਨਾਮ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਸੰਰਚਿਤ ਕਰੋ, ਕਿਉਂਕਿ ਅਨੁਵਾਦ ਰੀਡਾਇਰੈਕਟ ਜਾਂ ਇੰਬੈੱਡ ਕੀਤੇ ਨਿਰਪੇਖ URL ਮੁੜ ਨਹੀਂ ਲਿਖਦਾ। ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਨਾਮ ਵਰਤੋ, ਤਾਂ ਜੋ ਸਰਟੀਫਿਕੇਟ ਦੀ ਅਸੰਗਤੀ ਕਦੇ ਰਾਊਟਿੰਗ ਖਰਾਬੀ ਨਾ ਸਮਝੀ ਜਾਵੇ।

ਅਸਲ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚ ਕਰੋ, ਕਿਹੜੀ ਸਾਈਟ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਗੈਰ-ਮਨਜ਼ੂਰ ਪੋਰਟ ਵੀ ਜਾਂਚੋ। ਕਿਸੇ ਵੀ NAT ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਵਰਤੋ, ਕਿਉਂਕਿ ਸਥਾਪਿਤ ਸਥਿਤੀ ਪੁਰਾਣੀ ਮੈਪਿੰਗ ਰੱਖਦੀ ਹੈ:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

ਪਹਿਲੇ ਹੁਕਮ ਵਿੱਚ ਖਾਲੀ ਜਾਂ ਅਣਕਿਆਸਿਆ alias ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ ਵੀ ਫਾਇਰਵਾਲ ਨਿਯਮ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ peer ਚੋਣ ਗਲਤ ਹੈ। ਜੇ alias ਸਹੀ ਹੈ ਅਤੇ ਨਾਮ ਫਿਰ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ DNS ਅਤੇ ਸਰਟੀਫਿਕੇਟਾਂ ਵੱਲ ਚਲੀ ਗਈ ਹੈ। ਦੋਵੇਂ ਨਾਮ ਜਵਾਬ ਦੇਣ ਲੱਗਣ ਅਤੇ ਤੀਜਾ ਪੋਰਟ ਬੰਦ ਰਹਿਣ ਤੇ, ਡਿਜ਼ਾਈਨ ਉਹੀ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਦਾਅਵਾ ਕਰਦਾ ਹੈ: ਸੰਕੁਚਿਤ ਰੂਪ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਦੋ ਸੇਵਾਵਾਂ, ਮਿਲਾਈਆਂ ਦੋ LAN ਨਹੀਂ।