Een VPN en een website op één host zonder botsingen draaien

Deelt u één host tussen een openbare site en een VPN, dan erft u twee vragen, niet één: wat luistert waar, en wie authenticeert wie. Beantwoord beide voordat u een configuratiebestand aanraakt, want de standaardwaarden zijn op manieren fout die pas onder belasting zichtbaar worden. Een pagina die via HTTPS laadt, bewijst dat de weblistener antwoordt en niets over de peer-listener. Wat volgt is een beslissingsvolgorde die voorkomt dat de twee elkaar opeten.

Bepaal wat op welk adres en welke transport luistert

Schrijf een tabel met drie kolommen, adres, transport en poort, en één rij per dienst, inclusief de beheerinterface. TCP 443 voor de site en UDP 443 voor de VPN zijn geen conflict ook al komen de nummers overeen, omdat het transport verschilt. Twee diensten op hetzelfde adres, transport en poort hebben een regeling nodig die de implementatie documenteert, niet een die u tijdens een storing verzint. Die tabel is ook het artefact dat de volgende wijziging beoordeelbaar maakt.

Gescheiden adressen of een tweede poort maken eigendom zichtbaar in een pakketopname, en dat is meer waard dan elegantie. Sommige VPN-implementaties ondersteunen het delen van een poort met een webserver, maar het mechanisme is specifiek: de daemon inspecteert de eerste bytes en stuurt verkeer door dat niet zijn eigen protocol is. Een generieke omgekeerde proxy voor HTTP doet dat niet, en het herschrijven van headers zal hem geen versleutelde tunnelhanddruk laten begrijpen. Lees de uitrolnotities van het protocol, zoals de OpenVPN-listenerdocumentatie, en volg de regeling die zij beschrijft.

Bepaal welke identiteit bij welke dienst hoort

Een browsercertificaat en een VPN-peerreferentie zijn verschillende objecten met verschillende vertrouwensmodellen. Het webcertificaat wordt gevalideerd door een publieke autoriteit en noemt een hostnaam, terwijl de peerreferentie een apparaat of een gebruiker bij de concentrator authenticeert en zelfondertekend of intern uitgegeven kan zijn. Het ene als het andere hergebruiken werkt in smalle gevallen en is de koppeling zelden waard. Verificatie uitschakelen zodat een gedeeld certificaat past is geen scheidingsplan; het verwijdert de controle die de referentie betekenis gaf.

Houd de twee opslagplaatsen onafhankelijk en noteer welke autoriteit elk uitgeeft. Wordt de ene geroteerd, dan zou de andere geen wijziging nodig moeten hebben, en als dat wel zo is, is de koppeling het ding om te repareren.

Bepaal waar het beheer woont

De beheerinterface van de VPN hoort op een beheerpad, nooit op de openbare listener, ook niet wanneer de host al het internet bedient. Een webserver op 443 betekent niet dat de peerconsole vanaf elke plek bereikbaar moet zijn, en de console is meestal het waardevollere doel. Bind hem aan een loopback- of beheeradres, beperk hem op bron en houd een herstelpad dat niet afhangt van het feit dat de tunnel overeind staat. Het herstelpad is belangrijk omdat de gebruikelijke fout is uzelf buiten te sluiten terwijl u het slot repareert.

Schrijf smalle firewallregels, één per listener, en benoem de interface of het serviceaccount waar het platform dat ondersteunt. Brede regels die de host openen omdat de site 443 nodig heeft, zijn de manier waarop beheerinterfaces in scannerindexen belanden.

Herzie die regels tegen de listenertabel telkens wanneer een dienst wordt toegevoegd. De herziening is goedkoop en ze vangt de regel die iemand om twee uur 's nachts heeft toegevoegd.

Bepaal wat te doen wanneer de twee strijden

Een host delen betekent CPU, geheugen, bestandsdescriptoren en bandbreedte delen, en de betwiste hulpbron is niet altijd de voor de hand liggende. Een drukke site kan de verbindingstabel vullen, de werkslots uitputten of de schijfwachtrij zo hard duwen dat de VPN-logging vastloopt. Kijk naar gebruik per dienst in plaats van hosttotalen, want een gemiddelde verbergt welk proces hongert. Als één werklast de andere herhaaldelijk verstoort, isoleer ze dan in plaats van om het symptoom heen te tunen.

Isolatie kan een container zijn, een cgroup-limiet, een aparte wachtrij of een tweede host, en de juiste keuze hangt af van welke hulpbron strijdt. Een poortwijziging lost hier niets op, en een grotere instantie lost niets op als de limiet één verzadigde wachtrij is. Beslis met een meting: benoem de hulpbron, belast hem, en kies dan de kleinste isolatie die de concurrentie wegneemt.

Verifieer van buitenaf, en daarna opnieuw na een herstart

Test vanaf een apparaat dat niet op het eigen netwerk van de host staat: laad de site, breng de tunnel omhoog en bereik één hulpbron die hem vereist. Herstart daarna elke dienst afzonderlijk en herhaal de andere test, want een herstart is het moment waarop een gedeelde listenerregeling haar volgorde verliest. Als de VPN start voor de webserver die de gedeelde poort bezit, kan het deelmechanisme zich nooit aanhaken, en het symptoom is een tunnel die gisteren werkte. Maak de afhankelijkheid expliciet in de unitvolgorde.

Bevestig daarna de grenzen: de site antwoordt op haar poort, de VPN antwoordt op de zijne, en de beheerinterface antwoordt alleen vanaf het beheerpad. Noteer het resultaat naast de listenertabel met de datum. Een host die alle drie de controles na een herstart doorstaat, is een host die u zonder briefing aan iemand anders kunt overdragen.