Webhosting kontra en VPS: kan din plan køre en VPN-server?

Et fungerende websted er bevis på, at en udbyder kan levere HTTP, ikke at du styrer en maskine. Mellem en delt plan, en administreret applikation og en selvadministreret server er der et stort gab i, hvad kontoen må gøre ved netværket. Beslut, hvilken side af det gab din VPN-konstruktion har brug for, før du betaler for endnu et år. Fire egenskaber skiller de to, og ingen af dem står på en prisliste.

Hvad hver plan reelt giver dig

Den brugbare sammenligning er ikke pris eller diskplads, men myndighed. Spørg, hvad kontoen kan starte, hvilke kernefunktioner den kan nå, hvilke porte der tager imod indgående trafik, og om tilladt trafik igen må forlade stedet til noget andet.

De fleste hostingprodukter falder i tre former, og kun den sidste er en server til almindelige formål:

En shell-konto er den sædvanlige kilde til forvirring. Filoverførsel eller adgang til planlagte opgaver kan ligne administration, mens processen er låst til en mappe og et lille sæt tilladte handlinger.

Fire egenskaber, der afgør svaret

Tag dem i rækkefølge, for et fejltrin i første skridt gør resten irrelevant.

For det første skal softwaren køre som en langlivet proces, der overlever vedligeholdelse. For det andet skal implementeringen kunne oprette sin virtuelle grænseflade; på Linux betyder det normalt at åbne /dev/net/tun med den relevante administrative tilladelse, som kernens TUN/TAP-dokumentation beskriver, selv om ikke enhver VPN-konstruktion bruger den enhed. For det tredje skal klienter kunne nå lytteren på den offentlige adresse, den transport og den port, du har tænkt dig, og en web-reverse-proxy, der accepterer HTTPS, siger intet om en urelateret protokol på samme nummer. For det fjerde skal tilladt trafik kunne komme videre, med ruter, videresendelse og enhver oversættelse, der reelt understøttes.

Servicevilkårene står ved siden af de fire og er slet ikke tekniske. Ubegrænsede trafikkvoter beskriver normalt webforespørgsler, ikke en tunnel, der bærer andres downloads. Læs afsnittet om acceptabel brug, før du designer ud fra det, og husk gendannelsesadgang til den dag, tjenesten ikke starter.

Hvor en webkonto stopper

En webplan kører normalt din kode i en administreret runtime med et fast indgangspunkt. Selv hvor en tunnelbinær findes, kan processen mangle tilladelse til at åbne en enhedsknude, binde en privilegeret port eller ændre rutetabellen. Disse begrænsninger er produktet, ikke en forglemmelse.

Derfor viser et plugin, der lover VPN, sig normalt at være en proxy til et andet sted. Hvis den nuværende konto kun tilbyder webkontroller, er det ærlige skridt en separat server, ikke en jagt på det modul, der låser den manglende myndighed op.

Når én vært skal køre begge

Deling er mulig og nogle gange fornuftig, men behandl det som en sikkerhedsbeslutning frem for en bekvemmelighed. En webapplikation med en uploadformular står ved siden af tunnellegitimationsoplysninger og en kontrolsocket, og et exploit i den ene når den anden. Separate konti, separate serviceenheder og separate filsystemer reducerer den eksponering uden at købe en ekstra maskine.

Konkurrence om ressourcer betyder lige så meget. En backup over tunnelen og en travl webproces konkurrerer om samme uplink og samme disk, og fejlen ser ud som et langsomt websted frem for en mættet tunnel. Beslut, hvilken belastning der vinder, før hændelsen, og begræns tunnelen, så webstedet bliver ved med at svare.

Ingen af de to ordninger er isoleret, blot fordi begge tjenester kører. Evnen til at hoste dem sammen er starten på designet, og isolationsarbejdet er det, der gør det forsvarligt.

Afgør det på en prøvevært med fire kommandoer

Før du migrerer, lej den mindste instans af målproduktet i en time og test de fire egenskaber direkte. At gætte ud fra en funktionstabel spilder færre penge end et år med den forkerte plan, men langt mere tid.

Kør disse på prøveværten og læs fejlene som svar, ikke som forhindringer:

ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head

De to første linjer fortæller, om en tunnel-enhed overhovedet kan findes. Den tredje rapporterer, om værten må videresende pakker, og den fjerde viser, hvad der allerede lytter, så en portkonflikt fanges tidligt. En udbyder, der fejler på anden linje, kan stadig understøtte en implementering i brugerland, så navngiv den mekanisme, du har brug for, i stedet for produktkategorien, når du spørger deres support.