En proxy -server er den som snakker med internett på dine vegne. For eksempel, hvis college -nettverket har blokkert https: // www.Facebook.com/men domenet https: // eksempelproxy.com er fremdeles tilgjengelig, så kan du besøke sistnevnte, og den vil videresende alle forespørslene dine for Facebook -servere til Facebook, og sende med svarene fra Facebook tilbake til nettleseren din.
For å oppsummere, sender en fullmakt forespørsler på vegne av en av flere klienter til alle servere ute på internett. En omvendt proxy oppfører seg på lignende måte.
EN Omvendt proxy mottar forespørsel fra alle klienter på vegne av en eller flere servere. Så hvis du har et par servere som er vert for WW1.eksempel.com og WW2.eksempel.com En omvendt proxy -server kan godta forespørsler på vegne av de to serverne, videresende disse forespørslene til sine respektive sluttpunkter der svaret blir generert og sendt tilbake til omvendt proxy for å bli videresendt tilbake til klientene.
Oppsettet
Før vi begynner. Jeg vil sette i stein hvordan oppsettet mitt ser ut, så når du prøver å implementere designen din, ville det være mindre forvirrende.
Jeg brukte Digitaloceans plattform for å spinne opp tre VP -er. De er alle på samme nettverk hver med sin egen private IP, og bare en VPS har en statisk offentlig IP (dette vil være vår omvendte proxy -server.)
VM/Hostname | Privat IP | Offentlig IP | Rolle |
ReverseProxy | 10.135.123.187 | 159.89.108.14 | Omvendt proxy, kjører nginx |
Node-1 | 10.135.123.183 | N/a | Kjører første nettsted |
Node-2 | 10.135.123.186 | N/a | Kjører andre nettsted |
De to forskjellige nettstedene som kjører har domenenavn WW1.Ranvirslog.com og 2. verdenskrig.Ranvirslog.com Og begge av dem peker på ReverseProxys offentlige IP, jeg.e, 159.89.108.14
Ideen bak privat IP er at de tre VM -ene kan snakke med hverandre via denne private IP -en, men en ekstern bruker kan bare få tilgang til den omvendte proxy VM på den offentlige IP -en. Dette er viktig å huske på. For eksempel kan du ikke SSH inn i noen av VM ved å bruke sin private IP.
Videre har både Node-1 og Node-2 en Apache-webserver som serverer to distinkte websider. Dette vil hjelpe oss å skille en fra en annen.
Det første nettstedet sier “Nettsted 1 fungerer!!!”
Tilsvarende viser det andre nettstedet dette:
Nettstedene dine kan variere, men hvis du vil gjenskape dette oppsettet som utgangspunkt, kan du kjøre APT-install Apache2 på Node-1 og Node-2. Rediger deretter filen/var/www/html/indeks.html slik at webserveren sier hva du vil at den skal si.
ReverseProxy VM er fremdeles uberørt. Alle VM -ene kjører Ubuntu 18.04 LTS, men du står fritt til å bruke ethvert annet operativsystem du vil ha. Du kan til og med etterligne dette ved hjelp av Docker -containere. Ved å opprette et brukerdefinert Docker Bridge-nettverk og gytebeholdere på det, kan du tilordne hver container en privat IP og videresende alle HTTP/HTTPS-proxy til en container, som vil være vår Nginx Reverse Proxy Container.
Så langt så bra.
Nginx standardkonfigurasjon
La oss begynne med å installere Nginx til ReverseProxy -serveren, jeg bruker Ubuntu så passende er pakkelederen min:
$ sudo apt install nginx
Før vi går videre en liten merknad om Nginxs konfigurasjon. Alle de forskjellige konfigurasjonsfilene er lagret i /etc /nginx inkludert nginx.Conf -fil som er hovedkonfigurasjonsfilen. Hvis vi ser på innholdet i denne filen (inne i HTTP -blokken), vil du legge merke til følgende to linjer:
..
inkluderer/etc/nginx/conf.d/*.Conf;
inkluderer/etc/nginx/nettsted-aktivert/*;
..
Den andre linjen inneholder alle filene i den nettstedaktiverte katalogen til Nginxs konfigurasjon. Dette er standardpraksisen på de fleste Debian-baserte distribusjoner. For eksempel har standard "Welcome to Nginx" -siden standard webside slik at vi trygt kan fjerne symlink. Originalen er fremdeles tilgjengelig på nettsteder-tilgjengelig katalog.
$ rm/etc/nginx/nettsted-aktivert/standard
Men når vi vil lage omvendt proxy -konfigurasjon, vil vi gjøre det i Conf.d katalog (med vårt filnavn som har en .Konftens forlengelse) Dette er universelt, og fungerer på tvers av alle distribusjoner, ikke bare Debian eller Ubuntu.
Hvis du ikke bruker Debian-basert distro, finner du standard Velkommen side konfigurasjon ved/etc/nginx/conf.d/standard.Conf bare flytt filen til et sted trygt hvis du vil bruke den i fremtiden (siden dette ikke er en symlink)
$ mv/etc/nginx/conf.d/standard.Conf ~/Standard.konf
Det kan noen ganger finnes i/etc/nginx/standard.D fordi folk bare ikke kan være enige om en enkelt enkel standard! Så du må gjøre litt graving i /etc /nginx -katalogen, for å finne ut av dette.
Legge til omvendte proxyblokker
Som nevnt før, er de to forskjellige domenenavnene jeg er vert for denne proxy
Så la oss opprette en fil per nettsted i/etc/nginx/conf.d/ mappe. Så vi er godt organiserte.
$ berøring/etc/nginx/conf.D/WW1.konf
$ berøring/etc/nginx/conf.D/WW2.konf
Du kan navngi filene hva du ønsker, så lenge den har en .Konf på slutten av navnet.
I den første filen ww1.Konf Legg til følgende linjer:
server
Lytt 80;
Hør [::]: 80;
Server_name WW1.Ranvirslog.com;
plassering /
proxy_pass http: // 10.135.123.183/;
proxy_buffering av;
proxy_set_header x-real-ip $ remote_addr;
Lytteuttalelsene forteller Nginx å lytte på port 80 for både IPv4 og IPv6 -tilfeller. Det sjekker deretter om servernavnet er WW1.Ranvirslog.com så sparker lokasjonsblokken inn og fullmakter forespørselen til http: // 10.135.123.183/ med buffering slått av. Dessuten sikrer Proxy_set_header ... Line at klientens opprinnelige IP blir videresendt til den proxied -serveren. Dette er nyttig i tilfelle du vil beregne antall unike besøkende osv. Ellers ville den proxied -serveren bare ha en besøkende - Nginx -serveren.
Alternativene buffere og set_header er helt valgfrie og legges bare til for å gjøre fullmakt så gjennomsiktig som mulig. For WW2.Ranvirslog.com nettsted, jeg la til følgende konfigurasjon på/etc/nginx/conf.D/WW2.konf:
server
Lytt 80;
Hør [::]: 80;
Server_name WW2.Ranvirslog.com;
plassering /
proxy_pass http: // 10.135.123.186/;
proxy_buffering av;
proxy_set_header x-real-ip $ remote_addr;
Lagre både filene og test om den generelle konfigurasjonen er gyldig eller ikke:
$ sudo nginx -t
Hvis det er feil, vil output fra kommandoen ovenfor hjelpe deg å finne og fikse dem. Start nå serveren på nytt:
$ service nginx omstart
Og du kan teste om det fungerte eller ikke ved å besøke de forskjellige domenenavnene i nettleseren din og se resultatet.
Hver enkeltes brukssak er forskjellig. Konfigurasjonen nevnt ovenfor kan trenge litt finjustering for å fungere for scenariet ditt. Kanskje kjører du flere servere på samme vert, men i forskjellige porter, i så fall vil proxy_pass ... -linjen ha http: // localhost: portnummer/som verdien.
Disse detaljene avhenger veldig av brukssaken din. For ytterligere detaljer om andre alternativer og tuneabler se de offisielle Nginx -dokumentene.