Două servere web separate în spatele unui DMZ Netgate Forum

După câteva săptămâni de luptă să-mi smulg părul, vin să vă cer ajutorul.

Am un server conectat la un livebox cu pfsense.

Am creat o rețea LAN și un DMZ

Pe DMZ găsim un prim server WEB care este funcțional cu un proxy invers (calmar) și accesibil din rețeaua locală și din rețea.

Până acum totul funcționează, totuși povestea se complică când încerc să configurez un al doilea server web.

Accesez întotdeauna primul site, dar niciodată al doilea, am încercat regulile de port forward/NAT peste tot pentru a-mi pierde latina.

Când reușesc să operez al doilea server (acces la pagina web), celălalt devine inaccesibil.

Aș fi putut să mă joc cu o gazdă virtuală. Cu toate acestea, ideea este să înțelegeți NAT în pfsense pentru a putea construi ulterior o infrastructură corectă, fără a vă deranja.

Deci, dacă cineva mă poate îndruma, aș fi foarte recunoscător.

servere

Lipsa cunoștințelor și cercetării.

Rolul NAT este de a transfera un anumit flux de rețea, de la IP-ul public la un server.

În cazul unui server web, fluxurile de rețea sunt fie HTTP = 80/tcp, fie HTTPS = 443/tcp. Apropo, nu indic un domeniu (dns), iar acest lucru este normal și trebuie înțeles !

Dacă doriți să găzduiți NU un server web (sub un singur nume de domeniu), ci DOUĂ sau MAI MULTE servere web, trebuie să introduceți un proxy invers. Acest proxy va putea analiza cererile HTTP pentru a transmite trafic către serverul său, adică în funcție de numele domeniului. De obicei, proxy-ul va defini „gazdă virtuală” care va asigura asocierea „nume de domeniu” „server web”.

Prin urmare, am indicat pașii necesari:

  • NAT efectuat de la pfSense,
  • proxy invers care a făcut trimiterea,
  • servere web care răspund la nume de domenii.

Dacă amestecați pașii, nu va funcționa .

NB: există o mulțime de proxy inverse, începând cu servere web precum Apache sau Nginx. Squid este un proxy pur și puternic, poate este mai ușor să începeți cu servere web .

NB2: Pentru traficul din rețeaua LAN, regula NAt nu poate fi aplicată, deci aveți nevoie de o definiție dns locală pentru fiecare server web sau mai degrabă nume de domeniu !

Îți mulțumesc că ți-ai făcut timp să-mi răspunzi JDH.

Lipsa cunoștințelor este sigură.

Rolul NAT pentru mine este de a traduce un IP intern care va fi accesibil prin adresa publică.

În ceea ce privește fluxurile HTTP și HTTPS, cunosc principiul HTTP nesecurizat și HTTPS securizat cu un certificat SSL.

Am un proxy invers, am definit serverul Web, maparea.

Am un nume de domeniu și subdomenii

Unde nu pot să înțeleg este partea NAT, trebuie să definesc adresa IP WAN, așa că îmi imaginez cea a serverului Hyper-v sau a piciorului WAN al pfsense (am testat cu cele două soluții).

Deci, cred că îngrijorarea mea este legată de regula NAT. Dar dacă aveți un tutorial sau o documentație de comunicat cu mine, mă interesează pentru că pot găsi doar informații incorecte sau dintr-o versiune mult mai veche.

Când repetăm ​​că avem nevoie de și mai multă experiență atunci când vrem să virtualizăm .

Nu sunt familiarizat cu Hyper-V (și nu vreau să îmbunătățesc asta).

Principiul este clar să aveți 3 „comutatoare” interne în hipervizor. Și acest lucru este foarte clar, deoarece puteți vedea 3 rețele distincte. Voi numi aceste 3 rețele „WAN”, „DMZ” și „LAN”. Ar trebui să specific că, doar pfSense are 3 interfețe de rețea, fiecare pe un „switch” ?

Cred că totul este doar pentru învățare, așa că ne putem imagina o singură placă de rețea pentru mașină, care va fi neapărat asociată cu WAN. Adresa atribuită hipervizorului în sine va fi în „WAN”. Este foarte dificil să ai PC-uri fizice în „WAN” .

Cel mai bine ar fi fost să aveți 2 plăci de rețea „WAN” și „LAN” cu un comutator conectat la „LAN” pentru computerele fizice (și bineînțeles să nu folosiți Wifi-ul Livebox).

Cu un singur card, Livebox trimite tot traficul către IP WAN al pfSense, care face NAT-ul IP WAN (adresa privată care primește întregul flux către IP-ul public al Livebox) către IP-ul proxy-ului invers (în DMZ).

Cred că nu ne-am înțeles bine.
Pot spune în siguranță că știu bine Hyper-V, comutatoare etc.
Infrastructura mea funcționează perfect cu rezoluția și fluxurile DNS.
Am schimbat portul de acces la Pfsense pentru a rezerva porturile 80 și 443 pentru web și pentru securitate.

De asemenea, proxy-ul meu squid și proxy-ul invers funcționează.

Cred că problema mea provine din configurația mea de proxy invers sau din regulile NAT pe care nu le gestionez deloc pe pfsense (atât cât știu cum să le fac în livebox).

Sau Outbound (pentru care chiar nu am înțeles).

Pentru cei care ar întâmpina aceeași dificultate ca mine, am ajuns să găsesc soluția mea.

Așa că am funcționat bine, dar am avut nevoie mai întâi de o regulă de ieșire și m-am înșelat la legarea adresei.

Acest link nu are valoare (și este fals) !

Este imposibil să faci două reguli identice să funcționeze: prima va fi întotdeauna executată, a doua niciodată. Mai mult, numărul de utilizare trebuie să îl indice în mod clar.

Este perfect evident că un pachet HTTP este un pachet IP, deci este trimis la o adresă IP corespunzătoare numelui dns al serverului web țintă. Dar pachetul HTTP (partea DATA) conține cererea HTTP care specifică numele dns. Prin urmare, este serverul web sau proxy-ul care va analiza cererea și va deduce către ce server web țintă să trimită solicitarea.