Cilën adresë burimore do të regjistrojë NGINX për një klient VPN?
Vendosni çfarë sheh NGINX pranë OpenVPN në një host të vetëm: një adresë të brendshme tuneli, një adresë publike dalëse apo një partner të përcjellë, sipas rrugës së ndjekur.
Në një instalim NGINX me OpenVPN në të njëjtin host shfaqen tre adresa klienti, një për secilën rrugë që mund të marrë një kërkesë. Një shfletues që arrin adresën e tunelit, një shfletues që arrin adresën publike dhe një program që del nëpër rrugën e internetit të portës duken të ndryshëm në soketin e dëgjimit. Vendosni cilën rrugë po shikoni përpara se të interpretoni rreshtin e regjistrit. Vendimi varet nga destinacioni që përdori klienti, nga përjashtimi që mban për pikën e jashtme të VPN-së dhe nga fakti nëse diçka e përkthen paketën gjatë rrugës.
Vendosni sipas destinacionit, jo sipas kush është përdoruesi
Filloni me adresën ku u dërgua kërkesa, sepse ajo adresë zgjedh rrugën. Një kërkesë drejt adresës së tunelit të hostit arrin në ndërfaqen e tunelit me adresën e brendshme të klientit si burim. Një kërkesë drejt adresës publike të hostit zakonisht arrin në ndërfaqen e kthyer nga interneti me adresën publike të klientit, edhe kur i njëjti laptop ka një tunel të ngritur në atë moment. Anëtarësimi në grupin e VPN-së është pra veti e rrugës së paketës, jo veti që ndjek përdoruesin.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
Pikërisht ky rresht i tretë ia vlen të kontrollohet i pari kur një përdorues VPN shfaqet në regjistër me një adresë që nuk ka asnjë lidhje me tunelin. Shpjegon gjithashtu pse dy përdorues me të njëjtin profil mund të prodhojnë zëra të ndryshëm: rrjetet e tyre të aksesit ndryshojnë dhe asgjë në tunel nuk e mbishkruan këtë.
Pse pika e jashtme krijon një rrugë të dytë publike
Klienti duhet të arrijë adresën publike të portës për të ngritur tunelin, ndaj duhet të ekzistojë një rrugë drejt asaj adrese jashtë tunelit. Kur një klient ridrejton gjithë trafikun nga brenda, një zbatim i arsyeshëm mban një rrugë hosti të qartë për adresën publike të serverit, për të shmangur një tunel që varet nga vetja. Ky përjashtim nuk bën dallim mes shërbimeve, ndaj çdo kërkesë drejt së njëjtës adresë publike e ndjek, përfshirë një kërkesë shfletuesi drejt një sajti të strehuar në portë.
Ky është mekanizmi pas shumicës së raporteve konfuze në këtë fushë dhe varet nga zbatimi i klientit, jo i serverit. Dy klientë me profile identike mund të sillen ndryshe. Heqja e përjashtimit për të »rregulluar« regjistrin rrëzon edhe tunelin, ndaj mbajeni dhe projektoni rreth tij.
Lexoni së bashku soketin, tabelën dhe formatin e regjistrit
Tre vëzhgime përcaktojnë cilën rrugë po shikoni: ku dëgjon soketi, cila ndërfaqe përgjigjet destinacionit dhe çfarë regjistron vërtet formati i regjistrit. Nëse dëgjuesi është i lidhur vetëm me adresën e tunelit, një kërkesë publike nuk mund ta arrijë fare, gjë që përjashton menjëherë dy rreshta. Nëse kërkimi për klientin kthen pajisjen e tunelit, kërkesa mbërriti me burim të brendshëm dhe regjistri duhet ta tregojë.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44Më pas lexoni formatin dhe jo rreshtin. Një fushë e ushqyer nga një krye e përcjellë regjistron një pohim, jo një partner soketi, dhe pohimi ka vlerë vetëm kur partneri i menjëhershëm është një përfaqësues i besuar. Shkrimi i të dy vlerave në regjistër i zgjidh debatet e mëvonshme, sepse partneri i menjëhershëm dhe adresa e zëvendësuar janë fakte të ndryshme dhe vetëm njëri prej tyre erdhi nga rrjeti.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confZgjidhni pikën e hyrjes që doni dhe bëni DNS-në të pajtohet
Nëse sajti është menduar vetëm përmes tunelit, jepini një emër që për klientët VPN zgjidhet në adresën e tunelit dhe zbatoni politikën në soketin e dëgjimit. Një përgjigje DNS e ndarë që kthen 10.24.0.1 për emrin e brendshëm është një vendim rrugëtimi i veshur si hollësi e zgjidhjes së emrave. Nëse sajti duhet të jetë edhe publik, mbani dy emra ose dy porta dhe lërini regjistrit t'ju thotë cila e shërbeu kërkesën.
Rregullat e lejimit ndjekin të njëjtën logjikë. Lejimi i grupit të tunelit nuk autorizon një kërkesë publike dhe nuk do të plotësojë një adresë të brendshme në një lidhje që mbërriti përmes internetit. Përzierja e të dy pikave të hyrjes nën një emër e kthen burimin e regjistruar në një efekt anësor të rrugëtimit të klientit në vend të një zgjedhjeje projektimi.
Verifikoni rrugën, pastaj politikën
Konfirmoni rrugën me një kapje në portë dhe me një kërkesë që e kontrolloni ju. Një kapje në pajisjen e tunelit dhe një në ndërfaqen publike tregojnë cila i mbarti bajtët, dhe radha e paketave ju thotë nëse ndodhi një përkthim mes tyre.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5Më pas verifikoni aksesin në të dy drejtimet: pika e hyrjes me emrin e synuar funksionon për klientin e synuar, dhe një rrugë publike e paautorizuar refuzohet në vend që thjesht të jetë e ngadaltë. Një sajt i përgjithshëm jehone IP provon diçka për daljen e portës në internet dhe asgjë për këtë sajt në të njëjtin host. Kur një faqe dhe një WebSocket nuk merren vesh, krahasoni URL-të, familjet e adresave dhe përgjigjet DNS përpara se të prekni konfigurimin e serverit.