Rularea unui VPN și a unui site pe un singur host fără coliziuni

Când împărțiți un host între un site public și un VPN, moșteniți două întrebări, nu una: ce ascultă unde și cine autentifică pe cine. Răspundeți la ambele înainte de a atinge un fișier de configurare, pentru că valorile implicite sunt greșite în moduri care apar doar sub sarcină. O pagină care se încarcă prin HTTPS dovedește că ascultătorul web răspunde și nimic despre ascultătorul partenerilor. Urmează o ordine a deciziilor care împiedică cele două să se mănânce reciproc.

Decideți ce ascultă pe ce adresă și transport

Scrieți un tabel cu trei coloane, adresă, transport și port, și un rând pentru fiecare serviciu, inclusiv interfața administrativă. TCP 443 pentru site și UDP 443 pentru VPN nu sunt o coliziune chiar dacă numerele coincid, pentru că transportul diferă. Două servicii pe aceeași adresă, transport și port au nevoie de o înțelegere pe care implementarea o documentează, nu de una pe care o inventați în timpul unei căderi. Acel tabel este și artefactul care face următoarea modificare verificabilă.

Adrese separate sau un al doilea port fac proprietatea vizibilă într-o captură de pachete, iar asta valorează mai mult decât eleganța. Unele implementări VPN permit partajarea unui port cu un server web, dar mecanismul este specific: demonul inspectează primii octeți și redirecționează traficul care nu este protocolul său. Un proxy invers HTTP generic nu face asta, iar rescrierea antetelor nu îl va face să înțeleagă un schimb de mână al unui tunel criptat. Citiți notele de implementare ale protocolului, cum ar fi documentația ascultătorului OpenVPN, și urmați înțelegerea pe care o descrie.

Decideți ce identitate aparține cărui serviciu

Un certificat de browser și o acreditare de partener VPN sunt obiecte diferite cu modele de încredere diferite. Certificatul web este validat de o autoritate publică și numește un nume de host, în timp ce acreditarea de partener autentifică un dispozitiv sau un utilizator la concentrator și poate fi auto-semnată sau emisă intern. Reutilizarea unuia ca celălalt funcționează în cazuri înguste și rareori merită cuplarea. Dezactivarea verificării pentru ca un certificat partajat să se potrivească nu este un plan de separare; elimină verificarea care dădea sens acreditării.

Păstrați cele două depozite independente și notați ce autoritate emite fiecare. Când unul este rotit, celălalt nu ar trebui să aibă nevoie de schimbare, iar dacă are, cuplarea este ceea ce trebuie reparat.

Decideți unde locuiește administrarea

Interfața administrativă a VPN aparține unei căi de gestionare, niciodată ascultătorului public, chiar și atunci când hostul servește deja internetul. Un server web pe 443 nu implică faptul că consola partenerilor trebuie să fie accesibilă de oriunde, iar consola este de obicei ținta de valoare mai mare. Legați-o de o adresă de buclă sau de gestionare, restricționați-o după sursă și păstrați o cale de recuperare care nu depinde de faptul că tunelul este pornit. Calea de recuperare contează pentru că eșecul obișnuit este să vă închideți în afara în timp ce reparați încuietoarea.

Scrieți reguli de firewall înguste, una pentru fiecare ascultător, numind interfața sau contul de serviciu acolo unde platforma permite. Regulile largi care deschid hostul pentru că site-ul are nevoie de 443 sunt modul în care interfețele administrative ajung în indexurile scanerelor.

Revizuiți aceste reguli față de tabelul ascultătorilor de fiecare dată când se adaugă un serviciu. Revizuirea este ieftină și prinde regula pe care cineva a adăugat-o la două dimineața.

Decideți ce faceți când cele două concurează

Partajarea unui host înseamnă partajarea procesorului, memoriei, descriptorilor de fișier și lățimii de bandă, iar resursa disputată nu este întotdeauna cea evidentă. Un site aglomerat poate umple tabelul de conexiuni, epuiza sloturile de lucru sau împinge coada discului suficient de tare încât înregistrarea VPN să se blocheze. Uitați-vă la utilizarea pe serviciu în loc de totalurile hostului, pentru că o medie ascunde care proces suferă de foame. Dacă o sarcină deranjează în mod repetat cealaltă, izolați-le în loc să reglați în jurul simptomului.

Izolarea poate fi un container, o limită cgroup, o coadă separată sau un al doilea host, iar alegerea corectă depinde de resursa care concurează. O schimbare de port nu repară nimic aici, iar o instanță mai mare nu repară nimic dacă limita este o singură coadă saturată. Decideți cu o măsurătoare: numiți resursa, încărcați-o, apoi alegeți cea mai mică izolare care elimină concurența.

Verificați din exterior, apoi din nou după o repornire

Testați de pe un dispozitiv care nu este în rețeaua hostului: încărcați site-ul, ridicați tunelul și atingeți o resursă care îl cere. Apoi reporniți fiecare serviciu separat și repetați celălalt test, pentru că o repornire este momentul în care o înțelegere de ascultător partajat își pierde ordinea. Dacă VPN-ul pornește înaintea serverului web care deține portul partajat, mecanismul de partajare poate să nu se atașeze niciodată, iar simptomul este un tunel care funcționa ieri. Faceți dependența explicită în ordinea unităților.

Apoi confirmați limitele: site-ul răspunde pe portul său, VPN-ul răspunde pe al său, iar interfața administrativă răspunde doar din calea de gestionare. Notați rezultatul lângă tabelul ascultătorilor cu data. Un host care trece toate cele trei verificări după o repornire este un host pe care îl puteți preda altcuiva fără o prezentare.