VPN ਅਤੇ ਘਰ ਦਾ LAN ਇੱਕੋ ਸਬਨੈੱਟ 'ਤੇ: ਪਹਿਲਾਂ ਰੂਟ ਵੇਖੋ
ਦੋਵੇਂ ਅਡੈਪਟਰ 192.168.1.0/24 ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਹੀ ਰੂਟ ਜਿੱਤਦਾ ਹੈ। ਮੁੜ ਨੰਬਰ ਦੇਣ ਜਾਂ DNS ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅਡੈਪਟਰ ਸੂਚੀ, ਜਿੱਤਣ ਵਾਲਾ ਰੂਟ ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ ਵੇਖੋ।
ਤੁਸੀਂ ਦਫ਼ਤਰ ਦੇ VPN ਨਾਲ ਜੁੜਦੇ ਹੋ, ਟਰੇ ਦਾ ਆਈਕਨ ਹਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਇੰਟਰਾਨੈੱਟ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਦੋ ਮੀਟਰ ਦੂਰ ਪਿਆ ਪ੍ਰਿੰਟਰ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੋ ਸ਼ੇਅਰ ਸਵੇਰੇ ਚੱਲ ਰਿਹਾ ਸੀ ਉਹੀ ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ ਸਮਾਂ ਪਾਰ ਕਰ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਲੌਗ ਵਿੱਚ ਪ੍ਰਿੰਟਰ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ। ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ DNS ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਨਾਮ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ ਉਹ ਨਾ-ਮੌਜੂਦ ਨਾਮ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਸਮੱਸਿਆ ਪਤੇ ਵਿੱਚ ਹੈ: ਦੋ ਅਡੈਪਟਰ ਹੁਣ 192.168.1.0/24 ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਅਤੇ ਇਹ ਪ੍ਰੀਫ਼ਿਕਸ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਰੂਟ ਜਿੱਤ ਸਕਦਾ ਹੈ। ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਵੇਖੋ ਅਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਕਿਹੜੇ ਅਡੈਪਟਰ ਨੇ ਇਹ ਲਿਆ।
ਲੱਛਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਟਨਲ ਤੋਂ ਨਹੀਂ
ਸੰਕੇਤ ਦਾਇਰਾ ਹੈ। ਜੇ ਇੰਟਰਾਨੈੱਟ ਚੱਲਦਾ ਹੈ ਅਤੇ ਹਰ ਸਥਾਨਕ ਡਿਵਾਈਸ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਟਨਲ ਠੀਕ ਹੈ ਅਤੇ ਸਥਾਨਕ ਰਾਹ ਨਹੀਂ। ਜੇ ਸਥਾਨਕ ਡਿਵਾਈਸਾਂ ਚੱਲਦੀਆਂ ਹਨ ਅਤੇ ਇੰਟਰਾਨੈੱਟ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਲਟਾ। ਜੇ ਇੱਕ ਹੋਸਟ ਤੋਂ ਬਿਨਾਂ ਸਭ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਅਜਿਹੇ ਪਤੇ ਵੱਲ ਵੇਖ ਰਹੇ ਹੋ ਜੋ ਦੋਵੇਂ ਪਾਸਿਆਂ ਮੌਜੂਦ ਹੈ।
ਕੋਈ ਸੈਟਿੰਗ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਥਾਨਕ ਅਤੇ ਇੱਕ ਦੂਰ ਦਾ ਪਤਾ ਲਿਖ ਲਓ। “ਪ੍ਰਿੰਟਰ” ਜਾਂਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ; 192.168.1.40 ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਕਦਮ ਇਸ ਸਮੱਸਿਆ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਬਰਬਾਦ ਹੋਣ ਵਾਲਾ ਇੱਕ ਘੰਟਾ ਰੋਕਦਾ ਹੈ, ਭਾਵ ਰੂਟਿੰਗ ਫ਼ੈਸਲੇ ਲਈ DNS ਸੈਟਿੰਗ ਦੁਬਾਰਾ ਲਿਖਣਾ।
ਕਦਮ 1: ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਦੋਵੇਂ ਅਡੈਪਟਰ ਵੇਖੋ
ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ (ncpa.cpl) ਖੋਲ੍ਹੋ ਅਤੇ ਦੋਵੇਂ ਅਡੈਪਟਰ ਨਾਲ-ਨਾਲ ਪੜ੍ਹੋ। Ethernet ਅਡੈਪਟਰ 192.168.1.50/24 ਦਿਖਾਉਂਦਾ ਹੈ, ਗੇਟਵੇ 192.168.1.1। VPN ਅਡੈਪਟਰ ਸਰਵਰ ਵੱਲੋਂ ਭੇਜਿਆ 192.168.1.201/24 ਦਿਖਾਉਂਦਾ ਹੈ। ਦੋਵੇਂ ਜਾਇਜ਼ ਹਨ, ਦੋਵੇਂ ਮੰਨਦੇ ਹਨ ਕਿ ਪ੍ਰੀਫ਼ਿਕਸ on-link ਹੈ, ਅਤੇ ਸਟੈਕ ਇਸ ਲਈ ਇੱਕ ਹੀ ਰੂਟ ਰੱਖੇਗਾ।
Get-NetIPAddress -AddressFamily IPv4 ਪਤੇ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ Get-NetIPInterface | Sort-Object InterfaceMetric ਉਹ ਕ੍ਰਮ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਟੈਕ ਇਹਨਾਂ ਨੂੰ ਵਰਤੇਗਾ। ਉਹੀ ਮੈਟ੍ਰਿਕ ਕਾਲਮ ਉਹ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੁਣ ਪੜ੍ਹਨ ਵਾਲੇ ਹੋ, ਇਸ ਲਈ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ ਅੰਕ ਲਿਖ ਲਓ।
DNS ਸਿਧਾਂਤ ਸਸਤੇ ਵਿੱਚ ਗ਼ਲਤ ਸਾਬਤ ਕਰੋ: Resolve-DnsName printer.office.lan ਕੱਲ੍ਹ ਵਾਲਾ ਹੀ ਪਤਾ ਮੋੜਦਾ ਹੈ। ਨਾਮ ਹੱਲ ਹੋ ਗਿਆ; ਫਿਰ ਪੈਕਟ ਗ਼ਲਤ ਅਡੈਪਟਰ ਰਾਹੀਂ ਬਾਹਰ ਗਿਆ। ਇੱਥੇ ਦੋ ਮਿੰਟ ਰਿਜ਼ੌਲਵਰ ਸੈਟਿੰਗ ਵਿੱਚ ਦੁਪਹਿਰ ਬਚਾਉਂਦੇ ਹਨ।
ਕਦਮ 2: ਸੱਚਮੁੱਚ ਜਿੱਤਿਆ ਰੂਟ ਪੜ੍ਹੋ
Find-NetRoute -RemoteIPAddress 192.168.1.40 ਉਸ ਪਤੇ ਲਈ ਸਟੈਕ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫ਼ੇਸ, ਅਗਲੇ ਹੌਪ ਅਤੇ ਸਰੋਤ ਨੂੰ ਛਾਪਦਾ ਹੈ। ਇਸ ਆਉਟਪੁੱਟ ਨੂੰ ਸੰਕੇਤ ਨਹੀਂ, ਜਵਾਬ ਮੰਨੋ। ਕਿਹੜੀ ਐਂਟਰੀ ਕਿੰਨਾ ਹਾਰੀ ਇਹ ਵੇਖਣ ਲਈ route print -4 ਪੂਰੀ ਸਾਰਣੀ ਦਿੰਦਾ ਹੈ।
ਵਿਸ਼ੇਸ਼ਤਾ ਇਰਾਦੇ ਨੂੰ ਹਰਾਉਂਦੀ ਹੈ. ਭੇਜਿਆ ਗਿਆ 192.168.0.0/25 ਸਥਾਨਕ 192.168.0.0/24 ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੀਫ਼ਿਕਸ ਲੰਮਾ ਹੈ, ਇਸ ਲਈ 192.168.0.0 ਤੋਂ 192.168.0.127 ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉੱਪਰਲਾ ਅੱਧਾ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ। ਬਿਨਾਂ ਕਿਸੇ ਗ਼ਲਤੀ ਸੁਨੇਹੇ ਦੇ ਅੱਧਾ LAN ਗ਼ਾਇਬ ਹੋਣਾ ਉਸ ਸਾਰਣੀ ਲਈ ਸਹੀ ਵਿਵਹਾਰ ਹੈ।
tracert -d 192.168.1.40 ਸਾਰਣੀ ਤੋਂ ਬਾਹਰੋਂ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ: ਜੇ ਪਹਿਲਾ ਹੌਪ ਤੁਹਾਡੇ ਆਪਣੇ ਰਾਊਟਰ ਦੀ ਥਾਂ ਟਨਲ ਦਾ ਪਤਾ ਹੈ, ਤਾਂ ਰੂਟ ਹੀ ਪੂਰੀ ਕਹਾਣੀ ਹੈ। Linux 'ਤੇ ਉਹੀ ਸਵਾਲ ip route get 192.168.1.40 ਹੈ, ਜੋ ਸਰੋਤ ਪਤਾ ਅਤੇ ਡਿਵਾਈਸ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਛਾਪਦਾ ਹੈ। ਜਦੋਂ ਜਵਾਬ tun0 ਕਹੇ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲ ਵੇਖਣਾ ਬੰਦ ਕਰੋ।
ਕਦਮ 3: ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਜਾਂਚੋ
ਸਹੀ ਅੱਗੇ ਵਾਲਾ ਰੂਟ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜੇ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਜਵਾਬ ਨਾ ਦੇ ਸਕੇ। ਜਦੋਂ ਕਲਾਇੰਟ ਦੇ LAN ਤੱਕ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹਾਂ, ਤਾਂ ਉਸ LAN ਦੇ ਗੇਟਵੇ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਟਨਲ ਪੂਲ ਕਿੱਥੇ ਹੈ: ਉਸ ਰਾਊਟਰ 'ਤੇ ip route add 10.8.0.0/24 via 192.168.1.12, ਅਤੇ ਕਲਾਇੰਟ ਵਾਪਸੀ ਦਾ ਰਾਹ ਜਾਣਨ ਲਈ ਸਰਵਰ ਤੋਂ push “route 192.168.1.0 255.255.255.0”।
ਪਹਿਲੀ ਐਂਟਰੀ ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਟਾਰਗਿਟ ਛੱਡ ਕੇ ਆਪਣੇ ਡਿਫ਼ੌਲਟ ਗੇਟਵੇ ਵੱਲ ਜਾਂਦਾ ਹੈ, ਜੋ ਨਿੱਜੀ ਪਤਾ ISP ਨੂੰ ਭੇਜ ਕੇ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਲੱਛਣ ਇੱਕ-ਪਾਸੜ ਹੈ ਅਤੇ ਗ਼ਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ: ਬੇਨਤੀਆਂ tun0 'ਤੇ ਦਿਸਦੀਆਂ ਹਨ, ਜਵਾਬ ਕਦੇ ਨਹੀਂ।
VPN ਹੋਸਟ 'ਤੇ masquerade ਨਿਯਮ ਉਸ ਸਥਿਰ ਰੂਟ ਦੀ ਲੋੜ ਹਟਾ ਦਿੰਦਾ ਹੈ: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. ਇਹ ਅਸਲ ਸਰੋਤ ਪਤੇ ਵੀ ਲੁਕਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹਰ ਅਗਲਾ ਲੌਗ ਸਵਾਲ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਗ਼ਲਤ ਡਿਫ਼ੌਲਟ ਗੇਟਵੇ ਵਾਲਾ ਟਾਰਗਿਟ ਹੋਸਟ ਵੀ ਉਹੀ ਚੁੱਪ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਵਧੀਆ ਹਾਲਤ ਵਿੱਚ ICMP ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਆਮ ਹਾਲਤ ਵਿੱਚ ਕਾਲਾ ਛੇਕ, ਇਸ ਲਈ ਕੈਪਚਰ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਲੋੜੀਂਦਾ ਹੈ।
ਕਦਮ 4: ਉਹ ਮੁਰੰਮਤ ਚੁਣੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਨਿਭਾ ਸਕੋ
ਇਸ ਲਈ ਪੰਜ ਮੁਰੰਮਤਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਉਹ ਇੱਕ-ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀਆਂ। ਕਿਹੜਾ ਹੁਕਮ ਸਭ ਤੋਂ ਛੋਟਾ ਹੈ ਇਸ ਆਧਾਰ 'ਤੇ ਨਹੀਂ, ਸਗੋਂ ਇੱਕੋ ਸਮੇਂ ਕੀ ਪਹੁੰਚਯੋਗ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਇਸ ਆਧਾਰ 'ਤੇ ਚੁਣੋ।
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
ਮੈਟ੍ਰਿਕ ਸਭ ਤੋਂ ਸਸਤਾ ਵਿਕਲਪ ਹੈ ਅਤੇ ਲੋਕ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਸੇ ਵੱਲ ਹੱਥ ਪਾਉਂਦੇ ਹਨ। ਬਦਲਾਅ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਚਾਲੂ ਰਹਿਣ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੇ ਕੋਲ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਹੈ, ਤੁਸੀਂ ਭੁੱਲ ਜਾਣ ਵਾਲੇ ਸ਼ੈੱਲ ਵਿੱਚ ਨਹੀਂ। ਇਹ ਦੋ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਇੱਕੋ ਪਤੇ ਤੱਕ ਇੱਕੋ ਸਮੇਂ ਪਹੁੰਚ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਅਤੇ ਇਹੀ ਸੀਮਾ ਬਾਕੀ ਸਭ ਨੂੰ ਸਾਰਣੀ ਵਿੱਚ ਹੇਠਾਂ ਭੇਜਦੀ ਹੈ।
ਘਰ ਦੇ LAN ਨੂੰ ਮੁੜ ਨੰਬਰ ਦੇਣਾ 10.10.0.0/24 'ਤੇ ਸਾਫ਼ ਹੱਲ ਹੈ: ਇੱਕ DHCP ਲੀਜ਼ ਨਵੀਨੀਕਰਨ ਅਤੇ ਪੁਰਾਣੀ ਰੇਂਜ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੇ ਰਿਜ਼ਰਵੇਸ਼ਨ, ਪ੍ਰਿੰਟਰ ਕਤਾਰਾਂ ਤੇ ਹਾਰਡਕੋਡ ਪਤੇ। ਦਫ਼ਤਰ ਵਾਲਾ ਪਾਸਾ ਮੁੜ ਨੰਬਰ ਦੇਣਾ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡਾ ਫ਼ੈਸਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਦੋਵੇਂ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਹੋਵੇ ਤਾਂ IPv6 ਟਕਰਾਅ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਯਾਦ ਰੱਖਣ ਵਾਲੀ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਥਾਂ fd00::/8 ਤੋਂ ਵਿਲੱਖਣ ਸਥਾਨਕ ਪ੍ਰੀਫ਼ਿਕਸ ਵਰਤ ਕੇ, ਪਰ ਐਪਲੀਕੇਸ਼ਨ TCP 'ਤੇ ਜਾਂਚੋ, ping ਨਾਲ ਨਹੀਂ, ਕਿਉਂਕਿ ICMP ਚੱਲ ਸਕਦਾ ਹੈ ਜਦੋਂ ਸੇਵਾ ਨਾ ਚੱਲੇ।
OpenVPN ਦਾ ਆਪਣਾ ਅਨੁਵਾਦ ਵਿਕਲਪ ਆਖ਼ਰੀ ਉਪਾਅ ਹੈ, ਸਰਵਰ ਤੋਂ ਕਲਾਇੰਟ-ਖ਼ਾਸ ਡਾਇਰੈਕਟਰੀ ਐਂਟਰੀ ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਵਿਕਲਪ ਦੇ ਨਾਮ ਤੋਂ ਬਾਅਦ ਇਹ ਚਾਰ ਪੈਰਾਮੀਟਰ ਲੈਂਦਾ ਹੈ — ਦਿਸ਼ਾ, ਨੈੱਟਵਰਕ, ਨੈੱਟਮਾਸਕ ਅਤੇ ਉਪਨਾਮ — ਅਤੇ ਉਪਨਾਮ ਚੋਣਵਾਂ ਨਹੀਂ: push "route 192.168.2.0 255.255.255.0" ਅਤੇ push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0"। ਨੈੱਟਵਰਕ ਅਤੇ ਮਾਸਕ ਉਹ ਰੇਂਜ ਹੈ ਜੋ ਕਲਾਇੰਟ ਵੇਖਦਾ ਹੈ (192.168.2.0/24), ਉਪਨਾਮ ਸਰਵਰ ਪਾਸੇ ਦੀ ਅਸਲ ਦਫ਼ਤਰ ਰੇਂਜ ਹੈ (192.168.1.0/24), ਅਤੇ ਭੇਜਿਆ ਰੂਟ ਉਸ ਦਿੱਸਦੀ ਰੇਂਜ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਫਿਰ ਦਫ਼ਤਰ ਉਸ ਕਲਾਇੰਟ ਨੂੰ 192.168.2.x ਹੇਠ ਦਿੱਸਦਾ ਹੈ। ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਮੈਪਿੰਗ ਦਰਜ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਬੰਦਾ ਇਸ ਨੂੰ ਰੂਟਿੰਗ ਖ਼ਰਾਬੀ ਸਮਝ ਕੇ ਡੀਬੱਗ ਕਰੇਗਾ।
ਇੱਕੋ ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਅਨੁਵਾਦ ਦਾ ਸੰਕੁਚਿਤ ਰੂਪ ਹੈ ਅਤੇ ਇਸ ਨੂੰ OpenVPN ਵਿਕਲਪ ਦੀ ਲੋੜ ਹੀ ਨਹੀਂ। VPN ਹੋਸਟ 'ਤੇ DNAT ਨਿਯਮ ਇੱਕ ਪੋਰਟ ਮੁੜ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ LAN ਆਪਣੇ ਪਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਸ ਹੋਸਟ ਪਤੇ 'ਤੇ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜੋ ਇਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ। ਕੀਮਤ ਆਮ ਹੈ: ਸੇਵਾ VPN ਹੋਸਟ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਵੇਖਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ-ਵਾਰ ਲੌਗ ਅਤੇ ਉਲਟ ਖੋਜ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਇੱਕ ਪ੍ਰਿੰਟਰ ਕਤਾਰ ਜਾਂ ਇੱਕ ਐਡਮਿਨ ਸਫ਼ਾ ਢੱਕਦਾ ਹੈ, ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੇ ਹੋਸਟ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਣਾ ਨਹੀਂ।
ਹੋਰ ਕੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ
ਬ੍ਰੌਡਕਾਸਟ ਰੂਟਿਡ ਟਨਲ ਪਾਰ ਨਹੀਂ ਕਰਦਾ। DLNA, UPnP, NetBIOS ਬ੍ਰਾਊਜ਼ਿੰਗ ਅਤੇ Wake-on-LAN ਉਸ ਬ੍ਰੌਡਕਾਸਟ ਜਾਂ ਮਲਟੀਕਾਸਟ 'ਤੇ ਨਿਰਭਰ ਹਨ ਜੋ tun ਡਿਵਾਈਸ ਨਹੀਂ ਢੋਂਦਾ, ਇਸ ਲਈ ਕੋਈ ਰੂਟ ਖੋਜ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। dev tap ਨਾਲ ਬ੍ਰਿਜਿੰਗ ਸੈਗਮੈਂਟ ਵਧਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਸ ਨਾਲ DHCP ਬ੍ਰੌਡਕਾਸਟ, ARP ਤੇ ਹਰ ਹੋਰ ਖੋਜ ਪੈਕਟ; ਦੂਰ ਦੇ ਰਾਊਟਰ ਦੇ LAN ਪਾਸੇ ਦੇ ਪਤੇ ਲਈ route 192.168.2.1 255.255.255.255 ਵਰਗਾ ਯੂਨੀਕਾਸਟ ਹੋਸਟ ਰੂਟ ਚੁਣੋ।
ਇੱਕੋ ਰਾਹ 'ਤੇ ਦੋਵੇਂ 192.168.1.1 ਵਰਤਣ ਵਾਲੇ ਦੋ ਰਾਊਟਰ ਇੱਕੋ ਸਮੱਸਿਆ ਪਰਿਵਾਰ ਦੇ ਹਨ: ਸਥਾਨਕ ਪਤਾ ਹਮੇਸ਼ਾ ਜਿੱਤਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ LAN ਹਿਲਣ ਤੱਕ ਦੂਰ ਦੇ ਰਾਊਟਰ ਦਾ ਸਫ਼ਾ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ। ਦੂਜਾ ਅਡੈਪਟਰ ਜੋੜਨ ਨਾਲ ਦੋਵੇਂ ਹਾਲਤਾਂ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤ ਦਰਜ ਕਰੋ: ip route get ਜਾਂ Find-NetRoute, ਸੰਬੰਧਿਤ ਪਤੇ 'ਤੇ ping -c 3, ਇੱਕ traceroute, ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ tcpdump -ni tun0 icmp, ਫਿਰ ਸਰਵਰ 'ਤੇ ਰੂਟਿੰਗ ਸਾਰਣੀ ਅਤੇ NAT ਕਾਊਂਟਰ। ਜੋ ping ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ ਉਹ ਟਨਲ ਵੱਲ ਨਹੀਂ, ਵਾਪਸੀ ਦੇ ਰਾਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਇੱਕ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉੱਪਰਲੀਆਂ ਕਿਹੜੀ ਮੁਰੰਮਤ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦੀ ਹੈ।