Два отделни уеб сървъра зад Netgate Forum DMZ
След няколко седмици мъчане да си разкъса косата, идвам да помоля за вашата помощ.
Имам сървър, свързан към livebox с pfsense.
Създадох LAN и DMZ
На DMZ намираме първи WEB сървър, който е функционален с обратен прокси (squid) и достъпен от локалния и net.
Засега всичко работи, но историята се усложнява, когато се опитвам да настроя втори уеб сървър.
Винаги имам достъп до първия сайт, но никога до втория, опитах порта за пренасочване/NAT навсякъде, за да загубя латиница.
Когато успея да управлявам втория сървър (достъп до уеб страницата), другият става недостъпен.
Можех да играя с виртуален хост. Идеята обаче е да разберете NAT в pfsense, за да можете по-късно да изградите правилна инфраструктура, без да ви притеснява.
Така че, ако някой може да ме насочи, ще съм много благодарен.
Липса на знания и изследвания.
Ролята на NAT е да прехвърли даден мрежов поток от публичния IP към сървър.
В случай на уеб сървър, мрежовите потоци са или HTTP = 80/tcp, или HTTPS = 443/tcp. Между другото, аз не посочвам домейн (dns) и това е нормално и трябва да се разбере !
Ако искате да хоствате НЕ ЕДИН уеб сървър (под едно име на домейн), а ДВЕ или ПОВЕЧЕ уеб сървъри, трябва да вмъкнете обратен прокси сървър. Този прокси сървър ще може да анализира HTTP заявки за предаване на трафик към неговия сървър, т.е. според името на домейна. Обикновено проксито ще дефинира „виртуален хост“, което ще гарантира връзката „име на домейн“ с уеб сървъра.
Ето защо посочих необходимите стъпки:
- NAT, извършен от pfSense,
- обратното прокси, което направи препращането,
- уеб сървъри, които отговарят на имена на домейни.
Ако смесите стъпките, това няма да работи .
NB: има много обратни прокси, като се започне с уеб сървъри като Apache или Nginx. Squid е чист и силен прокси, може би е по-лесно да започнете с уеб сървъри .
NB2: За трафик от LAN правилото NAt не може да се приложи, така че се нуждаете от локална dns дефиниция за всеки уеб сървър или по-скоро име на домейн !
Благодаря ви, че отделихте време да ми отговорите JDH.
Липсата на знания е сигурна.
Ролята на NAT за мен е да превежда вътрешен IP, който ще бъде достъпен чрез публичния адрес.
По отношение на HTTP и HTTPS потоци знам принципа на незащитения HTTP и защитения HTTPS със SSL сертификат.
Имам обратен прокси, определих уеб сървъра, картографирането.
Имам име на домейн и поддомейни
Където не мога да разбера, че е NAT част, трябва да дефинирам WAN IP адреса, така че си представям, че на сървъра Hyper-v или WAN крака на pfsense (тествах с двете решения).
Така че предполагам, че моята грижа е свързана с правилото NAT. Но ако имате урок или документация, за да ми съобщите, интересувам се, защото мога да намеря невярна информация или от много по-ранна версия.
Когато повтаряме, че се нуждаем от още повече опит, когато искаме да виртуализираме .
Не съм запознат с Hyper-V (и не се стремя да подобря това).
Принципът е ясно да има 3 вътрешни "превключватели" в хипервизора. И това е много ясно, тъй като можете да видите 3 различни мрежи. Ще нарека тези 3 мрежи „WAN“, „DMZ“ и „LAN“. Трябва ли да посоча това, само pfSense има 3 мрежови интерфейса, всеки на „превключвател“ ?
Предполагам, че всичко е само за учене, така че човек може да си представи една мрежова карта за машината, която непременно ще бъде свързана с WAN. Адресът, присвоен на самия хипервизор, ще бъде в „WAN“. Просто е много сложно да имаш физически компютри в „WAN“ .
Най-доброто би било да имате 2 мрежови карти „WAN“ и „LAN“ с превключвател, свързан към „LAN“ за физическите компютри (и разбира се, да не използвате Wifi на Livebox).
С една карта Livebox изпраща целия трафик към IP WAN на pfSense, което прави NAT на IP WAN (частен адрес, който получава целия поток към публичния IP на Livebox) към IP на обратния прокси сървър (в DMZ).
Мисля, че не се разбрахме добре.
Мога спокойно да кажа, че познавам Hyper-V добре, ключове и т.н.
Моята инфраструктура работи перфектно DNS резолюция и потоци.
Промених порта за достъп на Pfsense, за да запазя портове 80 и 443 за мрежата и за сигурност.
Моят ликвид прокси и обратен прокси също работят.
Мисля, че проблемът ми идва от моята обратна прокси конфигурация или NAT правила, които изобщо не управлявам на pfsense (доколкото знам как да ги направя в кутията на живо).
Или изходящото (за което наистина не разбрах).
За тези, които биха се сблъскали със същата трудност като мен, в крайна сметка намерих своето решение.
Така че бях работил добре, но първо се нуждаех от правило за изходящи данни и греших при свързването на адрес.
Тази връзка е безполезна (и е невярна) !
Невъзможно е да накарате две еднакви правила да работят: първото винаги ще бъде изпълнено, второто никога. Освен това броят на употребите трябва ясно да го показва.
Напълно очевидно е, че HTTP пакетът е IP пакет, така че той се изпраща на IP адрес, съответстващ на dns името на целевия уеб сървър. Но HTTP пакетът (частта DATA) съдържа HTTP заявката, която посочва името dns. Следователно уеб сървърът или проксито ще анализира заявката и ще изведе до кой целеви уеб сървър да изпрати заявката.