Publiek IP wijzigt niet

[wapzil]

Beste Tweakers,

Ik probeer thuis een VPN server te installeren, alleen krijg ik het niet voor elkaar om mijn publieke IP adres om te zetten naar een private IP adres (als ik dat goed uitleg).
Hopelijk kunnen/willen jullie een “newbie” verder helpen.

Vooraf informatie:
01: Internet komt binnen in meterkast via internet provider.
02: Dit is aangesloten op een home modem/router (experia box v10).
03: Het interne netwerk van deze modem/router is: 192.168.7.X (heb ik gewijzigd omdat ik begrijp dat het standaard adres 192.168.1.0/24 vaker gebruikt wordt).
04: Vervolgens is er een laptop aangesloten via een internet kabel naar de modem/router.
(Deze laptop heeft maar één internet poort).
05: Laptop OS = Ubuntu 18.02 (server).
06: Ubuntu heeft onderstaande netwerk instellingen (static ip):
subnet: 192.168.7.0/24
Address: 192.168.7.40
Gateway: 192.168.7.254
Servers: 1.1.1.1, 1.0.0.1

Home router informatie:
OpenVPN poort 443
OpenVPN UDP
OpenVPN naar: 192.168.7.40 port ipv4 forward.

VPN informatie:
01: Ik gebruik OpenVPN als server software via command-line(sudo apt-get install openvpn easy-rsa.
(Na 100x proberen gebruik in inmiddels een script wat het configureren voor me uitvoert om tijd te besparen).
02: OpenVPN server.conf is als volgt:
port 443
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1 bypass-dhcp"
crl-verify crl.pem
ca ca.crt
cert server_XXXXX.crt
key server_XXXXX.key
tls-auth tls-auth.key 0
dh dh.pem
auth SHA256
cipher AES-128-CBC
tls-server
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
status openvpn.log
verb 3

03: OpenVPN client.conf is als volgt:
client
proto udp
remote XX.XX.XXX.XXX 443
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_pR80eUJ2w46IdsNB name
auth SHA256
auth-nocache
cipher AES-128-CBC
tls-client
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
setenv opt block-outside-dns
verb 3
<ca>
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----
</ca>
<cert>
</key>
key-direction 1
<tls-auth>


04: Tunnelblick log is als volgt:
*Tunnelblick: OS X 10.13.6; Tunnelblick 3.7.6a (build 5080)
2018-08-19 11:10:03 *Tunnelblick: Attempting connection with martmac; Set nameserver = 769; monitoring connection
2018-08-19 11:10:03 *Tunnelblick: openvpnstart start martmac.tblk 52772 769 0 3 0 1065264 -ptADGNWradsgnw 2.4.6-openssl-1.0.2o
2018-08-19 11:10:03 *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.6-openssl-1.0.2o/openvpn
--daemon
--log
/Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Smartmac.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_0_1065264.52772.openvpn.log
--cd
/Library/Application Support/Tunnelblick/Shared/martmac.tblk/Contents/Resources
--setenv
IV_GUI_VER
"net.tunnelblick.tunnelblick 5080 3.7.6a (build 5080)"
--verb
3
--config
/Library/Application Support/Tunnelblick/Shared/martmac.tblk/Contents/Resources/config.ovpn
--verb
3
--cd
/Library/Application Support/Tunnelblick/Shared/martmac.tblk/Contents/Resources
--management
127.0.0.1
52772
/Library/Application Support/Tunnelblick/cnkknmkmaedcdillmcpkbmbhfoimcnibpcdjgilf.mip
--management-query-passwords
--management-hold
--script-security
2
--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

Disabled IPv6 for 'iPhone USB'
Retrieved from OpenVPN: name server(s) [ 1.0.0.1 1.1.1.1 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
WARNING: Ignoring ServerAddresses '1.0.0.1 1.1.1.1' because ServerAddresses was set manually and '-allowChangesToManuallySetNetworkSettings' was not specified
Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected
Saved the DNS and SMB configurations so they can be restored
Did not change DNS ServerAddresses setting of '1.1.1.1 1.0.0.1 156.154.70.1 156.154.71.1' (but re-set it)
Changed DNS SearchDomains setting from '' to 'openvpn'
Changed DNS DomainName setting from 'home' to 'openvpn'
Did not change SMB NetBIOSName setting of ''
Did not change SMB Workgroup setting of ''
Did not change SMB WINSAddresses setting of ''
DNS servers '1.1.1.1 1.0.0.1 156.154.70.1 156.154.71.1' were set manually
DNS servers '1.1.1.1 1.0.0.1 156.154.70.1 156.154.71.1' will be used for DNS queries when the VPN is active
NOTE: The DNS servers include one or more free public DNS servers known to Tunnelblick and one or more DNS servers not known to Tunnelblick. If used, the DNS servers not known to Tunnelblick may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.
Flushed the DNS cache via dscacheutil
/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
Notified mDNSResponder that the DNS cache was flushed
Setting up to monitor system configuration with process-network-changes
End of output from client.up.tunnelblick.sh
**********************************************
2018-08-19 11:10:03 *Tunnelblick: Established communication with OpenVPN
2018-08-19 11:10:03 Unrecognized option or missing or extra parameter(s) in /Library/Application Support/Tunnelblick/Shared/martmac.tblk/Contents/Resources/config.ovpn:17: block-outside-dns (2.4.6)
2018-08-19 11:10:03 OpenVPN 2.4.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jun 25 2018
2018-08-19 11:10:03 library versions: OpenSSL 1.0.2o 27 Mar 2018, LZO 2.10
2018-08-19 11:10:03 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:52772
2018-08-19 11:10:03 Need hold release from management interface, waiting...
2018-08-19 11:10:03 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:52772
2018-08-19 11:10:03 MANAGEMENT: CMD 'pid'
2018-08-19 11:10:03 MANAGEMENT: CMD 'state on'
2018-08-19 11:10:03 MANAGEMENT: CMD 'state'
2018-08-19 11:10:03 MANAGEMENT: CMD 'bytecount 1'
2018-08-19 11:10:03 MANAGEMENT: CMD 'hold release'
2018-08-19 11:10:03 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-08-19 11:10:03 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2018-08-19 11:10:03 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2018-08-19 11:10:03 TCP/UDP: Preserving recently used remote address: [AF_INET]XX.XX.XXX.XXX:443
2018-08-19 11:10:03 Socket Buffers: R=[196724->196724] S=[9216->9216]
2018-08-19 11:10:03 UDP link local: (not bound)
2018-08-19 11:10:03 UDP link remote: [AF_INET]XX.XX.XXX.XXX:443
2018-08-19 11:10:03 MANAGEMENT: >STATE:1534669803,WAIT,,,,,,
2018-08-19 11:10:03 MANAGEMENT: >STATE:1534669803,AUTH,,,,,,
2018-08-19 11:10:03 TLS: Initial packet from [AF_INET]XX.XX.XXX.XXX:443, sid=24fdeb3f 8f4564a4
2018-08-19 11:10:03 VERIFY OK: depth=1, CN=cn_oll81In5TxqhiGXU
2018-08-19 11:10:03 VERIFY KU OK
2018-08-19 11:10:03 Validating certificate extended key usage
2018-08-19 11:10:03 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2018-08-19 11:10:03 VERIFY EKU OK
2018-08-19 11:10:03 VERIFY X509NAME OK: CN=server_pR80eUJ2w46IdsNB
2018-08-19 11:10:03 VERIFY OK: depth=0, CN=server_pR80eUJ2w46IdsNB
2018-08-19 11:10:03 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 4096 bit RSA
2018-08-19 11:10:03 [server_pR80eUJ2w46IdsNB] Peer Connection Initiated with [AF_INET]XX.XX.XXX.XXX:443
2018-08-19 11:10:03 *Tunnelblick: openvpnstart starting OpenVPN
2018-08-19 11:10:04 MANAGEMENT: >STATE:1534669804,GET_CONFIG,,,,,,
2018-08-19 11:10:04 SENT CONTROL [server_pR80eUJ2w46IdsNB]: 'PUSH_REQUEST' (status=1)
2018-08-19 11:10:04 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 1.0.0.1,dhcp-option DNS 1.1.1.1,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2018-08-19 11:10:04 OPTIONS IMPORT: timers and/or timeouts modified
2018-08-19 11:10:04 OPTIONS IMPORT: --ifconfig/up options modified
2018-08-19 11:10:04 OPTIONS IMPORT: route options modified
2018-08-19 11:10:04 OPTIONS IMPORT: route-related options modified
2018-08-19 11:10:04 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2018-08-19 11:10:04 OPTIONS IMPORT: peer-id set
2018-08-19 11:10:04 OPTIONS IMPORT: adjusting link_mtu to 1624
2018-08-19 11:10:04 OPTIONS IMPORT: data channel crypto options modified
2018-08-19 11:10:04 Data Channel: using negotiated cipher 'AES-256-GCM'
2018-08-19 11:10:04 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2018-08-19 11:10:04 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2018-08-19 11:10:04 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2018-08-19 11:10:04 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2018-08-19 11:10:04 Opened utun device utun2
2018-08-19 11:10:04 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2018-08-19 11:10:04 MANAGEMENT: >STATE:1534669804,ASSIGN_IP,,10.8.0.2,,,,
2018-08-19 11:10:04 /sbin/ifconfig utun2 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2018-08-19 11:10:04 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2018-08-19 11:10:04 /sbin/ifconfig utun2 10.8.0.2 10.8.0.2 netmask 255.255.255.0 mtu 1500 up
2018-08-19 11:10:04 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.2
2018-08-19 11:10:04 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun2 1500 1552 10.8.0.2 255.255.255.0 init
**********************************************
Start of output from client.up.tunnelblick.sh
2018-08-19 11:10:08 *Tunnelblick: No 'connected.sh' script to execute
2018-08-19 11:10:08 /sbin/route add -net XX.XX.XXX.XXX 192.168.7.254 255.255.255.255
add net XX.XX.XXX.XXX: gateway 192.168.7.254
2018-08-19 11:10:08 /sbin/route add -net 0.0.0.0 10.8.0.1 128.0.0.0
add net 0.0.0.0: gateway 10.8.0.1
2018-08-19 11:10:08 /sbin/route add -net 128.0.0.0 10.8.0.1 128.0.0.0
add net 128.0.0.0: gateway 10.8.0.1
2018-08-19 11:10:08 Initialization Sequence Completed
2018-08-19 11:10:08 MANAGEMENT: >STATE:1534669808,CONNECTED,SUCCESS,10.8.0.2,XX.XX.XXX.XXX,443,,
2018-08-19 11:10:13 *Tunnelblick process-network-changes: A system configuration change was ignored
2018-08-19 11:10:13 *Tunnelblick: This computer's apparent public IP address (XX.XX.XXX.XXX) was unchanged after the connection was made.

Hoofdvraag: Waarom wordt mijn public ip adres niet omgezet naar het verwachte interne IP adres 10.8.0.0.X?
Hoe en waar configureer ik de benodigde wijzigingen om het wel werkbaar te maken?

[MAX3400]

Euh, een VPN verbinding zorgt, in jouw geval, voor een "versleutelde" verbinding van buiten naar binnen. Dan krijg je een 10.x.x.x adres, zoals geconfigureerd. Als je dan met je verbonden device wil internetten, ga je via je normale route weer naar buiten en heb je het publieke adres "whatever" wat je van je ISP krijgt.

Of ik begrijp echt ie vraag niet?

[Room42]

Hoe kan een 10.x.x.x-adres ooit publiek worden? Antwoord: Dat kan niet. Als je je publieke adres test met een publieke service (zoals https://api.ipify.org/) ga je altijd een publiek IP-adres krijgen. En als je thuis je OpenVPN-server draait, zul je dus het publieke IP-adres van je thuisverbinding krijgen. Kort gezegd: Je krijgt het publieke IP-adres van de VPN-server.

[donny007]

Wat probeer je te bereiken, en hoe test je het precies?

Wil je vanaf buitenaf verbinding kunnen maken met je thuisnetwerk om interne apparaten te benaderen? Wil je ook kunnen internetten via de VPN verbinding?

[Brahiewahiewa]

wapzil schreef op zondag 19 augustus 2018 @ 11:21:
…Hoofdvraag: Waarom wordt mijn public ip adres niet omgezet naar het verwachte interne IP adres 10.8.0.0.X?

@MAX3400 zet je een beetje op het verkeerde been. Een vpnserver hoeft niet persé van buiten naar binnen te werken; hij kan ook van binnen naar buiten werken. En ook - zoals in jouw geval - van binnen naar binnen.

Je gaat nu via de moeilijke weg naar buiten: je krijgt een 10.8.0.0/24 adres, dat wordt door je router gerouteerd naar het internet, maar gaat daarbij nog steeds via jouw publieke ip naar buiten. En da's maar goed ook, want een 10.8.0.0/24 adres wordt niet gerouteerd op het internet. Lees RFC1918 er maar op na.

[wapzil]

donny007 schreef op zondag 19 augustus 2018 @ 11:37:
Wat probeer je te bereiken, en hoe test je het precies?

Wil je vanaf buitenaf verbinding kunnen maken met je thuisnetwerk om interne apparaten te benaderen? Wil je ook kunnen internetten via de VPN verbinding?

Beste donny007,

Bedankt voor je reactie.

Ik wil inderdaad vanaf buitenaf verbinding kunnen maken met het interne netwerk om interne apparaten te kunnen benaderen.
Dat hiervoor het publieke ip adres van mijn ISP gebruikt wordt kan ik nog volgen.
Vervolgens wil ik dat de connectie soort van omgeleid wordt naar het 10.X.X.X adres naar buiten toe.
Waarbij ik er ook mee wil kunnen internetten.

[MAX3400]

wapzil schreef op zondag 19 augustus 2018 @ 13:27:
[...]


Beste donny007,

Bedankt voor je reactie.

Ik wil inderdaad vanaf buitenaf verbinding kunnen maken met het interne netwerk om interne apparaten te kunnen benaderen.
Dat hiervoor het publieke ip adres van mijn ISP gebruikt wordt kan ik nog volgen.
Vervolgens wil ik dat de connectie soort van omgeleid wordt naar het 10.X.X.X adres naar buiten toe.
Waarbij ik er ook mee wil kunnen internetten.

Zoals @Brahiewahiewa zegt: een 10-adres kan je niet publiekelijk naar buiten routeren als een 10-adres. Middels NAT gebruik je voor internetten dus je publieke adres.

[wapzil]

MAX3400 schreef op zondag 19 augustus 2018 @ 11:27:
Euh, een VPN verbinding zorgt, in jouw geval, voor een "versleutelde" verbinding van buiten naar binnen. Dan krijg je een 10.x.x.x adres, zoals geconfigureerd. Als je dan met je verbonden device wil internetten, ga je via je normale route weer naar buiten en heb je het publieke adres "whatever" wat je van je ISP krijgt.

Of ik begrijp echt ie vraag niet?

Beste MAX3400,

Hartelijk dank voor je reactie.
Nu moet ik toegeven dat mijn technische kennis omtrent VPN nogal beperkt is.
Alleen als ik youtube video's volg over hoe ik een VPN verbinding opzet, dan denk ik te begrijpen dat een public ip adres van de ISP juist wel omgezet kan worden naar een 10.X adres.

Vanaf 27 minuten wordt weergegeven dat het IP adres gewijzigd wordt.
YouTube: OpenVPN Setup for Ubuntu (18.04) in Terminal

Waarschijnlijk begrijp ik het niet goed, maar ik probeer het proces verder te ontdekken.

[ Voor 3% gewijzigd door wapzil op 19-08-2018 13:33 ]

[Thralas]

wapzil schreef op zondag 19 augustus 2018 @ 13:27:
Ik wil inderdaad vanaf buitenaf verbinding kunnen maken met het interne netwerk om interne apparaten te kunnen benaderen.

Dat is zo te zien gelukt.

Vervolgens wil ik dat de connectie soort van omgeleid wordt naar het 10.X.X.X adres naar buiten toe.
Waarbij ik er ook mee wil kunnen internetten.

Als ik het goed begrijp wil dat je internetverbinding altijd 'via thuis' loopt, ook als je onderweg bent? Ook dat lijkt gelukt, daar is de redirect-gateway-optie voor (die je ook gebruikt).

Test het nog even door via een mobiele verbinding naar je VPN te verbinden.

Het enige probleem zit volgens mij tussen je oren.

dan denk ik te begrijpen dat een public ip adres van de ISP juist wel omgezet kan worden naar een 10.X adres.

Dat begrijp je verkeerd. In het filmpje zie je dat er een 10.8.0.X-adres wordt toegewezen. Dat is een lokaal adres, net als 192.168.X.Y. Dit adres wordt enkel gebruikt voor communicatie met de VPN-server, en wordt meermaals omgezet (NAT) voor je verbinding van een publiek adres lijkt te komen.

Eerst NAT je VPN server je 10.8.0.X-adres naar 192.168.7.40, vervolgens NAT je router het naar het publieke IP van je ISP.

[ Voor 6% gewijzigd door Thralas op 19-08-2018 13:50 ]

[wapzil]

Thralas schreef op zondag 19 augustus 2018 @ 13:48:
[...]


Dat is zo te zien gelukt.


[...]


Als ik het goed begrijp wil dat je internetverbinding altijd 'via thuis' loopt, ook als je onderweg bent? Ook dat lijkt gelukt, daar is de redirect-gateway-optie voor (die je ook gebruikt).

Test het nog even door via een mobiele verbinding naar je VPN te verbinden.

Het enige probleem zit volgens mij tussen je oren.


[...]


Dat begrijp je verkeerd. In het filmpje zie je dat er een 10.8.0.X-adres wordt toegewezen. Dat is een lokaal adres, net als 192.168.X.Y. Dit adres wordt enkel gebruikt voor communicatie met de VPN-server, en wordt meermaals omgezet (NAT) voor je verbinding van een publiek adres lijkt te komen.

Eerst NAT je VPN server je 10.8.0.X-adres naar 192.168.7.40, vervolgens NAT je router het naar het publieke IP van je ISP.

Quote

Beste Thralas,

Hartelijk dank voor je reactie.
Ik denk dat ik het nu begrijp.

Ook alle andere bedankt voor jullie reactie!
Heel fijn dat jullie allemaal met me mee wilde denken