Publiek bereikbaar zonder je netwerk open te zetten
Elk publiek subdomein loopt via een Cloudflare Tunnel naar onze eigen hardware. Op de router staat geen enkele inkomende poort open — de tunnel maakt zelf een uitgaande verbinding. Daarachter routeert Caddy per subdomein; op de edge doen workers het werk dat de origin nooit hoeft te zien.
Van bezoeker naar dienst — van buiten naar binnen dicht
Bezoekers komen nooit verder dan de edge. Wat wél naar binnen moet, gaat door een tunnel die van binnenuit is opgezet en eindigt bij een reverse proxy die per subdomein routeert.
Poort openzetten, of de verbinding omdraaien
Dezelfde vraag — "hoe wordt mijn eigen hardware publiek bereikbaar?" — met twee heel verschillende antwoorden. Links de klassieke route, rechts wat wij draaien.
Met poortforwarding
- Poort 443 doorzetten op de router naar de eigen hardware
- Het thuis-IP staat daarmee in publieke DNS
- Elke scanner op internet klopt rechtstreeks aan
- Certificaten en firewallregels zelf bijhouden
- Beheerinterfaces hangen aan hetzelfde publieke adres
Met een tunnel
- De tunnel-client maakt zélf een uitgaande verbinding naar de edge
- Geen enkele inkomende poort open op de router
- Achter de tunnel routeert Caddy per subdomein naar de juiste dienst
- Workers handelen af wat de origin nooit hoeft te zien
- Zero Trust staat vóór alles wat niet publiek hoort te zijn
De edge doet het werk, het netwerk blijft dicht
Tunnel in plaats van poortforwarding
Alle publieke subdomeinen lopen via een Cloudflare Tunnel naar de eigen hardware. De verbinding wordt van binnenuit opgezet; op de router staat geen enkele inkomende poort open. Dat scheelt een hele klasse aan aanvalsoppervlak — de origin is niet rechtstreeks aan te spreken.
Eén ingang, veel diensten
Achter de tunnel zit een reverse proxy (Caddy) die per subdomein naar de juiste dienst routeert. Een nieuwe dienst publiceren is een routeregel erbij — geen nieuwe netwerkopening, geen nieuwe firewallregel.
Workers op de edge
Wat niet naar de origin hoeft, gebeurt op de edge. Een router-worker vangt één specifiek pad af en geeft de rest ongemoeid door aan de origin. Verkeer dat de eigen hardware niet nodig heeft, komt er dus ook niet.
Formulieren zonder mailserver
Een intake-worker handelt contactformulieren af en levert ze per e-mail af via Email Routing. Geen eigen mailserver om te onderhouden en geen API-sleutel in de frontend — het geheim blijft aan de edge-kant.
Zero Trust vóór het beheer
Beheerinterfaces die niet publiek horen te zijn, zitten achter Cloudflare Access. Ze zijn bereikbaar zonder dat ze op het open internet staan; wie geen toegangsbewijs heeft, komt niet voorbij de edge.
DNS-as-code
DNS staat volledig op Cloudflare. Wijzigingen gaan via de API, met een backup van de zone vooraf. Een record is daarmee een reviewbare, terugdraaibare verandering in plaats van een klik in een paneel.
Eerlijk: de MX-val waar we zelf in liepen
Bij het overzetten van de mail-DNS wezen we een MX-record naar een inbound-parse-dienst. Dat ziet er goed uit — het record valideert, mail wordt geaccepteerd — maar zo'n dienst is geen mailbox. Post kwam binnen en werd nergens afgeleverd, zonder bounce. Stil dataverlies dus: niemand krijgt een foutmelding, dus niemand merkt het.
Opgelost door de MX te verhuizen naar echte routing en SPF, DKIM en DMARC alsnog netjes in te richten. De les die we sindsdien hard toepassen: een MX-record dat mail accepteert is geen bewijs dat mail ergens aankomt. Test na elke mail-DNS-wijziging de volledige weg tot in de inbox.
Wil je jouw diensten publiek bereikbaar maken zonder poorten open te zetten?
Deze opzet draait op onze eigen hardware: tunnel, reverse proxy, edge-workers, mail via Email Routing en Zero Trust voor het beheer. We richten hem ook voor jou in.