{"id":53572,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chto-proishodit-pri-soedineniyah-vnutri-i-vne-vpn-tunnelya"},"modified":"2020-02-18T14:01:29","modified_gmt":"2020-02-18T11:01:29","slug":"chto-proishodit-pri-soedineniyah-vnutri-i-vne-vpn-tunnelya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/chto-proishodit-pri-soedineniyah-vnutri-i-vne-vpn-tunnelya","title":{"rendered":"What happens during connections inside and outside the VPN tunnel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Letters to Tucha's technical support often turn into real articles. Recently, a client reached out to us asking to clarify what happens with connections within the VPN tunnel between the user's office and the cloud environment, as well as with connections outside the VPN tunnel. Therefore, the text provided below is an actual letter we sent to one of the clients in response to their question. Of course, we changed the IP addresses to anonymize the client. But yes, Tucha's technical support is indeed renowned for its detailed responses and informative letters. \ud83d\ude42<\/p>\n

Of course, we understand that for many, this article may not be groundbreaking. However, since articles for beginner administrators occasionally appear on Habr, and given that this article originated from a real letter to a real client, we still want to share this information here. There's a good chance it will be useful to someone.
\nSo, we will explain in detail what happens between the cloud server and the office if they are connected via a site-to-site network. Note that some services are only available from the office, while others can be accessed from anywhere on the Internet.<\/p>\n

First, we will clarify that our client requested the server 192.168.A.1<\/b> to allow connections via RDP from anywhere, connecting to A.A.A.2:13389<\/b>, while the other services are accessible only from the office (192.168.B.0\/24)<\/b>, connected through VPN<\/a>. The client also initially set it up so that the machine 192.168.B.2 <\/b>in the office could also be accessed via RDP from anywhere, connecting to B.B.B.1:11111<\/b>. We assisted in organizing IPSec connections between the cloud and the office, and the client's IT specialist began to ask questions about what would happen in various scenarios. To answer all these questions, we wrote out everything you can read below.
\n<\/a><\/noindex>
\n\"What<\/p>\n

Now, let's examine these processes in more detail.<\/p>\n

<\/p>\n

Position One<\/h3>\n

\nWhen something is sent from 192.168.B.0\/24<\/b> downward API support (simultaneously with this in 192.168.A.0\/24<\/b> or from 192.168.A.0\/24<\/b> downward API support (simultaneously with this in 192.168.B.0\/24<\/b>, it enters the VPN. This means that the packet is additionally encrypted and transmitted between B.B.B.1<\/b> and A.A.A.1<\/b>, but 192.168.A.1<\/b> sees the packet specifically from 192.168.B.1<\/b>. They can communicate with each other using any protocols. The responses are sent back through the VPN in the same way, thus the packet from 192.168.A.1<\/b> for 192.168.B.1<\/b> will be sent as an ESP datagram from A.A.A.1<\/b> to B.B.B.1<\/b>, which the router on the other side will unwrap, extract the packet from, and deliver to 192.168.B.1<\/b> how a packet from 192.168.A.1<\/b>.<\/p>\n

A specific example:<\/p>\n

1) 192.168.B.1<\/b> calls 192.168.A.1<\/b>, wants to establish a TCP connection with 192.168.A.1:3389<\/b>;<\/p>\n

2) 192.168.B.1<\/b> sends a request to establish a connection from 192.168.B.1:55555<\/b> (the port number for feedback is chosen by it, here and thereafter we will use number 55555 as an example of such a port number that the system selects during the formation of the TCP connection) to 192.168.A.1:3389<\/b>;<\/p>\n

3) the operating system running on the computer with the address 192.168.B.1<\/b>, decides to send this packet to the gateway address of the router (192.168.B.254<\/b> in our case), because it does not have other, more specific routes for 192.168.A.1<\/b>, so it sends the packet via the default route (0.0.0.0\/0);<\/p>\n

4) for this, it tries to find the MAC address for the IP address 192.168.B.254 <\/b>in the ARP protocol cache table. If not found, it sends from the address 192.168.B.1<\/b> a broadcast who-has request to the network 192.168.B.0\/24<\/b>When 192.168.B.254<\/b> responds by sending its MAC address, the system sends the Ethernet packet to it and records this information in its cache table;<\/p>\n

5) the router receives this packet and determines where to send it: it has a policy that states it must route all packets between 192.168.B.0\/24<\/b> and 192.168.A.0\/24<\/b> over a VPN connection between B.B.B.1<\/b> and A.A.A.1<\/b>;<\/p>\n

6) the router forms an ESP datagram from B.B.B.1<\/b> to A.A.A.1<\/b>;<\/p>\n

7) the router decides where to send this packet, it sends it to, for example, B.B.B.254<\/b> (ISP gateway), because it does not have more specific routes to A.A.A.1<\/b>, than 0.0.0.0\/0;<\/p>\n

8) just like mentioned before, it finds the MAC address for B.B.B.254<\/b> and sends the packet to the ISP gateway;<\/p>\n

9) ISPs transmit the ESP datagram through their networks from B.B.B.1<\/b> to A.A.A.1<\/b>;<\/p>\n

10) the virtual router at A.A.A.1<\/b> receives this datagram, decrypts it, and obtains the packet from 192.168.B.1:55555<\/b> for 192.168.A.1:3389<\/b>;<\/p>\n

11) the virtual router checks where to send it, finds the network in the routing table 192.168.A.0\/24<\/b> and sends it directly to 192.168.A.1<\/b>, since it has an interface 192.168.A.254\/24<\/b>;<\/p>\n

12) for this, the virtual router finds the MAC address for 192.168.A.1<\/b> and sends this packet to it over a virtual Ethernet network;<\/p>\n

13) 192.168.A.1<\/b> receives this packet on port 3389, agrees to establish a connection and forms a response packet from 192.168.A.1:3389<\/b> to 192.168.B.1:55555<\/b>;<\/p>\n

14) its system sends this packet to the gateway address of the virtual router (192.168.A.254<\/b> in our case), because it does not have other, more specific routes for 192.168.B.1<\/b>, it does not have, so it must send the packet via the default route (0.0.0.0\/0);<\/p>\n

15) just as in the previous cases, the system running on the server with the address 192.168.A.1<\/b>, finds the MAC address 192.168.A.254<\/b>, since it is in the same network as its interface 192.168.A.1\/24<\/b>;<\/p>\n

16) the virtual router receives this packet and decides where to forward it: it has a policy that dictates it must process all packets between 192.168.A.0\/24<\/b> and 192.168.B.0\/24<\/b> over a VPN connection between A.A.A.1<\/b> and B.B.B.1<\/b>;<\/p>\n

17) the virtual router creates an ESP datagram from A.A.A.1<\/b> for B.B.B.1<\/b>;<\/p>\n

18) the virtual router decides whom to send this packet to, forwarding it to A.A.A.254<\/b> (the internet service provider's gateway, which, in this case, is also us), because there are no more specific routes to B.B.B.1<\/b>, than 0.0.0.0\/0;<\/p>\n

19) internet providers transmit the ESP datagram across their networks A.A.A.1<\/b> to B.B.B.1<\/b>;<\/p>\n

20) the router at B.B.B.1 <\/b>receives this datagram, decrypts it, and obtains the packet from 192.168.A.1:3389<\/b> for 192.168.B.1:55555<\/b>;<\/p>\n

21) it understands that it should forward it specifically to 192.168.B.1<\/b>, since it is in the same network, therefore, there is a corresponding entry in the routing table that compels it to send packets for all 192.168.B.0\/24<\/b> directly;<\/p>\n

22) the router finds the MAC address for 192.168.B.1<\/b> and forwards this packet to it;<\/p>\n

23) the operating system on the computer with the address 192.168.B.1<\/b> receives the packet from 192.168.A.1:3389<\/b> for 192.168.B.1:55555<\/b> and initiates the next steps to establish a TCP connection.<\/p>\n

This example concisely and simply describes what happens at layers 2-4 (many more details could be recalled here). Layers 1, 5-7 are not covered.<\/p>\n

Position two<\/h3>\n

\nIf something is sent specifically to 192.168.B.0\/24<\/b> A.A.A.2 , it goes not through the VPN, but directly. This means that if a user from address<\/b>, this packet is NAT-ed from address 192.168.B.1<\/b> calls A.A.A.2:13389<\/b>, passing to B.B.B.1<\/b>, and there the router receives it and forwards it to , it goes not through the VPN, but directly. This means that if a user from address<\/b>knows nothing about 192.168.A.1<\/b>. 192.168.A.1<\/b> , it sees the packet from 192.168.B.1<\/b>, since it is NAT-ed. Therefore, the response to this request goes through the common route, it is NAT-ed from address B.B.B.1<\/b>and heads to , it goes not through the VPN, but directly. This means that if a user from address <\/b>, and that router returns this response to B.B.B.1<\/b>, which sees the response from 192.168.B.1<\/b>, the one it was addressing. , it goes not through the VPN, but directly. This means that if a user from address<\/b>(this number, just like in the previous example, may be different) at<\/p>\n

A specific example:<\/p>\n

1) 192.168.B.1<\/b> calls , it goes not through the VPN, but directly. This means that if a user from address<\/b>, wants to establish a TCP connection with A.A.A.2:13389<\/b>;<\/p>\n

2) 192.168.B.1<\/b> sends a request to establish a connection from 192.168.B.1:55555<\/b> , it does not exist, which means it forwards the packet via the default route (0.0.0.0\/0); A.A.A.2:13389<\/b>;<\/p>\n

3) the operating system running on the computer with the address 192.168.B.1<\/b>, decides to send this packet to the gateway address of the router (192.168.B.254<\/b> in our case), because it does not have other, more specific routes for , it goes not through the VPN, but directly. This means that if a user from address<\/b>4) for this, as we mentioned in the previous example, it tries to find the MAC address for the IP address<\/p>\n

5) the router receives this packet and decides where to forward it: it has a policy that dictates it must NAT (substituting the source address) all packets from 192.168.B.254<\/b> in the ARP protocol cache table. If not found, it sends from the address 192.168.B.1<\/b> a broadcast who-has request to the network 192.168.B.0\/24<\/b>When 192.168.B.254<\/b> responds by sending its MAC address, the system sends the Ethernet packet to it and records this information in its cache table;<\/p>\n

to other nodes in the internet; 192.168.B.0\/24<\/b> to other nodes of the Internet;<\/p>\n

6) Since this policy implies that the return address must match the lower address on the interface through which this packet will be sent, the router first determines to whom exactly it should send this packet, as in the previous example, it must send it to B.B.B.254<\/b> (ISP gateway), because it does not have more specific routes to , it goes not through the VPN, but directly. This means that if a user from address<\/b>, than 0.0.0.0\/0;<\/p>\n

7) Therefore, the router replaces the return address of the packet, from now on the packet from B.B.B.1:44444<\/b> (the port number, of course, can be different) to A.A.A.2:13389<\/b>;<\/p>\n

8) The router remembers what it did, so when the response from A.A.A.2:13389<\/b> to B.B.B.1:44444<\/b> comes in, it will know that it should change the address and port of the recipient to 192.168.B.1:55555<\/b>.<\/p>\n

9) Now, the router must send it to the internet service provider through B.B.B.254<\/b>, therefore, just as we mentioned earlier, it finds the MAC address for B.B.B.254 <\/b>and sends the packet to the ISP gateway;<\/p>\n

10) Internet service providers transmit the packet through their networks from B.B.B.1<\/b> to , it goes not through the VPN, but directly. This means that if a user from address<\/b>;<\/p>\n

11) The virtual router at , it goes not through the VPN, but directly. This means that if a user from address<\/b> receives this packet on port 13389;<\/p>\n

12) The virtual router has a rule that stipulates that packets received from any sender on this port should be sent to 192.168.A.1:3389<\/b>;<\/p>\n

13) The virtual router finds the network in the routing table 192.168.A.0\/24<\/b> and sends it directly to 192.168.A.<\/b>1, as it has the interface 192.168.A.254\/24<\/b>;<\/p>\n

14) For this, the virtual router finds the MAC address for 192.168.A.1<\/b> and sends this packet to it over a virtual Ethernet network;<\/p>\n

15) 192.168.A.1<\/b> receives this packet on port 3389, agrees to establish a connection and forms a response packet from 192.168.A.1:3389<\/b> to B.B.B.1:44444<\/b>;<\/p>\n

16) Its system forwards this packet to the gateway address of the virtual router (192.168.A.254<\/b> in our case), because it does not have other, more specific routes for B.B.B.1<\/b>, it does not have, so it must send the packet via the default route (0.0.0.0\/0);<\/p>\n

17) Just like in the previous cases, the system running on the server with the address 192.168.A.1<\/b>, finds the MAC address 192.168.A.254<\/b>, since it is in the same network as its interface 192.168.A.1\/24<\/b>;<\/p>\n

18) The virtual router receives this packet. It should be noted that it remembers having received the packet from A.A.A.2:13389<\/b> and changed its address and recipient port to B.B.B.1:44444<\/b> , therefore, for the packet from 192.168.A.1:3389<\/b>it changes the sender's address to 192.168.A.1:3389 <\/b>for B.B.B.1:44444<\/b> 19) The virtual router decides to whom to send this packet, it sends it to A.A.A.2:13389<\/b>;<\/p>\n

20) Internet service providers transmit the packet with A.A.A.254<\/b> (the internet service provider's gateway, which, in this case, is also us), because there are no more specific routes to B.B.B.1<\/b>, than 0.0.0.0\/0;<\/p>\n

21) The router at , it goes not through the VPN, but directly. This means that if a user from address<\/b> to B.B.B.1<\/b>;<\/p>\n

receives this packet and recalls that when it forwarded the packet from B.B.B.1<\/b> , it changed its sender address and port to 192.168.B.1:55555<\/b> for A.A.A.2:13389<\/b>, so this is a response that needs to be sent to B.B.B.1:44444<\/b>(In reality, there are several more checks, but we will not delve into that); 192.168.B.1:55555<\/b> 22) It realizes that it should be sent directly to<\/p>\n

, since it is in the same network, therefore, it has a corresponding entry in the routing table that directs packets for all 192.168.B.1<\/b>. 192.168.B.0\/24 <\/b>directly;<\/p>\n

23) the router finds the MAC address for 192.168.B.1<\/b> and forwards this packet to it;<\/p>\n

24) the operating system on the computer with the address 192.168.B.1<\/b> receives the packet from A.A.A.2:13389<\/b> for 192.168.B.1:55555<\/b> and initiates the next steps to establish a TCP connection.<\/p>\n

It should be noted that in this case, the computer with the address 192.168.B.1<\/b> knows nothing about the server with the address 192.168.A.1<\/b>, it only communicates with , it goes not through the VPN, but directly. This means that if a user from address<\/b>. Similarly, the server with the address 192.168.A.1<\/b> knows nothing about the computer with the address 192.168.B.1<\/b>. It believes that it has been contacted from the address B.B.B.1<\/b>, and it does not know anything else, so to speak.<\/p>\n

It\u2019s also worth noting that if this computer accesses A.A.A.2:1540<\/b>, the connection will not be established because port 1540 is not configured for connection forwarding on the virtual router, even if there are any servers in the virtual network 192.168.A.0\/24<\/b> (for example, on the server with the address 192.168.A.1<\/b>) and there are services waiting for connections on that port. If the user of the computer with the address 192.168.B.1<\/b> urgently needs to establish a connection with this service, they must use VPN, that is, connect directly to 192.168.A.1:1540<\/b>.<\/p>\n

It should be emphasized that any attempts to establish a connection with A.A.A.1<\/b> (except for IPSec connections from B.B.B.1<\/b> ) will not be successful. Any attempts to establish connections with , it goes not through the VPN, but directly. This means that if a user from address<\/b>, except for connections to port 13389, will also not be successful.
\nIt should also be noted that in the event that someone else (for example, C.C.C.C) accesses , it goes not through the VPN, but directly. This means that if a user from address <\/b>, everything mentioned in points 10-20 will apply to them as well. What happens before and after depends on what exactly is behind this C.C.C.C. We do not have such information, therefore we recommend consulting the administrators of the node with the address C.C.C.C.<\/p>\n

Third position<\/h3>\n

\nAnd conversely, if from 192.168.A.1 <\/b>anything is sent to any port that is configured for forwarding inside to B.B.B.1 (for example, 11111), it also does not go into the VPN but simply goes through A.A.A.1<\/b> and arrives at B.B.B.1<\/b>, and that one forwards it somewhere to, say, 192.168.B.2:3389<\/b>. That one sees this packet not from 192.168.A.1<\/b>, but from A.A.A.1<\/b>. And, when 192.168.B.2<\/b> responds, the packet goes from B.B.B.1<\/b> to A.A.A.1,<\/b> and later reaches the connection initiator \u2014 192.168.A.1<\/b>.<\/p>\n

A specific example:<\/p>\n

1) 192.168.A.1<\/b> calls B.B.B.1<\/b>, wants to establish a TCP connection with B.B.B.1:11111<\/b>;<\/p>\n

2) 192.168.A.1<\/b> sends a request to establish a connection from 192.168.A.1:55555<\/b> , it does not exist, which means it forwards the packet via the default route (0.0.0.0\/0); B.B.B.1:11111<\/b>;<\/p>\n

3) the operating system that runs on the server with the address 192.168.A.1<\/b>, decides to send this packet to the gateway address of the router (192.168.A.254<\/b> in our case), because it does not have other, more specific routes for B.B.B.1<\/b>, so it sends the packet via the default route (0.0.0.0\/0);<\/p>\n

4) for this, as we mentioned in previous examples, it tries to find the MAC address for the IP address 192.168.A.254<\/b> in the ARP protocol cache table. If not found, it sends from the address 192.168.A.1<\/b> a broadcast who-has request to the network 192.168.A.0\/24<\/b>When 192.168.A.254<\/b> in response, it sends its MAC address to it, the system sends an Ethernet packet for it, and records this information in its cache table;<\/p>\n

5) The virtual router receives this packet and determines where to send it: it has a policy that requires it to NAT (modifying the source address) all packets from 192.168.A.0\/24<\/b> to other nodes of the Internet;<\/p>\n

6) since this policy requires the source address to match the lowest address on the interface through which this packet will be sent, the virtual router first decides to whom exactly to send this packet, and, as in the previous example, it must send it to A.A.A.254<\/b> (the internet service provider's gateway, which, in this case, is also us), because there are no more specific routes to B.B.B.1<\/b>, than 0.0.0.0\/0;<\/p>\n

7) thus, the virtual router replaces the source address of the packet, from now on it is a packet from A.A.A.1:44444<\/b> (the port number, of course, can be different) to B.B.B.1:11111<\/b>;<\/p>\n

8) The virtual router remembers what it did, thus, when from B.B.B.1:11111<\/b> for A.A.A.1:44444<\/b> comes in, it will know that it should change the address and port of the recipient to 192.168.A.1:55555<\/b>.<\/p>\n

9) now the virtual router must send it to the ISP's network through A.A.A.254<\/b>, therefore, just as we mentioned before, it finds the MAC address for A.A.A.254 <\/b>and sends the packet to the ISP gateway;<\/p>\n

10) Internet service providers transmit the packet through their networks from A.A.A.1 on B.B.B.1<\/b>;<\/p>\n

11) The router at B.B.B.1<\/b> receives this packet on port 11111;<\/p>\n

12) on the virtual router, there exists a rule that states that packets received from any sender on this port should be forwarded to 192.168.B.2:3389<\/b>;<\/p>\n

13) The router finds in the routing table the network 192.168.B.0\/24<\/b> and sends it directly to 192.168.B.2<\/b>, since it has an interface 192.168.B.254\/24<\/b>;<\/p>\n

14) For this, the virtual router finds the MAC address for 192.168.B.2<\/b> and sends this packet to it over a virtual Ethernet network;<\/p>\n

15) 192.168.B.2<\/b> receives this packet on port 3389, agrees to establish a connection and forms a response packet from 192.168.B.2:3389<\/b> to A.A.A.1:44444<\/b>;<\/p>\n

16) its system forwards this packet to the gateway address of the router (192.168.B.254<\/b> in our case), because it does not have other, more specific routes for A.A.A.1<\/b>, it does not have, so it must send the packet via the default route (0.0.0.0\/0);<\/p>\n

17) just as in previous cases, the system operating on the computer with the address 192.168.B.2<\/b>, finds the MAC address 192.168.B.254<\/b>, since it is in the same network as its interface 192.168.B.2\/24<\/b>;<\/p>\n

18) The router receives this packet. It is worth noting that it remembers what it received at B.B.B.1:11111<\/b> and changed its address and recipient port to A.A.A.1 <\/b>, therefore, for the packet from 192.168.B.2:3389<\/b>it changes the sender's address to 192.168.B.2:3389<\/b> for A.A.A.1:44444<\/b> 19) The virtual router decides to whom to send this packet, it sends it to B.B.B.1:11111<\/b>;<\/p>\n

19) The router determines to whom to forward this packet. It sends it to, let\u2019s say, B.B.B.254 <\/b>(the gateway of the Internet provider, the exact address of which we do not know), because there are no more specific routes to A.A.A.1<\/b>, than 0.0.0.0\/0;<\/p>\n

21) The router at B.B.B.1<\/b> to A.A.A.1<\/b>;<\/p>\n

21) the virtual router at A.A.A.1 <\/b>, it changed its sender address and port to 192.168.A.1:55555<\/b> for B.B.B.1:11111<\/b>, so this is a response that needs to be sent to A.A.A.1:44444<\/b>. Thus, this is the response that needs to be forwarded to 192.168.A.1:55555<\/b> (in fact, as we mentioned in the previous example, there are also several checks there, but this time we will not delve into them);<\/p>\n

22) it understands that it should send it directly to 192.168.A.1<\/b>, since it is on the same network, therefore, it has a corresponding entry in the routing table that causes it to send packets for all 192.168.A.0\/24<\/b> directly;<\/p>\n

23) the router finds the MAC address for 192.168.A.1<\/b> and forwards this packet to it;<\/p>\n

24) the operating system on the server with the address 192.168.A.1<\/b> receives the packet from B.B.B.1:1111<\/b>1 for 192.168.A.1:55555 <\/b>and initiates the next steps to establish a TCP connection.<\/p>\n

Just as in the previous case, in this case the server with the address 192.168.A.1<\/b> knows nothing about the computer with the address 192.168.B.1<\/b>, it only communicates with B.B.B.1<\/b>. The computer with the address 192.168.B.1<\/b> also knows nothing about the server with the address 192.168.A.1<\/b>. It believes that it has been contacted from the address A.A.A.1<\/b>, and the rest is hidden from it.<\/p>\n

Output<\/h3>\n

\nThis is how everything occurs during connections inside the VPN tunnel between the client's office and the cloud environment, as well as during connections outside the VPN tunnel. If you have any questions or need our help with cloud solutions, feel free to contact us 24\/7.<\/a><\/noindex>
\n
Source: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0418\u0437 \u043f\u0438\u0441\u0435\u043c \u0432 \u0441\u043b\u0443\u0436\u0431\u0443 \u0442\u0435\u0445\u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 Tucha \u0440\u043e\u0436\u0434\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0441\u0442\u0430\u0442\u044c\u0438. \u0422\u0430\u043a, \u043d\u0435\u0434\u0430\u0432\u043d\u043e \u043a \u043d\u0430\u043c \u043e\u0431\u0440\u0430\u0442\u0438\u043b\u0441\u044f \u043a\u043b\u0438\u0435\u043d\u0442 \u0441 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u043c \u0440\u0430\u0437\u044a\u044f\u0441\u043d\u0438\u0442\u044c, \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442 \u043f\u0440\u0438 \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f\u0445 \u0432\u043d\u0443\u0442\u0440\u0438 VPN-\u0442\u0443\u043d\u043d\u0435\u043b\u044f \u043c\u0435\u0436\u0434\u0443 \u043e\u0444\u0438\u0441\u043e\u043c \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0438 \u0441\u0440\u0435\u0434\u043e\u0439 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u0438 \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f\u0445 \u0432\u043d\u0435 VPN-\u0442\u0443\u043d\u043d\u0435\u043b\u044f. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u0432\u0435\u0441\u044c \u0442\u0435\u043a\u0441\u0442, \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043d\u043d\u044b\u0439 \u043d\u0438\u0436\u0435, \u2014 \u044d\u0442\u043e \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u0435 \u043f\u0438\u0441\u044c\u043c\u043e, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043c\u044b \u043e\u0442\u043f\u0440\u0430\u0432\u0438\u043b\u0438 \u043e\u0434\u043d\u043e\u043c\u0443 \u0438\u0437 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u0432 \u043e\u0442\u0432\u0435\u0442 \u043d\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":53573,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53572","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47What happens during connections inside and outside the VPN tunnel | ProHoster","description":"Real articles are born from emails sent to Tucha's support service.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/chto-proishodit-pri-soedineniyah-vnutri-i-vne-vpn-tunnelya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442 \u043f\u0440\u0438 \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f\u0445 \u0432\u043d\u0443\u0442\u0440\u0438 \u0438 \u0432\u043d\u0435 VPN-\u0442\u0443\u043d\u043d\u0435\u043b\u044f | ProHoster","og:description":"\u0418\u0437 \u043f\u0438\u0441\u0435\u043c \u0432 \u0441\u043b\u0443\u0436\u0431\u0443 \u0442\u0435\u0445\u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 Tucha \u0440\u043e\u0436\u0434\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0441\u0442\u0430\u0442\u044c\u0438.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/chto-proishodit-pri-soedineniyah-vnutri-i-vne-vpn-tunnelya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-04T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53572","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-04 15:17:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:22:50","updated":"2026-02-04 15:17:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/53572","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=53572"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/53572\/revisions"}],"predecessor-version":[{"id":156714,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/53572\/revisions\/156714"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/53573"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=53572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=53572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=53572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}