înregistrare Logare
Puncte:0
Robert Driller avatar Server

OpenVPN routing between subnets and LAN not working

drapel cn
Robert Driller

I have set up an openVPN server with topology subnet. It contains a set of subnets for clients in the region 10.0.X.X which are routed. In the Server network there is a client (not in VPN) that runs a service that the VPN users need to access.

So basically I try to give different user groups access to a webservice. Both openvpn and the webservice run in docker instances

ANY HELP OR TIP IS VERY MUCH APPRECIATED SINCE I AM FIGHTING WITH THIS SINCE 2 WEEKS NOW

Steps Taken: I setup openvpn conf with routes and with client-to-client

server 192.168.255.0 255.255.255.0
verb 3
key /etc/openvpn/pki/private/xxxx.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/xxxx.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
key-direction 0
keepalive 10 60
persist-key
persist-tun

proto udp
# Rely on Docker to do port mapping, internally always 1194
port 1194
dev tun
status /tmp/openvpn-status.log
topology subnet
client-config-dir ccd

user nobody
group nogroup
comp-lzo no
client-to-client

### Route Configurations Below
route 192.168.254.0 255.255.255.0
route 10.0.0.0 255.255.255.0
route 10.0.1.0 255.255.255.0
route 10.0.3.0 255.255.255.0
route 10.0.4.0 255.255.255.0
route 10.0.5.0 255.255.255.0

### Push Configurations Below
#push "block-outside-dns"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "comp-lzo no"
push "route 172.17.0.0 255.255.255.0"

I configured forwarding by setting net.ipv4.ip_forward = 1 in /etc/sysctl.conf

I configured the iptable rules

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -s 192.168.255.0/24 -d 172.17.0.0/24 -i tun0 -j ACCEPT
-A FORWARD -j ACCEPT
-A FORWARD -s 192.168.255.0/24 -d 10.0.0.0/24 -i tun0 -j ACCEPT

But from the IP in the server range (192.168.255.2) am unable to ping or access anything (172.17.0.4 or 10.0.0.1)

A traceroute ends at the gateway

% traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 52 byte packets
1 192.168.88.1 (192.168.88.1) 12.279 ms 3.251 ms 1.882 ms
2 *

here also the log from my client

2022-04-30 06:24:38.983758 *Tunnelblick: macOS 12.3.1 (21E258); Tunnelblick 3.8.5beta05 (build 5650)
2022-04-30 06:24:39.446714 *Tunnelblick: Attempting connection with greenhive_master using shadow copy; Set nameserver = 769; monitoring connection
2022-04-30 06:24:39.450786 *Tunnelblick: openvpnstart start greenhive_master.tblk 52399 769 0 1 0 34652464 -ptADGNWradsgnw 2.4.10-openssl-1.1.1j
2022-04-30 06:24:39.477788 *Tunnelblick: openvpnstart starting OpenVPN
2022-04-30 06:24:39.857743 OpenVPN 2.4.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Feb 25 2021
2022-04-30 06:24:39.857947 library versions: OpenSSL 1.1.1j  16 Feb 2021, LZO 2.10
2022-04-30 06:24:39.859534 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:52399
2022-04-30 06:24:39.859562 Need hold release from management interface, waiting...
2022-04-30 06:24:40.078894 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.10-openssl-1.1.1j/openvpn
          --daemon
          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Srobertk-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sgreenhive_master.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.52399.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5650 3.8.5beta05 (build 5650)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --management 127.0.0.1 52399 /Library/Application Support/Tunnelblick/geeielmngfddkiiidnhcaaaogadlpdifnpjaepip.mip
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2022-04-30 06:24:40.108790 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:52399
2022-04-30 06:24:40.136505 MANAGEMENT: CMD 'pid'
2022-04-30 06:24:40.136565 MANAGEMENT: CMD 'auth-retry interact'
2022-04-30 06:24:40.136595 MANAGEMENT: CMD 'state on'
2022-04-30 06:24:40.136615 MANAGEMENT: CMD 'state'
2022-04-30 06:24:40.136655 MANAGEMENT: CMD 'bytecount 1'
2022-04-30 06:24:40.138068 *Tunnelblick: Established communication with OpenVPN
2022-04-30 06:24:40.152091 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2022-04-30 06:24:40.154175 MANAGEMENT: CMD 'hold release'
2022-04-30 06:24:40.155529 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-04-30 06:24:40.161486 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-04-30 06:24:40.161545 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-04-30 06:24:40.161718 MANAGEMENT: >STATE:1651292680,RESOLVE,,,,,,
2022-04-30 06:24:40.259123 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:40.259272 Socket Buffers: R=[786896->786896] S=[9216->9216]
2022-04-30 06:24:40.259296 UDP link local: (not bound)
2022-04-30 06:24:40.259311 UDP link remote: [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:40.259354 MANAGEMENT: >STATE:1651292680,WAIT,,,,,,
2022-04-30 06:24:40.305386 MANAGEMENT: >STATE:1651292680,AUTH,,,,,,
2022-04-30 06:24:40.305631 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=06c4262e 884c5cdc
2022-04-30 06:24:40.369493 VERIFY OK: depth=1, CN=greenhive
2022-04-30 06:24:40.370236 VERIFY KU OK
2022-04-30 06:24:40.370275 Validating certificate extended key usage
2022-04-30 06:24:40.370301 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2022-04-30 06:24:40.370323 VERIFY EKU OK
2022-04-30 06:24:40.370346 VERIFY OK: depth=0, CN=VPN.greenhive.at
2022-04-30 06:24:40.439317 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542'
2022-04-30 06:24:40.439596 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
2022-04-30 06:24:40.439767 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2022-04-30 06:24:40.439834 [VPN.greenhive.at] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:41.558800 MANAGEMENT: >STATE:1651292681,GET_CONFIG,,,,,,
2022-04-30 06:24:41.559492 SENT CONTROL [VPN.greenhive.at]: 'PUSH_REQUEST' (status=1)
2022-04-30 06:24:41.652600 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,comp-lzo no,route 172.17.0.0 255.255.255.0,route-gateway 192.168.255.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.255.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'
2022-04-30 06:24:41.652921 OPTIONS IMPORT: timers and/or timeouts modified
2022-04-30 06:24:41.652958 OPTIONS IMPORT: compression parms modified
2022-04-30 06:24:41.652985 OPTIONS IMPORT: --ifconfig/up options modified
2022-04-30 06:24:41.653008 OPTIONS IMPORT: route options modified
2022-04-30 06:24:41.653030 OPTIONS IMPORT: route-related options modified
2022-04-30 06:24:41.653051 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2022-04-30 06:24:41.653072 OPTIONS IMPORT: peer-id set
2022-04-30 06:24:41.653094 OPTIONS IMPORT: adjusting link_mtu to 1624
2022-04-30 06:24:41.653115 OPTIONS IMPORT: data channel crypto options modified
2022-04-30 06:24:41.653139 Data Channel: using negotiated cipher 'AES-256-GCM'
2022-04-30 06:24:41.653816 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-04-30 06:24:41.653851 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-04-30 06:24:41.654722 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2022-04-30 06:24:41.654977 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2022-04-30 06:24:41.655036 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2022-04-30 06:24:41.655181 Opened utun device utun3
2022-04-30 06:24:41.655203 MANAGEMENT: >STATE:1651292681,ASSIGN_IP,,192.168.255.2,,,,
2022-04-30 06:24:41.655217 /sbin/ifconfig utun3 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2022-04-30 06:24:41.665109 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2022-04-30 06:24:41.666818 /sbin/ifconfig utun3 192.168.255.2 192.168.255.2 netmask 255.255.255.0 mtu 1500 up
2022-04-30 06:24:41.672645 /sbin/route add -net 192.168.255.0 192.168.255.2 255.255.255.0
                           add net 192.168.255.0: gateway 192.168.255.2
2022-04-30 06:24:41.679237 MANAGEMENT: >STATE:1651292681,ADD_ROUTES,,,,,,
2022-04-30 06:24:41.679318 /sbin/route add -net 172.17.0.0 192.168.255.1 255.255.255.0
                           add net 172.17.0.0: gateway 192.168.255.1
                           06:24:41 *Tunnelblick:  **********************************************
                           06:24:41 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           06:24:43 *Tunnelblick:  Retrieved from OpenVPN: name server(s) [ 8.8.8.8 8.8.4.4 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
                           06:24:44 *Tunnelblick:  WARNING: Ignoring DomainName 'openvpn' because DomainName was set manually and '-allowChangesToManuallySetNetworkSettings' was not specified
                           06:24:44 *Tunnelblick:  WARNING: Ignoring ServerAddresses '8.8.8.8 8.8.4.4' because ServerAddresses was set manually and '-allowChangesToManuallySetNetworkSettings' was not specified
                           06:24:44 *Tunnelblick:  Setting search domains to '8.8.8.8 8.8.4.4' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected
                           06:24:45 *Tunnelblick:  Saved the DNS and SMB configurations so they can be restored
                           06:24:45 *Tunnelblick:  Did not change DNS ServerAddresses setting of '8.8.8.8 8.8.4.4' (but re-set it)
                           06:24:45 *Tunnelblick:  Changed DNS SearchDomains setting from 'openvpn' to '8.8.8.8 8.8.4.4'
                           06:24:45 *Tunnelblick:  Changed DNS DomainName setting from '' to '8.8.8.8 8.8.4.4'
                           06:24:45 *Tunnelblick:  Did not change SMB NetBIOSName setting of ''
                           06:24:45 *Tunnelblick:  Did not change SMB Workgroup setting of ''
                           06:24:45 *Tunnelblick:  Did not change SMB WINSAddresses setting of ''
                           06:24:45 *Tunnelblick:  DNS servers '8.8.8.8 8.8.4.4' were set manually
                           06:24:45 *Tunnelblick:  DNS servers '8.8.8.8 8.8.4.4' will be used for DNS queries when the VPN is active
                           06:24:45 *Tunnelblick:  The DNS servers include only free public DNS servers known to Tunnelblick.
                           06:24:45 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           06:24:45 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           06:24:45 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           06:24:45 *Tunnelblick:  Not notifying mDNSResponderHelper that the DNS cache was flushed because it is not running
                           06:24:45 *Tunnelblick:  Setting up to monitor system configuration with process-network-changes
                           06:24:45 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           06:24:45 *Tunnelblick:  **********************************************
2022-04-30 06:24:45.352811 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2022-04-30 06:24:45.352830 Initialization Sequence Completed
2022-04-30 06:24:45.352845 MANAGEMENT: >STATE:1651292685,CONNECTED,SUCCESS,192.168.255.2,xx.xx.xx.xx,1194,,
2022-04-30 06:24:46.571157 *Tunnelblick: Routing info stdout:
   route to: 8.8.4.4
destination: 8.8.4.4
    gateway: 192.168.88.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
stderr:

2022-04-30 06:24:46.593014 *Tunnelblick: Warning: DNS server Address 8.8.4.4 is a known public DNS server but is not being routed through the VPN
2022-04-30 06:24:46.680197 *Tunnelblick: Routing info stdout:
   route to: 8.8.8.8
destination: 8.8.8.8
    gateway: 192.168.88.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
stderr:

2022-04-30 06:24:46.705581 *Tunnelblick: Warning: DNS server Address 8.8.8.8 is a known public DNS server but is not being routed through the VPN

EDIT: here the ip route of the server

bash-5.0# ip route 
default via 172.17.0.1 dev eth0 
10.0.0.0/24 via 192.168.255.2 dev tun0 
10.0.1.0/24 via 192.168.255.2 dev tun0 
10.0.3.0/24 via 192.168.255.2 dev tun0 
172.17.0.0/16 dev eth0 proto kernel scope link src 
172.17.0.2 192.168.254.0/24 via 192.168.255.2 dev tun0 192.168.255.0/24 dev tun0 proto kernel scope link src 192.168.255.1

Of the client

172.17/24          192.168.255.2      UGSc            utun3

Statuslog

bash-5.0# cat /tmp/openvpn-status.log
OpenVPN CLIENT LIST
Updated,Sun May  1 08:20:48 2022
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
at_dev_1,179.115.236.15:34846,23335,23021,Sun May  1 07:14:26 2022
master,179.115.236.15:64773,9574,9889,Sun May  1 07:55:44 2022
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
192.168.255.2,master,179.115.236.15:64773,Sun May  1 07:55:44 2022
10.0.0.1,at_dev_1,179.115.236.15:34846,Sun May  1 07:14:26 2022
GLOBAL STATS
Max bcast/mcast queue length,1
END

EDIT here an image to show the situation Graphical explanation

80
0 + 0
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Vă rugăm să afișați ieșirea „ip route” a sistemelor afectate când este stabilită conexiunea VPN și ieșirea comenzii „status” în interfața de gestionare OpenVPN (pentru a afișa rutele interne și alte stări). Puteți masca IP-urile publice, dar păstrați absolut toate adresele private așa cum sunt. De asemenea, vreau să remarc că „topologia” nu are nimic de-a face cu modul în care așezați rețelele în afara OpenVPN. Își stabilește doar funcționarea internă. Modul `topology subnet` face ca OpenVPN în sine un router și asta necesită configurarea rutelor *interne* în el, cu ajutorul comenzilor `iroute` care intră în fișierele CCD.
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Vă rugăm, introduceți rezultatul de rutare în întrebare prin [editare](https://serverfault.com/posts/1099885/edit) și eliminați din comentariu; rupe liniile noi în comentariu, așa că este de necitit. De asemenea, am întrebat o ieșire *management* `status`. Arată elementele interne de care avem nevoie aici. Este crucial în modul `subrețea`, deoarece va afișa un tabel de rutare intern procesului OpenVPN în sine. // Observați, am vorbit despre `iroute`, nu despre traseul push și așa mai departe.Citiți `man openvpn` despre acea comandă și ce face.
0
Răspunde
Robert Driller avatar
drapel cn
Robert Driller
Scuze pentru asta, l-am ajustat. Am mai citit și eu pe iroute. Vă rog să mă corectați dacă greșesc, dar înțeleg că este o rutare specială în cazul în care vreau să mă conectez la o adresă care este „accesabilă” de la un **client** VPN. Dar, din moment ce adresa pe care vreau să o contactez se află în LAN-ul **serverului** VPN și vreau ca toți clienții să o poată contacta, push route nu este calea corectă? Am primit asta de la https://backreference.org/2009/11/15/openvpn-and-iroute/index.html
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Da, scriu un răspuns cu explicații. Nu este chiar „ascuns în spatele clientului”, dar este rutarea care se întâmplă în interiorul procesului OpenVPN de pe server.
0
Răspunde
Puncte:0
Nikita Kipriyanov avatar Server
drapel za
Nikita Kipriyanov

Deci vedem că nu aveți rute interne în OpenVPN. Probabil că asta vine din faptul că nu folosești niciunul iroute declarații din configurația dvs. De aceea, doar adresele VPN ale serverului și ale clienților sunt accesibile unul altuia.

Structura generală a VPN-ului „subrețea de topologie” OpenVPN arată astfel din perspectiva rețelei (OSI L3):

                                          192.168.255.10[tun] (client2) [eth] 10.0.2.1 --- ...
                                                   |
                                              [client2].9 [eth] 10.0.1.1 --- ...
(server) [tun]192.168.255.1 --- .2[server] (proces OpenVPN) [client1].5 --- 192.168.255.6[tun] (client1)
[eth] 10.0.0.1 --- ... .13[client3]
                                                   |
         ... --- 10.0.3.1 [eth] (client3) [tun]192.168.255.14

În acest exemplu cu trei clienți, procesul OpenVPN arată ca un router cu patru interfețe (una este orientată spre server). Acest router are nevoie și de setare de rutare! Acesta este ce iroute cuvântul cheie nu.

Deci, pentru clienții să ajungă la o rețea 10.0.0.0/24 în spatele serverului, ei au nevoie de o rută către acea rețea prin „adresa” respectivă orientată către client OpenVPN (de exemplu, client1 are nevoie de ruta ip adăugați 10.0.0.0/24 prin 192.168.255.5). Aceste rute le împinge cu „push route”. Pentru a ajunge la rețele în spatele altor clienți, faceți rute similare; în cazul meu exemplu, aceste rețele sunt consecutive și toate ar putea fi condensate într-un singur apăsați „route 10.0.0.0 255.255.252.0”.

De asemenea, „routerul” OpenVPN are nevoie de rute adecvate către aceste rețele prin adrese „client”. De exemplu, rețeaua 10.0.1.0/24 ar trebui direcționată prin 192.168.255.6. Pentru a face acest lucru, un server trebuie să ruleze un iroute 10.0.1.0 255.255.255.0 în numele client1. Pentru a realiza acest lucru, puneți

iroute 10.0.1.0 255.255.255.0

în client1 fișier în directorul de configurare a clientului (CCD), astfel încât să fie executat imediat după clientul cu numele comun client1 se autentifică cu succes.

Rețelele din spatele serverului nu au nevoie iroute. Se pare că folosește „interfața” serverului ca poartă de ultimă instanță.

0 + 0
Robert Driller avatar
drapel cn
Robert Driller
Vă mulțumesc foarte mult pentru răspunsul detaliat, doar pentru a mă asigura că am înțeles corect. Informațiile de rutare din partea clientului prin ruta push nu sunt suficiente, serverul are nevoie și de rutare folosind iroute direct în configurația serverului. Am adăugat iroute astfel `iroute 172.17.0.0 255.255.255.0` în configurația serverului, dar când pornesc openVPN îmi spune că: `Eroare de opțiuni: opțiunea 'iroute' nu poate fi folosită în acest context (/etc/openvpn/ openvpn.conf) Folosiți --help pentru mai multe informații.` Am înțeles greșit ultimul tău paragraf?
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Da, pentru că este greșit. Îmi amintește că ar trebui să recitesc întotdeauna manualul, chiar dacă l-am citit deja de multe ori. Se pare că direcționează prin server în mod implicit, de ex. folosește un server ca poartă de ultimă instanță. Acest lucru ar explica de ce subrețelele de server nu au nevoie de iroute. Problema dvs. inițială este că le-ați dat clienților adrese incompatibile cu rețeaua VPN cumva. Subrețelele sunt rețele /30 sculptate din spațiul de adrese VPN; dacă ați ales `192.168.255.1 255.255.255.0" ca IP al serverului, clienții dvs. vor avea 192.168.255.6/30, .10, .14 etc. alocat interfeței lor `tun`.
0
Răspunde
Robert Driller avatar
drapel cn
Robert Driller
Îmi pare rău că m-ai pierdut acolo. Înțeleg că fiecare dintre subrețelele mele (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 etc.) are o interfață tun alocată cu spațiu /30. Ar însemna asta că sunt posibile doar 127 de subrețele, deoarece fiecare își rezervă 2 adrese? Și dacă toată comunicarea este direcționată prin server, atunci de ce nu mi-ar direcționa apelul către adresa 172.14.0.4 din spatele serverului oVPN?
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.