Een toegewijde VPN-IP publiceert je website niet

Een toegewijde IP kopen bij een VPN-aanbieder voelt als een voordeur kopen. Het adres is stabiel, de tunnel staat, en de site laadt nog steeds niet voor wie dan ook buiten. Wat je hebt gekocht, is een toewijzing, geen regel voor inkomende doorsturing. Beide worden in dezelfde winkel verkocht en op volledig verschillende plekken geconfigureerd.

Het adres is een toewijzing, geen doorstuurregel

Noteer het inkomende openbare adres of de hostnaam, het toegestane transport, de toegewezen externe poort en de bestemming aan de clientzijde waar de aanbieder naartoe levert. Bevestig dan dat de server, het protocol en de accountfunctie die je hebt gekozen doorsturen echt ondersteunen, en dat de aanbieder hosting daarop toestaat.

Toegewijd beschrijft de adresstoewijzing. Het betekent niet dat ongevraagd inkomend verkeer is toegestaan, en verschillende add-ons van dezelfde operator kunnen verschillende mogelijkheden hebben. Het toegewijde adres en het product toegewijde server zijn de twee labels die het vaakst worden verward, en de supportpagina's vermelden meestal welke van de twee doorstuurt.

Een voorbeeldcontract ziet er zo uit: de aanbieder levert TCP 203.0.113.60:45000 aan de HTTPS-dienst van je verbonden apparaat op poort 8443. Dat beschrijft een mapping die iemand anders heeft geconfigureerd, geen regel die je aan hun rand kunt maken door hem in je eigen firewall te typen.

Rond de oorsprongzijde af

Als de webapplicatie op de VPN-client zelf draait, heeft die een luisteraar op de geleverde poort nodig en een beperkte toestemming voor lokale invoer op die poort. Als de client de gemapte verbinding doorstuurt naar een andere host, heeft die de bestemmingsvertaling, het doorstuurbeleid en een antwoordpad nodig dat de heen- en terugreis overleeft.

Ontwerp toegangsregels rond het bronadres dat het pad van de aanbieder werkelijk presenteert. Het is niet altijd de oorspronkelijke bezoeker, en het is ook niet altijd de VPN-server, wat uitmaakt wanneer je een regel schrijft waarop maar één van die adressen zou passen.

Poortvertaling maakt ook geen HTTPS van HTTP. De openbare poort en de lokale applicatiepoort mogen vrij verschillen, maar het schema, de identiteit van het certificaat en de omleidingen moeten nog steeds passen bij de dienst die mensen werkelijk bereiken. Als het certificaat de openbare host noemt, houd die naam dan op elke stap aan. Een mismatch hier verschijnt als een browserwaarschuwing en niet als een routeringsfout, wat mensen een uur naar de verkeerde logs stuurt.

Publiceer de hoge poort eerlijk

Als bezoekers rechtstreeks verbinden en de aanbieder een hoge poort heeft toegewezen, geef hun dan de volledige URL. Een gewoon DNS-adresrecord kan geen poort toevoegen aan een HTTPS-verzoek dat standaard 443 gebruikt, en geen TTL-aanpassing verandert dat.

Een webfrontend kan dit oplossen door bezoekers op de gebruikelijke poort te accepteren en zelf verbinding te maken met de doorgestuurde oorsprongpoort. De standaard proxy-poorten van Cloudflare zijn echter een vaste lijst, en een willekeurig toegewezen poort wordt geen ondersteunde edge-poort alleen omdat je een proxy-DNS-record hebt toegevoegd.

De bestemmingspoort van de oorsprong wijzigen is een andere handeling dan de poort van de bezoeker wijzigen. De Origin Rules van Cloudflare documenteren een overschrijving van de bestemmingspoort voor de backend-verbinding, beperkt tot een ondersteunde regel, schema en hostnaam. Een poortoverschrijving is geen algemene relay voor willekeurige UDP of andere protocollen.

Wanneer een frontend TLS beëindigt, valideer beide stappen: het certificaat van de browser naar de frontend en de verbinding van de frontend naar de oorsprong. De VPN-stap vervangt geen van beide controles, en een intern adres dat weglekt naar omleidingen of cookies is het gebruikelijke teken dat slechts één van de twee met de openbare naam in gedachten is geconfigureerd.

Houd de mapping in leven

Sommige aanbieders wijzen na een herverbinding een andere poort toe, en een gehuurde mapping kan vernieuwing vereisen via een actie aan de kant van de aanbieder. Volg het mechanisme dat je aanbieder documenteert, en werk de luisteraar, lokale regels, DNS of de frontendregel alleen bij waar het huidige contract dat vereist.

Een statisch openbaar adres maakt de poortlease niet statisch. Een adres en poort die nog in een dashboard staan, zijn geen bewijs dat de actieve sessie de mapping bezit, daarom is de test een vers verzoek van buiten in plaats van een schermafbeelding.

Herhaal dan de gevallen die je verwacht: een normale herverbinding en een VPN-verlies. Als verlies de oorsprong onbereikbaar moet maken, laat een updater dan niet stilletjes een direct ISP-pad op de achtergrond opnieuw publiceren. En als het doorstuurcontract niet aan de stabiliteitseisen van de site kan voldoen, kies dan een andere publicatieopzet in plaats van nog een adreslabel te kopen en te hopen dat het zich als een server gedraagt.