Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Sommig HTTPS verkeer werkt niet over VPN

Pagina: 1
Acties:

  • martijndierckx
  • Registratie: Maart 2007
  • Laatst online: 10-10 12:24
Hi

Ik heb een site-to-site VPN draaien naar een VPN machine bij DigitalOcean. Alles lijkt daar moeiteloos over te werken.
Echter gaan bepaalde websites op HTTPS niet open wanneer ik op de VPN zit, waar dat wel perfect lukt als de VPN niet aanstaat.

Bij nadere inspectie bemerk ik het volgende:

- Vanaf een client achter de VPN, kan ik website X wel bereiken via HTTP
- Vanaf een client achter de VPN, kan ik website X niet bereiken via HTTPS. Ik krijg volgende output bij een 'curl -v' (hij blijft hangen bij de handshake):
code:
1
2
3
4
5
6
7
8
9
10
* Rebuilt URL to: https://de-entourage.be/
*   Trying 185.56.145.138...
* TCP_NODELAY set
* Connected to de-entourage.be (185.56.145.138) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

- Vanaf de VPN server bij DigitalOcean, kan ik website X wel bereiken via HTTPS. Ik krijg daar volgende output bij een 'curl -v':
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
* Rebuilt URL to: https://de-entourage.be/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 185.56.145.138...
* TCP_NODELAY set
* Connected to de-entourage.be (185.56.145.138) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [213 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2874 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=de-entourage.be
*  start date: Apr 20 00:43:39 2018 GMT
*  expire date: Jul 19 00:43:39 2018 GMT
*  subjectAltName: host "de-entourage.be" matched cert's "de-entourage.be"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x564bf1c288e0)
} [5 bytes data]
> GET / HTTP/2
> Host: de-entourage.be
> User-Agent: curl/7.58.0
> Accept: */*
> 
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
< HTTP/2 200 
< date: Fri, 01 Jun 2018 11:29:06 GMT
< server: Apache
< last-modified: Fri, 17 Nov 2017 08:17:17 GMT
< etag: "449bc-55e295d6dbef9"
< accept-ranges: bytes
< content-length: 281020
< vary: Accept-Encoding,User-Agent
< content-type: text/html; charset=utf-8
< 
{ [5 bytes data]
100  274k  100  274k    0     0  3708k      0 --:--:-- --:--:-- --:--:-- 3759k
* Connection #0 to host de-entourage.be left intact


Any ideas?

  • Thralas
  • Registratie: December 2002
  • Laatst online: 11:12
Je MTU staat verkeerd.

  • martijndierckx
  • Registratie: Maart 2007
  • Laatst online: 10-10 12:24
Dit stukje in mijn iptables heeft het gefixed:

code:
1
2
3
4
5
6
7
8
9
# MSS is the TCP Max Segment Size
# Setting the 'max_mss' Ansible variable can solve some issues related to packet fragmentation
# This appears to be necessary on (at least) Google Cloud,
# however, some routers also require a change to this parameter
# See also:
# - https://github.com/trailofbits/algo/issues/216
# - https://github.com/trailofbits/algo/issues?utf8=%E2%9C%93&q=is%3Aissue%20mtu
# - https://serverfault.com/questions/601143/ssh-not-working-over-ipsec-tunnel-strongswan
-A FORWARD -s 192.168.6.0/24 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

  • Thralas
  • Registratie: December 2002
  • Laatst online: 11:12
1360 is wel heel conservatief.

Je kunt het ook beter op de interface zetten, dan werkt het ook voor UDP-verkeer.

[ Voor 4% gewijzigd door Thralas op 02-06-2018 18:12 ]