Vraag


Acties:
  • 0 Henk 'm!

  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Hallo Allemaal,

Ik had afgelopen week al een poging gedaan in het grote unifi topic maar doordat er zoveel diverse dingen tegelijk besproken worden is dit denk ik voer het hoofd gezien.

Ik heb het volgende probleem.

Sinds ik mijn unifi netwerk een upgrade gegeven heb met een UDM Pro vanuit een USG Pro 4. En een aantal Vlan netwerken aangemaakt heb voor bepaalde toepassingen werkt mijn Reverse proxy server niet meer zoals ik dat graag zou willen en het voorheen gewerkt heeft.

Ik heb mijn Reverse proxy server verplaats van vlan 0 waar vroegen alles zonder vlansin het netwerk was geplaatst. Nu heb ik een aantal servers verplaatst na Vlan 10. dit is dus een taged vlan van vlan 0 uiteindelijk.
De port forward heb ik veranderd van het nieuw naar het oud ip en de server heeft ook netjes het nieuwe ip gekregen en is berijkbaar daarop. Het doorsturen van de poorten werkt naar mijn mening ook omdat ik vanaf het internet de subdomeinen kan bereiken.
Het enige wat niet werkt is een geldig certificaat verkrijgen wat normaal gebeurt via certbot ( CLI applicatie ) in ubuntu server 20.4.

De melding die ik krijg als ik de certificaten probeer te vernieuwen en vroeger nooit. De melding ziet er als volgt uit.

de echte domeinen heb ik even vervang door een aangepaste tekst.
De dik gedrukte tekst in het log krijg ik normaal niet, naar mijn verwachting zit hier het probleem.
Als ik dit probleem op Google zoek kom ik telkens uit bij de port forward. Deze is naar mijn idee gewoon goed.

Met de het command " nginx -t " krijg ik een fouten te zien en zegt hij dat alles in orde is zoals ik verwacht had. De config file is ook niet meer aangepast voor of nadat ik het verhuist heb naar een andere vlan.

Afbeeldingslocatie: https://tweakers.net/i/CZeHUGMd6dyFfgtYtNd5FZDr1yM=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/Bg7mJsddXXOd89NAxgRH5enR.png?f=user_large

Of kan het zijn dat unifi UDM Pro met een bepaalde firewall regel dit verkeer toch op een of andere manier tegenhoud.


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
67
68
69
70
71
72
73
74
75
76
77
root@reverseproxy:~# certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: DOMAIN
2: DOMAIN
3: DOMAIN
4: DOMAIN
5: DOMAIN
6: DOMAIN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/DOMAIN.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/reverse-proxy.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
[b]Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/reverse-proxy.conf
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/reverse-proxy.conf
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.[/b]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://DOMAIN,
https://DOMAIN, https://DOMAIN,
https://DOMAIN, https://DOMAIN, and
https://DOMAIN

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
https://www.ssllabs.com/ssltest/analyze.html?d=DOMAIN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/DOMAIN/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/DOMAIN/privkey.pem
   Your cert will expire on 2020-11-25. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Alle reacties


  • LanTao
  • Registratie: Juni 2008
  • Niet online
Congratulations! You have successfully enabled https://DOMAIN
Wat precies gaat hier dan fout?

  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/reverse-proxy.conf
Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/reverse-proxy.conf
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.
No matching insecure server blocks listening on port 80 found.


Bovenstaande gaat fout naar mijn idee...
Dit stukje tekst heb ik voor het verhuizen nooit gezien.

[ Voor 4% gewijzigd door K!K op 10-09-2020 14:15 ]


  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Maar verder heeft niemand een idee wat er aan de hand kan zijn?

UPDATE:
Ik heb me Ubuntu server opnieuw geïnstalleerd als nieuwe vm.
Echter blijft dit het zelfde resultaat geven. Heb via internet een Port check gedaan en 80 en 443 staan open!
Echter blijven de doorgestuurde urls een niet legitiem cert houden.

Ik heb ook geprobeerd het te regelen via naging proxy manager. Als ik hier een cert aanvraag verstuur krijg ik een internal error te zien. Het lijkt me haast dat er iets fout gaat in de firewall van deUDM Pro.

Iemand een vergelijkbare setup?

[ Voor 79% gewijzigd door K!K op 12-09-2020 15:08 ]


Acties:
  • 0 Henk 'm!

  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Naar mijn idee kom ik toch wat verder met een nieuwe VM.

Inmiddels heb ik aardig wat Firewall rules en beveiliging om te proberen maar uitgezet.
Inmiddels krijg ik ook een andere error te zien in de CLI
Nu geeft certbot dus aan dat hij het domein niet kan bereiken. Als ik via de browser het aders invoer wordt het wel netjes naar het juiste ip doorverwezen.
Ook heb ik de host gebeld of het A record juist gekoppeld is en zijn bevestigen dat het juist is op dit moment.

Zoals ik al eerder heb aangegeven gaat het naar mijn idee mis met de VLAN instellingen en of de Firewall instelling in de UDM Pro.

Via https://www.yougetsignal.com/tools/open-ports/ heb ik poort 80 en 443 gecontroleerd deze geeft aan dat ze open zijn.

In de bijlage heb ik een aantal screenshots gemaakt overzicht van Netwerk Core 192.168.1.0/24 (Unifi devices + reverse proxy server) en Netwerk Main 192.168.10.0/24 ( Bepaalde apparaten of applicaties waar de reverse proxy server na doorstuurt ).
Vanuit het netwerk Main kan ik het ip adres van de reverse proxy benaderen via putty. Als ik de webpagina oproep van nginx server zelf krijg ik een melding bad gateway te zien. Dit heeft vermoedelijk met het probleem te maken.
Afbeeldingslocatie: https://tweakers.net/i/Oqb5B7H3ehAJB-ftATvBt3TJSk0=/800x/filters:strip_exif()/f/image/UUZM2PQYviawg04csYIts6M5.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/WLeHWQdhQITpA91f3aj7nYQ4Lzk=/800x/filters:strip_exif()/f/image/1g3xa5ASZqCiaoIpzen1QUbY.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/LgVgY4GKSmXkSq_IFaoED_n52dU=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/DogzCobSTU3qHn5BD3zko2yp.png?f=user_large

Zijn er suggesties?

Huidige error melding:
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
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for SUB.DOMEIN.NL
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain SUB.DOMEIN.NL
http-01 challenge for SUB.DOMEIN.NL
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: SUB.DOMEIN.NL
   Type:   unauthorized
   Detail: Invalid response from
   http://SUB.DOMEIN.NL/.well-known/acme-challenge/-cUe2Iz4fPXeiey6CTgw1j0rNQN6nzShLeBbJQ
   [WAN IPADRESS]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML
   2.0//EN\">\n<html><head>\n<title>404 Not
   Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

[ Voor 45% gewijzigd door K!K op 15-09-2020 14:42 ]


Acties:
  • 0 Henk 'm!

  • ad-user
  • Registratie: November 2007
  • Niet online
Welke wan aansluiting gebruik je?
utp of fiber?

De UDM pro heeft namelijk wan 1 (utp) en wan 2 (fiber)
In de nieuwe interface zie je alleen wan staan.
In de oude zie je wel wan1 en wan2.

Ik gebruik zelf de fiber (wan2) aansluiting, en de firewall is met deze aansluiting niet in te stellen in de nieuwe interface.

[ Voor 75% gewijzigd door ad-user op 29-09-2020 22:22 ]

maar de zomer komt eraan


Acties:
  • +1 Henk 'm!

  • michelvd
  • Registratie: Augustus 2005
  • Niet online
Hoi,

als ik het goed begrijp probeer je certificaten van de domeinen ACHTER je reverseproxy te updaten ? Dus de webservers van die domeinen staan niet op dezelfde machine als de reverse proxy ?

Als het antwoord op beide vragen ja is dan heb je een leuke uitdaging. Je gebruikt namelijk http-01 validation en daarvoor zet de certbot een filetje neer in je documentroot van je webserver en die staat op een andere machine (vandaar de 404 not found).
Je kunt twee dingen doen :
1) domeinvalidatie via DNS (dat wordt ook aangeraden door Letsencrypt)
2) domeinvalidatie door je reverseproxy te stoppen en certbot een eigen webserver te laten starten en na validatie de reverseproxy weer te starten.

groeten,

Michel

Acties:
  • +1 Henk 'm!

  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Op dit moment gebruik ik de Wan 1 (utp) aansluiting.
ad-user schreef op dinsdag 29 september 2020 @ 15:00:
Welke wan aansluiting gebruik je?
utp of fiber?

De UDM pro heeft namelijk wan 1 (utp) en wan 2 (fiber)
In de nieuwe interface zie je alleen wan staan.
In de oude zie je wel wan1 en wan2.

Ik gebruik zelf de fiber (wan2) aansluiting, en de firewall is met deze aansluiting niet in te stellen in de nieuwe interface.
Er staat een webserver (NGINX) op de zelfde server als dat de reverseporxy (certbot) staat. De domeinen naam zelf ( dus geen hosting ) wordt via een A-Record door gestuurd naar het juist Wan IP.

De Reverseproxy + NGINX draait op 192.168.1.28 en deze moet een van de domeinnamen die via de wan binnen komt dus door sturen naar 192.168.10.20:8081 bijvoorbeeld.

Dus ik type ergens ter wereld in subdomein.domein.nl > A-RECORD naar Juiste wan adres > Kom terecht op de Reverse proxy die herkent het domein en subdomein > stuurt het door naar het ingestelde ip adres binnen het lokale lan netwerk, al kan het zijn dat deze in een aparte vlan zit.
Mocht hij in een apparte vlan zitten is dit met de firewall afgevangen dat deze connectie toe gestaan is.
michelvd schreef op dinsdag 29 september 2020 @ 15:09:
Hoi,

als ik het goed begrijp probeer je certificaten van de domeinen ACHTER je reverseproxy te updaten ? Dus de webservers van die domeinen staan niet op dezelfde machine als de reverse proxy ?

Als het antwoord op beide vragen ja is dan heb je een leuke uitdaging. Je gebruikt namelijk http-01 validation en daarvoor zet de certbot een filetje neer in je documentroot van je webserver en die staat op een andere machine (vandaar de 404 not found).
Je kunt twee dingen doen :
1) domeinvalidatie via DNS (dat wordt ook aangeraden door Letsencrypt)
2) domeinvalidatie door je reverseproxy te stoppen en certbot een eigen webserver te laten starten en na validatie de reverseproxy weer te starten.

groeten,

Michel
toon volledige bericht

Acties:
  • 0 Henk 'm!

  • Frogmen
  • Registratie: Januari 2004
  • Niet online
Ik denk dat je een kleine denkfout maakt er is een wezenlijk verschil tussen reverse proxy en portforwarding. Bij reverse proxy is de reverse proxy server voor de buitenwereld de webserver hij serveert alleen de content die hij ophaalt van de interne webserver. Dus je certificaten moet je ook installeren op de reverse proxy en niet op de webserver in principe, of op beide.

Voor een Tweaker is de weg naar het resultaat net zo belangrijk als het resultaat.


Acties:
  • 0 Henk 'm!

  • K!K
  • Registratie: April 2008
  • Laatst online: 21:19
Waarop baseer jij de denkfout?

De reserve proxy server dient precies te doen wat jij omschrijft! En de certificaten zijn jaren lang op beide geïnstalleerd geweest. Het heeft ook jaren lang foutloos gefunctioneerd. Vandaar dat ik nu ook niet snap waarom het niet meer werkt met een andere router.
Pagina: 1