Köra en VPN och en webbplats på en enda värd utan kollisioner

Delar du en värd mellan en offentlig webbplats och en VPN ärver du två frågor, inte en: vad lyssnar var, och vem autentiserar vem. Svara på båda innan du rör en konfigurationsfil, eftersom standardvärdena är fel på sätt som först syns under last. En sida som laddas över HTTPS bevisar att webbslyssnaren svarar, och ingenting om peer-lyssnaren. Det som följer är en beslutsordning som hindrar de två från att äta upp varandra.

Bestäm vad som lyssnar på vilken adress och transport

Skriv en tabell med tre kolumner, adress, transport och port, och en rad per tjänst, inklusive administrationsgränssnittet. TCP 443 för webbplatsen och UDP 443 för VPN är ingen konflikt även om siffrorna stämmer, eftersom transporten skiljer sig. Två tjänster på samma adress, transport och port behöver ett arrangemang som implementeringen dokumenterar, inte ett du hittar på under ett avbrott. Tabellen är också artefakten som gör nästa ändring granskningsbar.

Separat adresser eller en andra port gör ägandet synligt i en paketinsamling, och det är värt mer än elegans. Vissa VPN-implementationer stöder att dela en port med en webbserver, men mekanismen är specifik: daemonen granskar de första byten och vidarebefordrar trafik som inte är dess eget protokoll. En generisk omvänd proxy för HTTP gör inte det, och omskrivning av rubriker får den inte att förstå ett handskakning för en krypterad tunnel. Läs protokollets distributionsanteckningar, till exempel OpenVPN-lyssnardokumentationen, och följ det arrangemang den beskriver.

Bestäm vilken identitet som hör till vilken tjänst

Ett webbläsarcertifikat och en VPN-peer-legitimation är olika objekt med olika förtroendemodeller. Webbcertifikatet valideras av en offentlig myndighet och namnger ett värdnamn, medan peer-legitimationen autentiserar en enhet eller en användare mot koncentratorn och kan vara självsignerat eller utfärdat internt. Att återanvända den ena som den andra fungerar i snäva fall och är sällan kopplingen värd. Att stänga av verifieringen så att ett delat certifikat passar är ingen separationsplan; det tar bort den kontroll som gav legitimationen betydelse.

Håll de två lagren oberoende och skriv ned vilken myndighet som utfärdar varje. När den ena roteras bör den andra inte behöva ändras, och om den gör det är kopplingen det som ska åtgärdas.

Bestäm var administrationen bor

VPN:ens administrativa gränssnitt hör på en administrationsväg, aldrig på den offentliga lyssnaren, även när värden redan betjänar internet. En webbserver på 443 innebär inte att peer-konsolen ska vara nåbar varifrån som helst, och konsolen är vanligtvis det mer värdefulla målet. Bind den till en loopback- eller administrationsadress, begränsa den efter källa och håll en återställningsväg som inte beror på att tunneln är uppe. Återställningsvägen spelar roll eftersom det vanliga felet är att låsa sig ute medan man lagar låset.

Skriv smala brandväggsregler, en per lyssnare, och namnge gränssnittet eller tjänstekontot där plattformen stöder det. Breda regler som öppnar värden eftersom webbplatsen behöver 443 är hur administrativa gränssnitt hamnar i skannerindex.

Granska dessa regler mot lyssnartabellen varje gång en tjänst läggs till. Granskningen är billig, och den fångar regeln som någon lade till klockan två på natten.

Bestäm vad du ska göra när de två konkurrerar

Att dela en värd betyder att dela CPU, minne, filbeskrivare och bandbredd, och den omstridda resursen är inte alltid den uppenbara. En upptagen webbplats kan fylla anslutningstabellen, förbruka arbetsslotsen eller pressa diskkön tillräckligt hårt för att VPN-loggningen ska stanna. Titta på användning per tjänst i stället för värdens totaler, eftersom ett medelvärde döljer vilken process som svälter. Om en arbetsbelastning upprepade gånger stör den andra, isolera dem i stället för att trimma runt symptomet.

Isolering kan vara en container, en cgroup-gräns, en separat kö eller en andra värd, och det rätta valet beror på vilken resurs som konkurrerar. En portändring löser ingenting här, och en större instans löser ingenting om gränsen är en mättad kö. Besluta med en mätning: namnge resursen, belasta den och välj sedan den minsta isolering som tar bort konkurrensen.

Verifiera utifrån och sedan igen efter en omstart

Testa från en enhet som inte är på värdens eget nätverk: ladda webbplatsen, res tunneln och nå en resurs som kräver den. Starta sedan om varje tjänst för sig och upprepa det andra testet, eftersom en omstart är när ett delat lyssnararrangemang tappar sin ordning. Om VPN:en startar före webbservern som äger den delade porten hakar delningsmekanismen kanske aldrig på, och symptomet är en tunnel som fungerade i går. Gör beroendet explicit i enhetsordningen.

Bekräfta sedan gränserna: webbplatsen svarar på sin port, VPN:en svarar på sin egen, och administrationsgränssnittet svarar bara från administrationsvägen. Anteckna resultatet bredvid lyssnartabellen med datumet. En värd som klarar alla tre kontrollerna efter en omstart är en värd du kan lämna över till någon annan utan en genomgång.