Két külön webszerver a Netgate Forum DMZ mögött
Több hetes küzdelem után, hogy kitépjem a hajam, jöttem, hogy segítséget kérjek.
Van egy szerverem, amely egy pfsense-lel van összekapcsolva egy livebox-szal.
Létrehoztam egy LAN-ot és egy DMZ-t
A DMZ-n találunk egy első WEB szervert, amely egy fordított proxyval (tintahal) működik, és elérhető a helyi és a netről.
Eddig minden működik, azonban a történet bonyolulttá válik, amikor megpróbálok beállítani egy második webszervert.
Mindig elérem az 1. oldalt, de a másodikat soha, a port forward/NAT szabályokat mindenhol kipróbáltam, hogy elveszítsem a latin nyelvemet.
Amikor sikerül működtetnem a második szervert (elérem a weboldalt), akkor a másik elérhetetlenné válik.
Játszhattam volna virtuális géppel. Az ötlet azonban az, hogy megértsük a NAT-ot a pfsense-ben annak érdekében, hogy később egy megfelelő infrastruktúrát tudjunk kiépíteni anélkül, hogy zavarnánk.
Tehát ha valaki utalhat, nagyon hálás lennék.
Az ismeretek és a kutatások hiánya.
A NAT feladata egy adott hálózati folyamat átvitele a nyilvános IP-ről a szerverre.
Webkiszolgáló esetén a hálózati folyamatok vagy HTTP = 80/tcp vagy HTTPS = 443/tcp. Egyébként nem jelölök domént (dns), és ez normális, és meg kell érteni !
Ha nem EGY webkiszolgálót (egyetlen tartománynév alatt), hanem KETT vagy TÖBB webkiszolgálót szeretne tárolni, akkor fordított proxyt kell beillesztenie. Ez a proxy képes lesz elemezni a szerverre irányuló forgalom továbbításához szükséges HTTP kéréseket, azaz a domain név szerint. Általában a proxy meghatározza a „virtuális gazdagépet”, amely biztosítja a „tartománynév” és a „webszerver” társulást.
Ezért jeleztem a szükséges lépéseket:
- A NAT a pfSense-ből származik,
- a fordított meghatalmazás, amely az áttételt tette,
- webszerverek, amelyek válaszolnak a domain nevekre.
Ha összekevered a lépéseket, az nem fog működni .
Megjegyzés: rengeteg fordított proxy létezik, kezdve az olyan webszerverekről, mint az Apache vagy az Nginx. A tintahal tiszta és nagyszerű proxy, talán könnyebb a webszerverekkel kezdeni .
NB2: A LAN-ról érkező forgalomhoz az NAt szabály nem alkalmazható, ezért minden webszerverhez vagy inkább tartománynévhez helyi dns-definícióra van szükség. !
Köszönöm, hogy szánt időt arra, hogy válaszoljon nekem JDH.
Az ismeretek hiánya biztos.
A NAT szerepe számomra egy belső IP lefordítása, amely elérhető lesz a nyilvános címen.
A HTTP és a HTTPS folyamatok tekintetében ismerem a nem biztonságos HTTP és az SSL tanúsítvánnyal biztonságos HTTPS elvét.
Van egy fordított proxy, definiáltam a webkiszolgálót, a leképezést.
Van domain nevem és aldomainem
Ahol nem értem, hogy ez a NAT-rész, meg kell határoznom a WAN IP-címet, így elképzelhetem a Hyper-v szerver vagy a pfsense WAN-lábának címét (a két megoldással teszteltem).
Tehát azt hiszem, aggódom a NAT szabály miatt. De ha van oktatóanyagod vagy dokumentációd, amellyel közölheted velem, akkor érdekel, mert csak hibás információkat találok, vagy egy sokkal korábbi verzióból.
Amikor megismételjük, hogy még több tapasztalatra van szükségünk, amikor virtualizálni akarunk .
Nem ismerem a Hyper-V-t (és nem is szeretnék ezen javítani).
Az elv egyértelműen az, hogy 3 belső „kapcsoló” legyen a hipervizorban. És ez nagyon világos, mivel 3 különböző hálózatot láthat. Ezt a 3 hálózatot 'WAN'-nak,' DMZ'-nek és 'LAN-nak' hívom. Meg kell adnom, hogy csak a pfSense rendelkezik 3 hálózati felülettel, mindegyik „kapcsolón” ?
Gondolom, ez mind csak a tanuláshoz használható, így el lehet képzelni egyetlen hálózati kártyát a géphez, amely szükségszerűen a WAN-hoz fog társulni. A hipervizorhoz rendelt cím 'WAN' lesz. Szuper trükkös, ha fizikai számítógépek vannak a WAN-ban .
A legjobb az lett volna, ha 2 'WAN' és 'LAN' hálózati kártya található kapcsolóval, amely a LAN-hoz csatlakozik a fizikai számítógépekhez (és természetesen nem használnánk a Livebox Wifi-jét).
Egyetlen kártyával a Livebox az összes forgalmat elküldi a pfSense IP WAN-jára, amely az IP WAN NAT-ot (a teljes adatfolyamot a Livebox nyilvános IP-jére fogadó privát cím) a fordított proxy IP-jére (in DMZ).
Azt hiszem, nem értettük jól egymást.
Nyugodtan mondhatom, hogy jól ismerem a Hyper-V-t, kapcsolókat stb.
Az infrastruktúrám tökéletesen működik a DNS-felbontás és az áramlás terén.
A hozzáférési portot Pfsense-re változtattam, hogy fenntartsam a 80-as és a 443-as portot az internet és a biztonság érdekében.
A tintahal és a fordított proxy is működik.
Úgy gondolom, hogy a problémám a fordított proxy konfigurációmból vagy a NAT-szabályokból fakad, amelyeket egyáltalán nem kezelek a pfsense-n (amennyire tudom, hogyan kell ezeket megtenni a liveboxon).
Vagy a kimenő (amihez igazán nem értettem).
Azok számára, akik ugyanolyan nehézségekkel szembesülnek, mint én, végül megtaláltam a megoldásomat.
Tehát jól dolgoztam, de előbb kimenő szabályra volt szükségem, és tévedtem a címmegkötésnél.
Ez a link értéktelen (és hamis) !
Két azonos szabályt lehetetlen működtetni: az elsőt mindig végrehajtják, a másodikat soha. Ezenkívül a használati számlának egyértelműen jeleznie kell.
Teljesen nyilvánvaló, hogy a HTTP csomag IP-csomag, ezért a cél webkiszolgáló dns nevének megfelelő IP-címre kerül elküldésre. De a HTTP csomag (a DATA rész) tartalmazza a HTTP kérést, amely meghatározza a dns nevet. Ezért a webszerver vagy a proxy elemzi a kérést, és arra következtet, hogy melyik célszervernek küldje el a kérést.