Два окремих веб-сервери за Netgate Forum DMZ
Після кількох тижнів, коли я намагався вирвати волосся, я прийшов попросити про вашу допомогу.
У мене є сервер, підключений до livebox за допомогою pfsense.
Я створив локальну мережу та DMZ
На DMZ ми знаходимо перший веб-сервер, який функціонує із зворотним проксі (squid) і доступний з локальної та мережевої.
Поки що все працює, однак історія ускладнюється, коли я намагаюся налаштувати другий веб-сервер.
Я завжди отримую доступ до 1-го сайту, але ніколи не до другого, я спробував правила перенаправлення портів/NAT, щоб загубити свою латинку.
Коли мені вдається керувати другим сервером (отримати доступ до веб-сторінки), інший стає недоступним.
Я міг пограти з віртуальним хостом. Однак ідея полягає в тому, щоб зрозуміти NAT у pfsense, щоб мати можливість будувати правильну інфраструктуру пізніше, не турбуючи вас.
Тож, якщо хтось може направити мене, я буду вдячний.
Брак знань та досліджень.
Роль NAT полягає в передачі заданого мережевого потоку з загальнодоступної IP на сервер.
У випадку веб-сервера потоки мережі складають або HTTP = 80/tcp, або HTTPS = 443/tcp. До речі, я не вказую домен (dns), і це нормально, і це слід розуміти !
Якщо ви хочете розмістити НЕ ОДИН веб-сервер (під одним іменем домену), а ДВА або БІЛЬШЕ веб-серверів, потрібно вставити зворотний проксі-сервер. Цей проксі зможе аналізувати HTTP-запити для передачі трафіку на його сервер, тобто відповідно до доменного імені. Як правило, проксі визначає "віртуальний хост", який забезпечить асоціацію "доменне ім'я" "веб-сервер".
Тому я вказав необхідні кроки:
- NAT виконується з pfSense,
- зворотний проксі-сервер, який зробив реферал,
- веб-сервери, які відповідають на доменні імена.
Якщо змішати кроки, це не спрацює .
Примітка: існує безліч зворотних проксі-серверів, починаючи з веб-серверів, таких як Apache або Nginx. Squid - це чистий і міцний проксі, можливо, простіше почати з веб-серверів .
NB2: Для трафіку з локальної мережі правило NAt не можна застосувати, тому вам потрібне локальне визначення dns для кожного веб-сервера, а точніше доменного імені !
Дякую, що знайшли час відповісти мені JDH.
Брак знань є певним.
Роль NAT для мене полягає у перекладі внутрішнього ІР, який буде доступний через публічну адресу.
Щодо потоків HTTP та HTTPS, я знаю принцип незахищеного HTTP та захищеного HTTPS із сертифікатом SSL.
У мене зворотний проксі, я визначив веб-сервер, відображення.
У мене є доменне ім’я та піддомени
Там, де я не можу зрозуміти, що це частина NAT, я повинен визначити IP-адресу WAN, тому я уявляю себе сервером Hyper-v або WAN-ногою pfsense (я тестував з двома рішеннями).
Тож, думаю, мене турбує правило NAT. Але якщо у вас є навчальний посібник або документація для спілкування зі мною, я зацікавлений, оскільки я можу знайти лише неправильну інформацію або з набагато більш ранньої версії.
Коли ми повторюємо, що нам потрібно ще більше досвіду, коли ми хочемо віртуалізуватись .
Я не знайомий з Hyper-V (і не прагну покращити це).
Принцип явно полягає в тому, щоб у гіпервізорі було 3 внутрішніх «перемикача». І це дуже ясно, оскільки ви можете побачити 3 різні мережі. Я буду називати ці 3 мережі «WAN», «DMZ» та «LAN». Чи повинен я вказати, що лише pfSense має 3 мережеві інтерфейси, кожен на "комутаторі" ?
Я думаю, це все лише для навчання, тому можна уявити єдину мережеву карту для машини, яка обов’язково буде пов’язана з глобальною мережею. Адреса, призначена самому гіпервізору, буде в "WAN". Просто надзвичайно складно мати фізичні ПК у "WAN" .
Найкраще було б мати 2 мережеві карти «WAN» та «LAN» з перемикачем, підключеним до «LAN» для фізичних ПК (і, звичайно, не використовувати Wi-Fi Livebox).
За допомогою однієї картки Livebox відправляє весь трафік до IP-глобальної мережі pfSense, що робить NAT IP-глобальної мережі (приватна адреса, що отримує весь потік до загальнодоступної IP-адреси Livebox) до IP-адреси зворотного проксі-сервера (у DMZ).
Думаю, ми погано зрозуміли одне одного.
Сміливо можу сказати, що добре знаю Hyper-V, комутатори тощо ...
Моя інфраструктура чудово працює з роздільною здатністю DNS і потоками.
Я змінив порт доступу на Pfsense, щоб зарезервувати порти 80 і 443 для Інтернету та безпеки.
Мій проксі-сервер і зворотний проксі також працюють.
Я думаю, що моя проблема випливає з моєї зворотної конфігурації проксі-сервера або правил NAT, якими я взагалі не керую на pfsense (наскільки я знаю, як їх робити на livebox).
Або вихідний (для якого я справді не розумів).
Для тих, хто зіткнеться з такими ж труднощами, як я, я в підсумку знайшов своє рішення.
Отже, я працював добре, але спочатку мені потрібно було правило виходу, і я помилився у прив’язці адреси.
Це посилання нічого не варто (і є помилковим) !
Неможливо змусити два однакових правила працювати: перше буде завжди виконуватися, друге ніколи. Більше того, кількість використання повинна чітко це вказувати.
Цілком очевидно, що пакет HTTP є пакетом IP, тому він надсилається на IP-адресу, що відповідає імені dns цільового веб-сервера. Але пакет HTTP (частина DATA) містить запит HTTP, який вказує ім'я dns. Тому веб-сервер або проксі-сервер аналізує запит і визначає, якому цільовому веб-серверу надіслати запит.
Dns Resolver представляє інтерес лише локально: визначає значення dns, які корисні локально. Якщо у вас є локальний сервер dns, ви робите те саме. (У посиланні dns надається в глобальну мережу, і не правила NAT працюють, повинен бути шлях до внутрішньої адресації, коротше дурниці).
Я відмовляюся допомагати вам:
- практичної інформації про конфігурацію дуже мало,
- Ваша схема погана: LAN не слід об’єднувати з WAN,
- ви вірите в посилання, яке нічому не відповідає
Однак я вказав вам найкращі практики.
JDH дякую за ваш відгук,
однак я справді не розумію, що ви говорите щоразу, чесно кажучи, я відчуваю, що читаю Вікіпедію.
Я не ставлю під сумнів ваші вміння, але хотів би знати ваш рівень.
Мій тренер перевірив цю інфраструктуру, він інженер систем та мереж.
Що стосується правил, то вони можуть помилятися, проте я знайшов ту ж інформацію в інших ТП або лабораторії.
У мене є AD, який дає мені роздільну здатність DNS із пересиланням на коробці.
Сподіваюся, вас не образити.
Правильна схема така
Інтернет-скринька (WAN) pfSense
то згідно з
pfSsense (LAN) внутрішній перемикач ПК
Сервери комутації pfSense (DMZ)
Якщо ви здійснюєте віртуалізацію, важливо мати принаймні 2 інтерфейси Ethernet.
Інтернет-коробка eth0/host/eth1 внутрішня мережа
Віртуальна машина pfSense матиме 2 мережеві інтерфейси: один підключений до eth0, інший до eth1; і ви будете керувати з "стажиста" (= eth1).
Якщо потрібно, ви додасте внутрішній перемикач на хост, щоб створити DMZ.
Якщо той, хто вам радить, скаже, що достатньо лише одного інтерфейсу і що це WAN, добре поміняйте друга !
Що стосується мого рівня, я займаюся брандмауером ще до 2000 року, це буде добре ?
Дякуємо за роз'яснення.
Тож я буду робити, як ви щодо діаграм.
Поточна інфраструктура:
Інтернет (FAI) => Livebox => сервер (Hyper-V) => з фіксованою адресацією та відповідними mac
сервер => Зовнішній комутатор => PfSense
PfSense => WAN (зовнішній комутатор) => LAN => DMZ
на Lan ми знаходимо AD та 3 віртуальні машини, які приєднуються до домену.
на DMZ є два незалежних сервери з dns.
Адміністрування PfSense здійснюється лише через сервер Hyper-V, а не через Інтернет, тому мені не потрібно мати другий Lan для адміністрування, SSH Pfsense відключений і оболонка заблокована.
AD має подвійну автентифікацію.
Я думаю, що ми говоримо більш-менш про одне і те ж, однак ви залишаєтесь на своїх знаннях і не слухаєте людей на цьому форумі (я бачив, як кілька людей сплелися з користувачами форуму), тому ми знімаємо в колах, це трохи соромно, більше ви говорите зі своїми знаннями Proxmox, що я знаю, що використовував його, а не Hyper-v, який працює по-іншому і забезпечує більшу гнучкість.
У мене вдома Proxmox (2 господарі). Але в бізнесі я займався Xen (мало) та VMware (непогано). Останнім часом у мене було 10 хостів VMware і близько 70 віртуальних машин.
Для брандмауера я зробив Raptor (зараз Symantec), Debian (або Linux) з рукописним сценарієм (iptables) або генератором (Shorewall), CheckPoint, прилади WatchGuard, Fortigate, Stormshield.
Я не впертий, у мене є "звички", постійні дослідження та читання, а також практика, якої вони необов'язково мають. які розігрують провокацію. (Алелери, які виступають проти, далеко не допомагають на форумі і навіть не присутні!)
У ваших поясненнях ми все ще не знаємо, чи є у вашого хоста 2 мережеві карти ! Тому що ви, здається, не розумієте, що це абсолютно важливо: було б глупо мати машини в зоні WAN (поле WAN pfSense) !
Адміністрування всіх ВМ повинно виконуватися з внутрішніх ПК (які не можуть бути в зоні WAN і з поважних причин.) А не з хоста Hyper-V: лише створення та ініціалізація ВМ.
(Більша гнучкість для Hyper-V? На мою думку, не правильний кваліфікатор! Ви, мабуть, не знаєте інших продуктів: у них спільне встановлення в 100-300 МБ проти принаймні 4 ГБ для Windows Core.
Ось більш детальна інформація з визначенням vSwitchs, створених на Hyper-V.
"У ваших поясненнях ми досі не знаємо, чи є у вашого хоста 2 мережеві карти ! Оскільки ви, здається, не розумієте, що це абсолютно важливо: було б глупо мати машини в зоні WAN (WAN-вікно pfSense)! ! "
Це аж ніяк не важливо, якщо адміністрування здійснюється локально, а не через Інтернет.
Якщо ви правильно подивитеся на схему, у мережі PfSense немає машин .
"Адміністрування всіх віртуальних машин повинно здійснюватися з внутрішніх ПК (які не можуть бути в зоні WAN і з поважних причин.) А не з хоста Hyper-V: лише створення та ініціалізація віртуальних машин."
- Дурне ні, безумовно, відсутність безпеки. Існує лише одна мережева карта, і я повторюю адміністрування PfSense, це робиться виключно від хосту (мається на увазі, от від віртуальної машини, у цьому випадку AD до білого списку).
"(Більша гнучкість для Hyper-V? Не гарна кваліфікація, на мій погляд! Ви, мабуть, не знаєте інших продуктів: у них спільне встановлення в 100-300 МБ проти принаймні 4 ГБ для Windows Core."
Я кажу не про гнучкість на рівні системи (послуги та вагу системи), а про створення та реалізацію vSwitch.
Чому я можу позаздрити такій системі, як Proxmox, за те, що я її використав, це лише той факт, що я можу швидко зробити Шаблон і мати змогу змінити його конфігурацію після розгортання, без того, щоб він потім зводився з глузду.
Щодо ESXI, я насправді цього не знаю, але він, однак, повинен бути дуже близьким до Proxmox з того, що я бачив.
PS: Цей обмін відкритий для всіх, не соромтеся надати свою думку, свої знання, ми завжди вчимось, навіть у когось із так званого молодшого профілю. наперед дякую.
Я забув згадати правило:
Адреси RFC1918 - це блоки мережевих IP-адрес, зарезервовані для приватних.
Однак я все-таки змінив порт адміністрування.
Гаразд, все віртуально, і є лише одна карта, тому обов’язково для WAN. Це дуже далеко від ідеалу .
Коли у вас є кілька фізичних ПК, вам доведеться слідувати тому, що я пишу: 2 мережеві карти в хості, одна підключена до коробки, інша до ПК (у локальній мережі) через фізичний комутатор.
Ви можете встановити ESXi (безкоштовно = безкоштовно) і навчитися користуватися ним: він професійний і дуже надійний. (Більше того, Hyper-V включений у ліцензію Windows і, отже, безкоштовний після придбання ліцензії Windows, чому більшість компаній купують, крім того, платні ліцензії VMware. Якщо ні, що VMware має "більше"?)
Якою б не була система віртуалізації, необхідно буде зрозуміти включені концепції мережі.
Так, ну ось, я старший технічний спеціаліст із систем та мереж, і я готую ступінь бакалавра, тому, думаю, я знаю, про що йде мова, але дякую за згадування концепцій.