Webhotell eller VPS: kan planen din køyre ein VPN-server?

Eit fungerande nettstad er prov på at ein leverandør kan levere HTTP, ikkje at du kontrollerer ein maskin. Mellom ein delt plan, ein administrert applikasjon og ein sjølvadministrert server er det eit stort gap i kva kontoen får gjere med nettverket. Bestem kva side av gapet VPN-designet ditt treng, før du betalar for endå eit år. Fire eigenskapar skil dei to, og ingen av dei står på ei prisliste.

Kva kvar plan faktisk gir deg

Den nyttige samanlikninga er ikkje pris eller diskplass, men myndigheit. Spør kva kontoen kan starte, kva kjernefunksjonar han når, kva portar som tek imot innkomande trafikk, og om tillaten trafikk kan gå ut att ein annan stad.

Dei fleste hostingprodukt fell i tre former, og berre den siste er ein server til generelt bruk:

Ein shell-konto er den vanlege kjelda til forvirring. Filoverføring eller tilgang til planlagde oppgåver kan sjå ut som administrasjon, medan prosessen er avgrensa til ei mappe og eit lite sett tillatne operasjonar.

Fire eigenskapar som avgjer svaret

Ta dei i rekkjefølgje, for eit feilgrep i første steg gjer resten irrelevant.

For det første må programvara køyre som ein langliva prosess som overlever vedlikehald. For det andre må implementasjonen kunne opprette sitt virtuelle grensesnitt; på Linux tyder det vanlegvis å opne /dev/net/tun med den relevante administrative løyva, slik TUN/TAP-dokumentasjonen til kjerna skildrar, sjølv om ikkje kvart VPN-design brukar den eininga. For det tredje må klientar nå lyttaren på den offentlege adressa, transporten og porten du har tenkt, og ein web-omvend proxy som godtek HTTPS seier ingenting om ein urelatert protokoll på same nummer. For det fjerde må tillaten trafikk kunne gå vidare, med ruter, videresending og kvar oversetjing som faktisk er støtta.

Tenestevilkåra står ved sida av dei fire og er slett ikkje tekniske. Ubegrensa trafikkkvotar skildrar vanlegvis webførespurnader, ikkje ein tunnel som ber andre sine nedlastingar. Les avsnittet om akseptabel bruk før du designar rundt det, og hugs gjenopprettingstilgang for dagen tenesta ikkje startar.

Kvar ein nettstadkonto stoppar

Ein nettstadplan køyrer vanlegvis koden din i ein administrert køyretid med eit fast inngangspunkt. Sjølv der ein tunnelbinær finst, kan prosessen mangla løyve til å opne ein einingnode, binde ein privilegert port eller endre rutetabellen. Desse avgrensingane er produktet, ikkje ei gløymsle.

Difor viser eit programtillegg som lovar VPN seg vanlegvis å vere ein proxy til ein annan stad. Viss den noverande kontoen berre tilbyr nettstadkontrollar, er det ærlege steget ein eigen server, ikkje ein jakt på modulen som låser opp den manglande myndigheita.

Når éin vert må køyre begge

Deling er mogleg og stundom fornuftig, men handsam det som ei tryggleiksavgjerd framfor ei lettvintheit. Ein webapplikasjon med eit opplastingsskjema står ved sida av tunnelpålogging og ein kontrollsocket, og eit exploit i den eine når den andre. Separate kontoar, separate tenesteeiningar og separate filsystem reduserer den eksponeringa utan å kjøpe ein ekstra maskin.

Konkurranse om ressursar tyder like mykje. Ein tryggleikskopi over tunnelen og ein travel webprosess konkurrerer om same oppstrømslinje og same disk, og feilen ser ut som ein treg nettstad framfor ein metta tunnel. Bestem kva belastning som vinn før hendinga, og avgrens tunnelen slik at nettstaden held fram med å svare.

Ingen av dei to ordningane er isolerte berre fordi begge tenestene køyrer. Evna til å hoste dei saman er starten på designet, og isolasjonsarbeidet er det som gjer det forsvarleg.

Avgjer det på ein prøvevert med fire kommandoar

Før du migrerer, leiger du den minste instansen av målproduktet i ein time og testar dei fire eigenskapane direkte. Å gjette frå ein funksjonstabell sløser mindre pengar enn eit år med feil plan, men langt meir tid.

Køyr desse på prøveverten og les feila som svar, ikkje som hindringar:

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

Dei to første linjene fortel om ei tunneleining i det heile kan finnast. Den tredje rapporterer om verten kan videresende pakkar, og den fjerde viser kva som alt lyttar, slik at ein portkonflikt vert fanga tidleg. Ein leverandør som feilar på andre linje, kan framleis støtte ein implementasjon i brukarland, så nemn mekanismen du treng, ikkje produktkategorien, når du spør supporten deira.