Ha egy gazdagépet megoszt egy nyilvános webhely és egy VPN között, két kérdést örököl, nem egyet: mi hallgat hol, és ki hitelesít kit. Válaszoljon mindkettőre, mielőtt konfigurációs fájlhoz nyúl, mert az alapértékek olyan módokon hibásak, amelyek csak terhelés alatt látszanak. Az HTTPS-en keresztül betöltődő oldal bizonyítja, hogy a webes hallgató válaszol, és semmit sem mond a társ-hallgatóról. A következő a döntések sorrendje, amely megakadályozza, hogy a kettő megegye egymást.

Döntse el, mi hallgat melyik címen és átvitelen

Írjon táblázatot három oszloppal, cím, átvitel és port, és egy sorral szolgáltatásonként, beleértve az adminisztratív felületet. A webhely TCP 443-a és a VPN UDP 443-a nem ütközés akkor sem, ha a számok megegyeznek, mert az átvitel különbözik. Két szolgáltatás ugyanazon a címen, átvitelen és porton olyan elrendezést igényel, amelyet a megvalósítás dokumentál, nem olyat, amelyet kiesés közben kitalál. Az a táblázat az az artefaktum is, amely a következő változtatást áttekinthetővé teszi.

Külön címek vagy egy második port teszik láthatóvá a tulajdonjogot egy csomagrögzítésben, és ez többet ér az eleganciánál. Egyes VPN-megvalósítások támogatják a port megosztását webszerverrel, de a mechanizmus sajátos: a démon megvizsgálja az első bájtokat, és továbbítja azt a forgalmat, amely nem a saját protokollja. Az általános HTTP fordított proxy nem teszi ezt, és a fejlécek átírása nem fogja megérteni egy titkosított alagút kézfogását. Olvassa el a protokoll telepítési jegyzeteit, például az OpenVPN-hallgató dokumentációját, és kövesse az általa leírt elrendezést.

Döntse el, melyik identitás melyik szolgáltatáshoz tartozik

A böngészőtanúsítvány és a VPN-társ hitelesítő adata különböző objektumok különböző bizalmi modellekkel. A webes tanúsítványt nyilvános hatóság érvényesíti, és hosztnevet nevez meg, míg a társ hitelesítő adata egy eszközt vagy felhasználót hitelesít a koncentrátor felé, és lehet önaláírt vagy belsőleg kiállított. Az egyiknek a másikként való újrafelhasználása szűk esetekben működik, és ritkán éri meg a csatolást. Az ellenőrzés kikapcsolása, hogy egy megosztott tanúsítvány beleférjen, nem elkülönítési terv; eltávolítja azt az ellenőrzést, amely értelmet adott a hitelesítő adatnak.

Tartsa a két tárolót függetlenül, és írja le, melyik hatóság melyiket állítja ki. Amikor az egyiket cserélik, a másiknak nem kellene változnia, és ha mégis, a csatolás az, amit javítani kell.

Döntse el, hol él az adminisztráció

A VPN adminisztratív felülete a kezelési útvonalra tartozik, soha nem a nyilvános hallgatóra, akkor sem, ha a gazdagép már szolgálja az internetet. Egy 443-as webszerver nem jelenti azt, hogy a társ-konzolnak mindenhonnan elérhetőnek kellene lennie, és a konzol általában a nagyobb értékű célpont. Kösse loopback- vagy kezelési címhez, korlátozza forrás szerint, és tartson olyan helyreállítási útvonalat, amely nem függ attól, hogy az alagút fenn van. A helyreállítási útvonal fontos, mert a szokásos hiba az, hogy kizárja magát, miközben a zárat javítja.

Írjon szűk tűzfalszabályokat, egyet hallgatónként, megnevezve a felületet vagy a szolgáltatásfiókot ott, ahol a platform támogatja. A széles szabályok, amelyek azért nyitják meg a gazdagépet, mert a webhelynek 443 kell, azok az utak, amelyeken az adminisztratív felületek beszkennelt indexekbe kerülnek.

Tekintse át ezeket a szabályokat a hallgató-táblázattal szemben minden alkalommal, amikor szolgáltatás kerül hozzáadásra. Az áttekintés olcsó, és elkapja azt a szabályt, amelyet valaki hajnali kettőkor adott hozzá.

Döntse el, mit tegyen, amikor a kettő verseng

Egy gazdagép megosztása a processzor, a memória, a fájlleírók és a sávszélesség megosztását jelenti, és a vitatott erőforrás nem mindig a nyilvánvaló. Egy forgalmas webhely megtöltheti a kapcsolattáblát, kimerítheti a munkaréseket, vagy olyan erősen nyomhatja a lemezsort, hogy a VPN naplózása elakad. Szolgáltatásonként nézze a használatot, ne a gazdagép összesített értékeit, mert az átlag elrejti, melyik folyamat éhezik. Ha az egyik terhelés ismételten zavarja a másikat, izolálja őket ahelyett, hogy a tünet körül hangolná.

Az izoláció lehet konténer, cgroup-korlát, külön sor vagy második gazdagép, és a helyes választás attól függ, melyik erőforrás verseng. A port módosítása itt semmit sem javít, és a nagyobb példány sem javít semmit, ha a korlát egy telített sor. Méréssel döntsön: nevezze meg az erőforrást, terhelje meg, majd válassza a legkisebb izolációt, amely megszünteti a versengést.

Kívülről ellenőrizze, majd újraindítás után ismét

Olyan eszközről teszteljen, amely nem a gazdagép saját hálózatán van: töltse be a webhelyet, emelje fel az alagutat, és érjen el egy erőforrást, amely megköveteli. Utána indítsa újra külön-külön minden szolgáltatást, és ismételje meg a másik tesztet, mert az újraindítás az a pillanat, amikor egy megosztott hallgató-elrendezés elveszíti a sorrendjét. Ha a VPN a megosztott portot birtokló webszerver előtt indul, a megosztási mechanizmus soha nem kapcsolódhat be, és a tünet egy tegnap működő alagút. Tegye kifejezetté a függőséget az egységek sorrendjében.

Utána erősítse meg a határokat: a webhely a saját portján válaszol, a VPN a sajátján, és az adminisztratív felület csak a kezelési útvonalról válaszol. Jegyezze fel az eredményt a hallgató-táblázat mellé a dátummal. Az a gazdagép, amely újraindítás után mindhárom ellenőrzést teljesíti, olyan gazdagép, amelyet eligazítás nélkül átadhat valaki másnak.

Kapcsolódó cikkek