letsencrypt ja wireguard

[dataaja95]

Terve
Yritän tässä saada letsencryptin certiä wireguardin takana olevalle koneelle, olen siis ohjannut vpn liikenteen palvelimen kautta jossa on kiinteä ip ja yritän saada tälle asiakaskoneelle certiä certbotin standalonetilassa, tcpdumpilla tutkittaessa vpn palvelimella liikenne ohjautuu oikein ulos serveriltä mutta ei saa koskaan vastausta letsencryptin palvelimilta, muu liikenne kuten tämän clienttikoneen päivitykset tai muu säätäminen toimii ok. Palvelimen sekä asiakkaan palomuureista avattu portit 80 ja 443 kuten kuuluu certin anomisen ajaksi. Letsencryptin logi kertoo näin, eikai palvelimella tarvitse pyöriä jotain webbipalvelinta asiakkaan certin anomisen aikana, palvelinhan vain tässätapauksessa reitittää liikennettä.

2023-05-08 18:25:07,245:WARNING:certbot._internal.auth_handler:Challenge failed for domain x.x.x
2023-05-08 18:25:07,246:INFO:certbot._internal.auth_handler:http-01 challenge for x.x.x
2023-05-08 18:25:07,246EBUG:certbot._internal.reporter:Reporting to user: The following errors were reported by the server:

Domain: x.x.x
Type: connection
Detail: xxxx: Fetching http://xxxxxx/.well-known/acme-challenge/: Connection refused

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. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

 

[dataaja95]

ALkaa tuntua, että clienttikone ei osaa reitittää oikein liikennettä gatewayn https portteihin, näyttävät ulkopuolelta nmapilla skannatessa olevan kiinni, vaikka palomuurista tarvittavat avaukset ovat tehty, miten tätä ongelmaa voisi lähteä ratkomaan

 

[SamCer]

Ite en oo muistaakseni koskaan onnistunu tuolla certbotin --standalone-vivulla saamaan certtiä. Sen vuoksi oon alkanu käyttämään dns-challenge validointia, joka on ollut pommin varma tapa, eikä tarvi alkaa certtiä varten puhkoa reikiä muuriin. Tosin, jos sen servun, jolle certtiä haluaa, pitää olla saavutettavissa suoraan netistä ja portteina on 80 + 443, niin eipä sillä silloin ole väliä.

Joillekin suurmille DNS-palveluntarjoajille, esim. Cloudflarelle, löytyy suoraan omat plugarit, joilla DNS validointi tehdään automaattisesti, jolloin ei tarvi itse käsin käydä lisäämässä validoinnin ajaksi DNS-recordeja sinne DNS-palvelimeen.

 

[dataaja95]

Luultavasti tulen pistämään verkkoon oman dns serverin jonka avulla voin tehdä certivarmistukset. Yritän saada wireguardia toimimaan gatewayna, tarkoituksena olisi reitittää yhteys erään koneen kautta jossa on kiinteä ip meikäläisen sisäverkkoon, muutamalle palvelimelle jotka hostaavat palveluja ulkoverkkoon ja homma pyörisi tuon kiinteän ip:llä varustetun koneen kautta, nyt kuitenkin kun skannaan nmapilla tuota gatewaykonetta en näe näiden palvelujen portteja aukinaisena vaikka näiltä koneilta joilla palvelut toimivat, pystyn käyttämään hienosti nettiä vpn:n läpi. Pitääkö tässä tehdä jotain nattisääntöjä iptablesiin. Paketit kuitenkin sisi kulkevat näiden palvelukoneiden ja vpn:n välillä ok.

 

[Chrono]

Tosiaan tuo Letsencrypt taitaa vaatia sen, että 80 ja 443 porteilta vastaa joku webserveri. Tullut itsellä silleen vastaan kun on unohtanu aktivoida subdomainin Apache virtual host conffin niin Letencrypt on subdomainin certtiä hakiessa valittanut jotain erroria, mikä sitten mennyt pois kun on aktivoinut Apachessa kyseisen subdomainin conffin.

 

[KaptPirk]

liikenne ohjautuu oikein ulos serveriltä mutta ei saa koskaan vastausta letsencryptin palvelimilta

Jos paluuliikennettä ei näy, niin ovatko DNS-tiedot kunnossa eli verkkotunnuksesi A/AAAA-tiedot osoittavat tähän ip-osoitteeseen?
Tosin käsittääkseni cert-pyynnön vastaanottava palvelin ei välttämättä ole sama kuin varsinaisen acme-challengen suorittava palvelin, joten kyselyt saattavat tulla ihan eri ip-osoitteesta. Tuleeko wireguard-koneen porttiin 80 mitään liikennettä tuona ajanjaksona?

DNS voi tarkistaa esim Googlen DNS-palvelusta: dns.google

kyseistä porttia ei näy aukinaisena vaikka nginxin pitäisi sitä kuunnella

Pyöriikö Nginx siis tuolla asiakaskoneella? Eikö silloin olisi parempi käyttää Certbotin nginx-pluginia standalonen sijasta? Olemassa oleva palvelinohjelmisto voi ilmeisesti häiritä standalonen toimintaa.

User Guide — Certbot 2.5.0 documentation "--- This plugin needs to bind to port 80 in order to perform domain validation, so you may need to stop your existing webserver."

kuitenkin ilmeisesti tämä vaatisi nattauksen iptablesilla että saisi portit näkymään ulkoverkkoon
--
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.2:443

Iptables-komento näyttäisi noin päällisinpuolin oikeanlaiselta mutta vaihda portti 443-->80 tai ainakin lisää vastaava komento portille 80. HTTP-01-challenge tapahtuu portilla 80.

Liikenne pääsee gatewaykoneelle asti, mutta vpn-clientille missä pyörii nginx liikenne ei pääse skannatessa ulkoverkosta.

Gateway-koneessa lienee useampi verkkoadapteri. Onhan iptables-komennon eth0 se julkisen internetin puolella sijaitseva verkkoadapteri? (edit: Vai pitääköhän sen olla joku wireguard-tunnelin virtuaalinen adapteri tässä tapauksessa, jos julkinen ip-osoite olikin tunnelin takana? En nyt ehkä täysin hahmottanut tätä verkkoliikennejärjestelyä.)

 

[dataaja95]

Noniin ja päivitetääs tilannetta tänne, homma ratkesikin sitten avaamalla palomuurista portit myös sisäänpäin vpn-yhteydelle, ilmeisesti certbot pääsi juttelemaan letsencryptin palvelimien kanssa oikein, mutta kun certejä alettiin lataamaan clienttikoneelle, homma tökkäsi siihen.