Hva er en omvendt fullmektig?

En proxy-server er den som snakker med Internett på dine vegne. For eksempel hvis høyskolens nettverk har blokkert https: // www.facebook.com / men domenet https: // exampleproxy.com er fremdeles tilgjengelig, så kan du besøke sistnevnte, og den vil videresende alle dine forespørsler om Facebook-servere til Facebook, og sende svarene fra Facebook tilbake til nettleseren din.

For å oppsummere sender en proxy forespørsler på vegne av en av flere klienter til alle servere ute på Internett. En omvendt fullmektig oppfører seg på samme måte.

EN omvendt fullmektig mottar forespørsel fra alle klienter på vegne av en eller flere servere. Så hvis du har et par servere som hoster ww1.eksempel.com og ww2.eksempel.com en omvendt proxy-server kan godta forespørsler på vegne av de to serverne, videresende forespørslene til deres respektive sluttpunkter der svaret genereres og sendes tilbake til den omvendte proxyen for å bli videresendt tilbake til klientene.

Oppsettet

Før vi begynner å tilpasse Nginx-konfigurasjonsfiler og lage en omvendt proxy-server. Jeg vil sette i stein hvordan oppsettet mitt ser ut, så når du prøver å implementere designet ditt, vil det være mindre forvirrende.

Jeg brukte DigitalOceans plattform for å spinne opp tre VPS. 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 / vertsnavn	Privat IP	Offentlig IP	Roll
Reverseproxy	10.135.123.187	159.89.108.14	Omvendt proxy, kjører Nginx
Node-1	10.135.123.183	Ikke relevant	Kjører første nettside
Node-2	10.135.123.186	Ikke relevant	Kjører andre nettsider

De to forskjellige nettstedene som kjører har domenenavn ww1.ranvirslog.com og WW2.ranvirslog.com og begge A-postene deres peker mot reverseproxyens offentlige IP, dvs.e, 159.89.108.14

Ideen bak privat IP er at de tre virtuelle maskinene kan snakke med hverandre via denne private IP, men en ekstern bruker kan bare få tilgang til den omvendte proxy-VM på sin offentlige IP. Dette er viktig å huske på. For eksempel kan du ikke ssh inn i noen av VM-ene ved hjelp av sin private IP.

Videre har både Node-1 og Node-2 en Apache-webserver som serverer to forskjellige nettsider. Dette vil hjelpe oss å skille hverandre fra hverandre.

Den første nettsiden sier “WEBSITE 1 WORKS!!!”

Tilsvarende viser det andre nettstedet dette:

Nettstedene dine kan variere, men hvis du vil replikere dette oppsettet som utgangspunkt, kjør apt install apache2 på Node-1 og Node-2. Rediger deretter filen / var / www / html / index.html slik at webserveren sier hva du vil at den skal si.

Revereproxy VM er fortsatt uberørt. Alle virtuelle maskiner kjører Ubuntu 18.04 LTS, men du kan bruke ethvert annet operativsystem du ønsker. 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 tildele hver container en privat IP og videresende all HTTP / HTTPS-proxyen til en container, som vil være vår Nginx omvendte proxy-container.

Så langt så bra.

Nginx standardkonfigurasjon

La oss begynne med å installere Nginx på reverseproxy-serveren, jeg bruker Ubuntu så apt er min pakkebehandling:

$ sudo apt installere nginx

Fjerner standardkonfigurasjon hvis du bruker Debian-basert distribusjon

Før vi går videre et lite notat 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 / nettsteder-aktivert / *;
..

Den andre linjen inneholder alle filene i den nettstedsaktiverte katalogen til Nginx-konfigurasjonen. Dette er standardpraksis for de fleste Debian-baserte distribusjoner. For eksempel har standard "Velkommen til Nginx" -siden en tilsvarende fil som heter standard på stedet / etc / nginx / sites-available / default med en symlink til / etc / nginx / sites-enabled /, men vi trenger ikke dette standard webside slik at vi trygt kan fjerne symlinket. Originalen er fremdeles tilgjengelig i kataloger som er tilgjengelige på nettsteder.

$ rm / etc / nginx / nettsteder-aktivert / standard

Men når vi oppretter omvendt proxy-konfigurasjon, vil vi gjøre det i conf.d-katalog (med filnavnet vårt som .conf utvidelse) dette er universelt, og fungerer på tvers av alle distribusjoner, ikke bare Debian eller Ubuntu.

Fjerner standardkonfigurasjon for andre distroer

Hvis du ikke bruker Debian-basert distro, vil du finne standard Velkomstside konfigurasjon på / etc / nginx / conf.d / standard.conf bare flytt filen til et sikkert sted 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 bli funnet i / etc / nginx / default.d fordi folk bare ikke kan bli 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 proxy-blokker

Som nevnt tidligere er de to forskjellige domenenavnene jeg er vert for denne fullmakten

1. ranvirslog.com (NETTSIDE 1) med IP 10.135.123.183
2. ranvirslog.com (WEBSITE 2) med IP 10.135.123.186

Så la oss lage en fil per nettsted i / etc / nginx / conf.d / mappe. Så vi er godt organisert.

$ touch / etc / nginx / conf.d / ww1.konf
$ touch / etc / nginx / conf.d / ww2.konf

Du kan navngi filene hva du måtte ønske, så lenge den har en .conf på slutten av navnet.

I den første filen ww1.conf legg til følgende linjer:

server
hør 80;
hør [::]: 80;
 
servernavn ww1.ranvirslog.com;
 
plassering /
proxy_pass http: // 10.135.123.183 /;
proxy_buffering av;
proxy_set_header X-Real-IP $ remote_addr;

Høringsuttalelsene forteller Nginx å lytte på port 80 for både IPv4- og IPv6-saker. Den sjekker deretter om servernavnet er ww1.ranvirslog.com, deretter sparker lokasjonsblokken inn og fullmakter forespørselen til http: // 10.135.123.183 / med buffering slått av. Videre sørger linjen proxy_set_header… for at klientens opprinnelige IP videresendes til den nærliggende serveren. Dette er nyttig hvis du vil beregne antall unike besøkende osv. Ellers ville den nærliggende serveren bare ha en besøkende - Nginx-serveren.

Alternativer for buffering og set_header er helt valgfrie og er bare lagt til for å gjøre proxyen så gjennomsiktig som mulig. For 2. verdenskrig.ranvirslog.com nettsted, la jeg til følgende konfigurasjon på / etc / nginx / conf.d / ww2.conf:

server
hør 80;
hør [::]: 80;
 
servernavn ww2.ranvirslog.com;
 
plassering /
proxy_pass http: // 10.135.123.186 /;
proxy_buffering av;
proxy_set_header X-Real-IP $ remote_addr;

Lagre begge filene og test om den generelle konfigurasjonen er gyldig eller ikke:

$ sudo nginx -t

Hvis det er feil, vil utdataene fra kommandoen ovenfor hjelpe deg med å finne og fikse dem. Start serveren på nytt:

$ service nginx start på nytt

Og du kan teste om det fungerte eller ikke ved å besøke de forskjellige domenenavnene i nettleseren din og se resultatet.

Konklusjon

Hver enkelt persons brukstilfelle er forskjellig. Konfigurasjonen nevnt ovenfor kan trenge litt tilpasning for å fungere for ditt scenario. Kanskje du kjører flere servere på samme vert, men i forskjellige porter, i så fall vil proxy_pass… -linjen ha http: // localhost: portNumber / som sin verdi.

Disse detaljene avhenger veldig av din brukstilfelle. For ytterligere detaljer om andre alternativer og innstillinger, se de offisielle Nginx-dokumentene.