Kør en VPN og et websted på én vært uden sammenstød

Deler du én vært mellem et offentligt websted og en VPN, arver du to spørgsmål, ikke ét: hvad lytter hvor, og hvem autentificerer hvem. Besvar begge, før du rører en konfigurationsfil, fordi standardværdierne er forkerte på måder, der først viser sig under belastning. En side, der indlæses over HTTPS, beviser, at weblytteren svarer, og intet om peer-lytteren. Det følgende er en beslutningsrækkefølge, der forhindrer de to i at spise hinanden.

Beslut hvad der lytter på hvilken adresse og transport

Skriv en tabel med tre kolonner, adresse, transport og port, og én række for hver tjeneste, inklusive administrationsgrænsefladen. TCP 443 til webstedet og UDP 443 til VPN er ikke en konflikt, selv om tallene stemmer, fordi transporten er forskellig. To tjenester på samme adresse, transport og port kræver en ordning, som implementeringen dokumenterer, ikke en du opfinder under et nedbrud. Tabellen er også det artefakt, der gør den næste ændring gennemseelig.

Adskilte adresser eller en anden port gør ejerskab synligt i en pakkeoptagelse, og det er mere værd end elegance. Nogle VPN-implementeringer understøtter at dele en port med en webserver, men mekanismen er specifik: dæmonen inspicerer de første bytes og videresender trafik, der ikke er dens egen protokol. En generisk omvendt proxy til HTTP gør ikke det, og omskrivning af headere får den ikke til at forstå et krypteret tunnel-håndtryk. Læs protokollens udrulningsnoter, såsom OpenVPN-lytterdokumentationen, og følg den ordning, den beskriver.

Beslut hvilken identitet der hører til hvilken tjeneste

Et browsercertifikat og en VPN-peer-legitimation er forskellige objekter med forskellige tillidsmodeller. Webcertifikatet valideres af en offentlig myndighed og navngiver et værtsnavn, mens peer-legitimationen autentificerer en enhed eller en bruger over for koncentratoren og kan være selvsigneret eller udstedt internt. Genbrug af den ene som den anden virker i snævre tilfælde og er sjældent koblingen værd. At slå verifikation fra, så et delt certifikat passer, er ikke en adskillelsesplan; det fjerner den kontrol, der gav legitimationen betydning.

Hold de to lagre uafhængige, og skriv ned, hvilken myndighed der udsteder hver. Når den ene roteres, bør den anden ikke skulle ændres, og hvis den skal, er koblingen det, der skal rettes.

Beslut hvor administrationen bor

VPN'ens administrative grænseflade hører på en administrationsvej, aldrig på den offentlige lytter, heller ikke når værten allerede betjener internettet. En webserver på 443 betyder ikke, at peer-konsollen skal være tilgængelig overalt, og konsollen er normalt det mere værdifulde mål. Bind den til en loopback- eller administrationsadresse, begræns den efter kilde, og hold en gendannelsesvej, der ikke afhænger af, at tunnelen er oppe. Gendannelsesvejen betyder noget, fordi den almindelige fejl er at låse sig selv ude, mens man retter låsen.

Skriv snævre firewallregler, én for hver lytter, og navngiv grænsefladen eller tjenestekontoen, hvor platformen understøtter det. Brede regler, der åbner værten, fordi webstedet har brug for 443, er måden, hvorpå administrative grænseflader ender i skannerindeks.

Gennemgå de regler mod lyttertabellen, hver gang en tjeneste tilføjes. Gennemgangen er billig, og den fanger den regel, som nogen tilføjede klokken to om morgenen.

Beslut hvad du gør, når de to konkurrerer

At dele en vært betyder at dele CPU, hukommelse, filbeskrivere og båndbredde, og den omstridte ressource er ikke altid den oplagte. Et travlt websted kan fylde forbindelsestabellen, udtømme arbejdspladser eller presse diskkøen så hårdt, at VPN-logning går i stå. Se på forbruget for hver tjeneste i stedet for værttotaler, fordi et gennemsnit skjuler, hvilken proces der sulter. Hvis én arbejdsbyrde gentagne gange forstyrrer den anden, isoler dem i stedet for at tune rundt om symptomet.

Isolation kan være en container, en cgroup-grænse, en separat kø eller en anden vært, og det rigtige valg afhænger af, hvilken ressource der konkurrerer. En portændring retter intet her, og en større instans retter intet, hvis grænsen er én mættet kø. Beslut ud fra en måling: navngiv ressourcen, belast den, og vælg derefter den mindste isolation, der fjerner konkurrencen.

Verificer udefra, og derefter igen efter en genstart

Test fra en enhed, der ikke er på værtens eget netværk: indlæs webstedet, rejs tunnelen, og nå én ressource, der kræver den. Genstart derefter hver tjeneste for sig og gentag den anden test, fordi en genstart er, når en delt lytterordning mister sin rækkefølge. Hvis VPN'en starter før den webserver, der ejer den delte port, bliver deleordningen måske aldrig tilkoblet, og symptomet er en tunnel, der virkede i går. Gør afhængigheden eksplicit i enhedsordenen.

Bekræft derefter grænserne: webstedet svarer på sin port, VPN'en svarer på sin egen, og administrationsgrænsefladen svarer kun fra administrationsvejen. Notér resultatet ved siden af lyttertabellen med datoen. En vært, der består alle tre kontroller efter en genstart, er en vært, du kan overdrage til en anden uden en briefing.