Tartalom

Bevezető

ISPConfig szerverünk szépen kezeli weboldalainkat, azonban ha a böngészőbe a szerver IP-címére vagy teljes hosztnevére hivatkozunk, akkor nem a várt eredményt kapjuk, mert ilyenkor az Apache2 Debian Default Page töltődik be, ami lényegében az Apache "üdvözlő" oldala. Ez persze nem tragikus hiba, de szépséghiba. Ebben a leírásban megnézzük, hogy hogyan állíthatjuk be Apache webkiszolgálónkat, hogy ilyenkor az általunk kívánt weboldal kerüljön betöltésre.

SSL beállítása előtt

A szerverre még nincs ráirányítva a domain név, így még csak az IP-címével lehet elérni, vagy a hosts fájlban beállított domain névvel vagy hosztnévvel. Ennél fogva még SSL sincs beállítva rajta.

Apache Default Page

Ha a szervert a teljes hosztnevével (FQDN) akarjuk elérni, vagy az IP-címével, akkor az Apache2 Debian Default Page töltődik be (természetesen Debian rendszerek esetén van ez a változat):

http://vps.linuxportal.eu/

http://178.238.208.205/

Ez a jól ismert Apache alapértelmezett oldala nem egy hiba miatt jelenik meg ilyenkor, hanem az Apache működéséből eredően. Nézzünk utána, hogy mi is történik valójában.

Apache konfigurációk sorrendje

Ha benézünk kicsit a motorháztető alá, a /etc/apache2/sites-enabled/ könyvtárba, akkor ezt látjuk:

Itt a névsorrend alapján kerülnek végrehajtásra a konfigok / virtualhostok. Az itteni lista alapján a következő történik:

Apache konfig: 000-apps.vhost

Feldolgozza a legelsőt, a 000-apps.vhost nevű szimbolikus linket, ami egy olyan Apache konfigurációra mutat ami a 8081-es porton figyelve a kéréseket, a különböző webes alkalmazásokat szolgáltatja ki a kliensek számára, mint például a webmail, phpMyAdmin, stb. Tehát minden olyasmit, amit a hosztnév vagy valamelyik weboldal domain neve után / jellel betölthető, mintha azok egy adott weboldal egyik alkönyvtárában lennének, de közben bármelyik weboldal után beírva betöltődnek.

Például a teljes hosztnévvel: https://vps.linuxportal.eu:8081/phpmyadmin, vagy simán a domain névvel: https://linuxportal.eu:8081/phpmyadmin/.
Egy phpMyAdmin példa a 8081-es porton HTTPS kapcsolattal:

A 8081-es portnak itt annyi a szerepe, hogy ez az Apache konfig az ISPConfig kezelőpanel saját SSL-jét használva védi le ezeket a webes szolgáltatásokat is. Ezt az SSL-t az ISPConfig telepítője kéri ki a Let's Encrypt-től, de ha valamilyen oknál fogva nem tudja ezt megtenni, akkor egy self-signed SSL-t generál magának. Jelen esetben ez utóbbi történt, mivel a domain név nem volt még ráirányítva a szerverre, tehát a hitelesítési folyamat nem sikerült.

Visszakanyarodva a konfighoz, ha belenézünk a 000-apps.vhost fájlba, akkor ezt találjuk benne:

Itt tehát azt láthatjuk, hogy ez a konfig/virtualhost a 8081-es porton figyel, lejjebb pedig hogy a /usr/local/ispconfig/interface/ssl/ispserver.crt fájlt használja a HTTPS kapcsolat kiépítésére.

De mivel a kiinduló problémánk alapjául szolgáló http://vps.linuxportal.eu/ vagy a http://178.238.208.205/ URL címeink nem tartalmaznak 8081-es portot, ezért az Apache át is ugorja ezt a konfigurációt, és lép a következőre a névsorban.

Apache konfig: 000-default.conf

A következő konfiguráció a sorban a 000-default.conf link, ami a ../sites-available/000-default.conf fájlra mutat. Ha ebbe is belenézünk:

Akkor itt láthatunk egy teljesen egyszerű virtualhost beállítást, ami csak a 80-as (HTTP) porton működik, és van neki egy /var/www/html webgyökér könyvtára. Ez a webgyökér könyvtár tartalmazza azt a bizonyos index.html fájlt, ami megjeleníti az Apache Debian "üdvözlő" oldalát. Mivel ez a konfig csak a 80-as porton működik, ezért az SSL beállítása után már nem lesz elérhető, hanem vagy hibát fog dobni, vagy bejön rajta valamelyik weboldal, stb. De majd ezt is részletezzük és javítjuk lejjebb.

Sima HTTP kapcsolatokon keresztül tehát így jelenik meg az Apache intro oldala. A következő fejezetben megnézzük, hogy érvényes SSL beállítása után hogyan alakulnak ezek a szerver elérési URL címek, és a rajtuk megjelenő tartalmak

SSL beállítása után

Mint ahogy a bevezetőben is említettem, ez a leírás párhuzamosan készült a Debian 11-es éles szerver telepítős leírással, ennek megfelelően ez a rész már a szerverre irányított linuxportal.eu domain név és az erre kikért működő Let's Encrypt SSL beállítása után került megírásra. Így tehát itt már a működő, érvényes SSL tanúsítvánnyal ellátott szerveren vizsgáljuk tovább az Apache beállításokat, és végezzük el az alapértelmezett weboldal beállítását is.

Apache Default Page

Itt most betöltjük ugyanannak a két URL címnek a HTTPS-es változatát:

https://vps.linuxportal.eu/

HTTPS-en már nem az Apache Default Page jön be, hanem az egyetlen weboldalunk. Ez most jelen esetben még rendben is lenne, mert nem hibát dobott, viszont ha több weboldal kerül a szerverre, akkor a névsorban a legelső fog jó eséllyel betöltődni, ami nem biztos hogy megfelelő lesz a számunkra.

Itt még további probléma az is, hogy bár bejön egy weboldal, de ebben az esetben nem a saját webcímével, hanem a szerver hosztnevével. Ami SEO szempontból nem jó, mivel a keresők elkezdik beindexelni ezzel az URL címmel is az adott weboldalt, amiből két probléma is adódhat:

• Ha több URL címen is elérhető pontosan ugyanaz a tartalom, és egyiken sincs a másikra utaló canonical link megjelölés, akkor azt a Google tartalom ismétlésnek veheti, és lejjebb sorolhatja weboldalunkat (mindkét URL címmel).
• Ha később felkerül a szerverre egy újabb weboldal, ami névsorban az elődje elé kerül, akkor onnantól az a weboldal fog bejönni rajta. Ez pedig még súlyosabb problémát jelent SEO szempontból, mert ilyenkor egy teljes URL struktúra fogja elveszíteni a SEO erejét, és egy új fog a helyére felépülni más tartalommal. Tehát ezt sem szeretnénk.

Ezért ezt javítanunk kell.

Érdekességképpen, most ezen a szerveren úgy állítottam be a körülményeket, mint ahogy most itt is vannak, hogy bemutathassam mi történik, ha például egy olyan weboldal van a tárhelyen ami ellenőrzi a futási URL címét:

(Természetesen a leírás végeztével ezen az oldalon is újra beállítom ezt a javítást, így ez a fenti kép csak a leírás készítésének idején lévő állapotot tükrözi.)

A Drupal CMS rendszer például ezt a hibát dobja ilyenkor hogy "The provided host name is not valid for this server.". Tehát érzékeli, hogy nem a megbízható címekről  (trusted hosts) fut a rendszer, és leállítja a fenti hibával. Ez se néz ki szebben, de még mindig jobb eset, mintha betöltődne egy másik URL címről, és "hagyná", hogy a keresők beindexeljék. Persze a Drupal nem ilyen megfontolásból teszi ezt, hanem inkább a saját rendszer biztonsága érdekében, de ez most itt is hasznos dolog.

http://178.238.208.205/

Sima HTTP-vel még ugyanúgy bejön az Apache oldala, és a HTTPS változata ugyanennek:

https://178.238.208.205/

Itt pedig ugyancsak bejön a névsorban a legelső oldal (jelenleg csak ez az egy van), és még az SSL-t is betölti hozzá, viszont hibát jelez, mivel az SSL az egy adott domain névre szól, nem pedig egy IP-címre.

A következő részben tehát megnézzük hogyan tudjuk orvosolni ezt a három hibásan működő szituációt.

Alapértelmezett weboldal beállítása

Célok meghatározása

A célunk tehát, hogy levédjünk minden olyan URL lehetőséget ahol nem szabályosan kerül betöltésre egy weboldal, és emiatt nem a várt módon működik a rendszer. A feladatok pedig az alábbiak:

• Ezekben az esetekben is egy fixen beállított weboldal töltődjön be. Jellemzően ez az elsődleges weboldal, de ha több weboldalunk is van, akkor akármelyik, de mi határozhassuk meg hogy melyik legyen az, ne a névsor alapján dőljön el.
• A betöltődő weboldal a saját url címére ugorjon, és azzal töltődjön be. Ezáltal az oldal is a rendeltetésének megfelelően fog működni, és a keresők sem indexelik "félre" tartalmainkat egy másik URL cím alatt. Erre a legalkalmasabb egy 301-es HTTP fejléc átirányítás, ami egy az egyben átdobja a böngészőt a megfelelő URL címre, azaz a saját címére.

Első körben vegyük sora a lehetőségeket. A fenti célokat az alábbi módokon tudjuk elérni:

• A virtualhost-ok sorrendjének átállításával (átnevezéssel a névsorban előrébb vesszük a betölteni kívánt weboldalt)
• Az alapértelmezett konfig megfelelő beállításával

Ezek közül az elsőt nem ajánlatos választani, mivel egy ISPConfig-os környezetben a kezelőpanel kapcsolgatja be és ki a virtualhost-okat, így nincs semmi garancia, hogy a módosításaink megmaradnának. Ezért a virtualhost linkek átnevezgetése a /etc/apache2/sites-enabled könytárban nem tanácsos. Ha egy LAMP szerveren lennénk, ott ez beleférne, mert ott rajtunk kívül nem állítgatja semmi ezeket, de itt nem mi kezeljük a virtualhost-okat, hanem az ISPConfig panel.

A második kivitelezés lesz a jó, mivel a már fentebb is megvizsgált /etc/apache2/sites-available/000-default.conf fájl az az Apache alapértelmezett konfigja, tehát ehhez szintén nem nyúl hozzá senki, így az ISPConfig sem módosítja ezt.

SSL engedélyezése a 000-default.conf konfigban

Nyissuk meg a /etc/apache2/sites-available/000-default.conf fájlt szerkesztésre:

nano /etc/apache2/sites-available/000-default.conf

Majd adjuk a végéhez az alábbi virtualhost részt:

<VirtualHost *:443>

        DocumentRoot /var/www/html

        SSLEngine On
        SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1
        SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt
        SSLCertificateKeyFile /usr/local/ispconfig/interface/ssl/ispserver.key

</VirtualHost>

Végül így néz ki a teljes fájlunk a módosítás után:

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

<VirtualHost *:443>

        DocumentRoot /var/www/html

        SSLEngine On
        SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1
        SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt
        SSLCertificateKeyFile /usr/local/ispconfig/interface/ssl/ispserver.key

</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Ezután indítsuk újra az Apache-ot:

systemctl restart apache2

Ezzel engedélyeztük az SSL-t a 000-default konfigban, aminek hatására az Apache nem fogja átugrani ezt a konfigurációt a HTTPS protokollal érkezők esetén sem, hanem végre fogja hajtani, mivel ez a konfiguráció a névsor szerint előrébb van, mint bármelyik domainhez tartozó "100"-al kezdődő virtualhost, valamint most már tartalmazza a 443-as port lekezelését is. SSL-nek pedig az ISPConfig kezelőpanel által is használt tanúsítványt állítjuk be.

SSL ellenőrzése a különböző URL-eken

Most ellenőrizzük a korábban vizsgált, hibásan működő URL-eket:

https://vps.linuxportal.eu/

Pont ennek kell itt történnie, tehát most már HTTPS-el is az alapértelmezett Apache konfig jön be. Korábban ezt átugrotta, és a weboldal töltődött be.

http://178.238.208.205/

Itt sima HTTP-vel nem történt eddig változás, ugyanúgy betöltődik az Apache Default Page, csak felsoroltam itt is, hogy egyben látszódjon mind a három URL variáció.

https://178.238.208.205/

És most már az IP-címmel is az Apache default konfigja jön be. Ugyan SSL hibát jelez, de ez itt most nem számít, mert itt az a lényeg, hogy az Apache ne ugorja át ezt a konfigot, hanem ezt futtassa le nekünk ilyenkor.

És most jöhet a 301-es átirányítás.

301-es átirányítás a megfelelő weboldalra

Most, hogy már mindhárom esetben az Apache 000-default.conf fájlja hajtódik végre, már csak át kell irányítani innen egy 301-es HTTP fejléccel (Moved permanently) az általunk kívánt weboldalra. Ilyenkor a cél weboldal a saját URL címével töltődik be, tehát minden a helyére kerül.

Az átirányítást kétféleképpen is megoldhatjuk:

• Az Apache 000-default.conf fájlban helyezünk el mindkét protokoll blokkjában a "Redirect 301 / https://www.linuxportal.eu/" sort, ezzel az Apache hajtaná végre az átirányítást a kívánt weboldalra, vagy
• a másik megoldás ha PHP-vel hajtatjuk végre a 301-es átirányítást.

A jelenlegi cél elérése szempontjából mindkét variációval pontosan ugyanazt a hatást érhetjük el: a fent említett mindhárom hibásan működő URL variáció esetén a beállított weboldalra ugrik át a böngésző.

Az Apache átirányítás hátránya

A kettő közül az első megoldás lenne az elegánsabb, mert így nem kellene további fájlokat is módosítani azonban ennek van egy hátránya. Ha a 000-default.conf fájlból hajtjuk végre az átirányítást egy adott weboldalra, akkor az Apache status modul által biztosított server-status útvonal sem lesz elérhető az eredeti localhost-on keresztül, és nem az Apache állapotok jelennek meg, amikor le szeretnénk kérni azokat. Ilyenkor így néz ki ennek a kimenete:

A szerver állapot lekérdezése az alapértelmezett módon:

curl http://localhost/server-status?auto

Itt jól láthatóan az Apache 301-es átirányításunk forráskódja jelenik meg. Csak akkor működik az állapot lekérdezése, ha az átirányított domain HTTP elérésével kérjük le:

curl http://linuxportal.eu/server-status?auto

Tehát az előző lekérésnek így kellene kinézni, de logikusan már csak az átirányított domain alól jön be.

Ezzel az a probléma, hogy azok a rendszer erőforrás elemző / megjelenítő programok, amik ennek a kimenére támaszkodnak, azok nem tudják hogy milyen domain alatt kellene ezt elérni, hanem csak a localhost-al próbálják betölteni. És ilyenkor nem jutnak hozzá az adatokhoz. Ilyen program például a Munin is, aminek Az Apache grafikonjait ennek a kimenetéből állítja össze.

Mindezt természetesen kipróbáltam, mint ahogy a többi leírás esetén is tesztelek mindent, és csak utána publikálom, hogy az itt lévő információk  megfeleljenek a valóságnak és segítségül szolgálhassanak másoknak is. Tehát emiatt az átirányítás miatt nálam le is álltak a Munin Apache grafikonjai, amíg ezt a részt teszteltem ezen a szerveren. Íme az érintett grafikonjaim:

Persze nem csak a Munin támaszkodik a server status adataira, hanem más egyéb rendszerállapot-figyelő programok is használhatják ennek a kimenetét adatforrásként, ezért ezt az átirányítást PHP fájban oldjuk meg.

Mindezt azért írtam le itt, hogy akik hasonló módon szeretnék beállítani az alapértelmezett weboldalukat a szerverükön, akkor az Apache default konfiban történő direkt átirányítást kerüljék el, bármennyire is kézenfekvőnek tűnik ez a megoldás. Persze be lehetne tenni útvonal kivételeket, hogy például a /server-status/ útvonalra ne legyen érvényes az átirányítás, stb, de sokkal egyszerűbb, ha PHP-ből oldjuk meg ezt az egészet 2-3 sorban. Így az Apache config is zavartalanul lefut, és csak a PHP-t meghívó böngészők kerülnek átirányításra.

Átirányítás PHP-vel

A PHP-vel történő átirányítás sem bonyolultabb, mindössze be kell lépnünk a /var/www/html könyvtárba:

cd /var/www/html

Majd itt nevezzük át az index.html fájlt, hogy ne ez töltődjön be (Így nem kell az Apache konfigban beállítani az index fájlt):

mv index.html index.html.bak

Majd hozzunk létre egy index.php fájlt:

nano index.php

És tegyük bele az alábbi sorokat:

<?php
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: https://www.linuxportal.eu");
    die();
?>

Persze itt se feledkezzünk meg átjavítani a saját webcímünkre az itteni példát!

Így a webgyökérben lévő PHP fájl lefut, és elvégzi a 301-es fejléc kiadását, majd az átirányítást. A die() csak amolyan plusz védelemnek van bent, ha esetleg nem valósulna meg az átirányítás, akkor ez mindenképp leállítja a végrehajtást, így nem töltődne be semmi, ezáltal a hibás tartalom sem. De az átirányítás szépen működik.

És ha most ránézünk a server status-ra az eredeti localhost-al:

curl http://localhost/server-status?auto

Akkor már erre a lekérésre is jönnek az adatok, tehát az erőforrás figyelő alkalmazások is gond nélkül működhetnek.

Alapértelmezett weboldal ellenőrzése az URL-címeken

Végül ellenőrizzük ismét a három, korábban hibásan működő URL-t, persze a saját domain neveinkkel, illetve IP-címeinkkel:

https://vps.linuxportal.eu/
http://178.238.208.205/
https://178.238.208.205/

Itt tehát működik mindhárom,  korábban hibásan működő eléréssel az alapértelmezett weboldal, ami már 301-es átirányítással a saját címére ugrik, és természetesen az SSL is működik (a harmadik, https-es IP-címes cím először dob egy SSL hibát, de azon átlépve ráugrik ugyanúgy a megfelelő oldalra).

Konklúzió

A szerver most már az elvárt működést produkálja a fentebb említett URL használat esetén is: az általunk meghatározott weboldal kerül betöltődésre mindegyik esetben. Így nem történik hibás keresőindexelés, valamint weboldalaink sem fognak hibásan működni a nem megfelelő URL címek miatt.