Ce adresă sursă va consemna NGINX pentru un client VPN?

Într-o instalare NGINX cu OpenVPN pe același host apar trei adrese de client, una pentru fiecare cale pe care o poate lua o cerere. Un browser care ajunge la adresa tunelului, un browser care ajunge la adresa publică și un program care iese prin calea de internet a gateway-ului arată diferit la socketul de ascultare. Decideți la ce cale vă uitați înainte de a interpreta linia de jurnal. Decizia depinde de destinația folosită de client, de excepția pe care o are pentru punctul final extern al VPN-ului și de dacă ceva traduce pachetul pe drum.

Decideți după destinație, nu după cine este utilizatorul

Începeți cu adresa către care a fost trimisă cererea, pentru că acea adresă alege calea. O cerere către adresa tunelului hostului ajunge pe interfața tunelului cu adresa internă a clientului ca sursă. O cerere către adresa publică a hostului ajunge de obicei pe interfața orientată spre internet cu adresa publică a clientului, chiar și atunci când același laptop are un tunel stabilit în acel moment. Apartenența la pool-ul VPN este așadar o proprietate a căii pachetului, nu o proprietate care urmează utilizatorul.

Exact acest al treilea rând merită verificat mai întâi când un utilizator VPN apare în jurnal cu o adresă care nu are nicio legătură cu tunelul. Explică și de ce doi utilizatori cu același profil pot produce intrări diferite: rețelele lor de acces diferă, iar nimic din tunel nu suprascrie asta.

De ce punctul final extern creează o a doua cale publică

Clientul trebuie să atingă adresa publică a gateway-ului pentru a stabili tunelul, deci trebuie să existe o rută către acea adresă în afara tunelului. Când un client redirecționează tot traficul spre interior, o implementare rezonabilă păstrează o rută de host explicită către adresa publică a serverului pentru a evita un tunel care depinde de el însuși. Excepția nu face diferențe între servicii, așa că orice cerere către aceeași adresă publică o urmează, inclusiv o cerere de browser către un site găzduit pe gateway.

Acesta este mecanismul din spatele majorității rapoartelor confuze din acest domeniu și ține de implementarea clientului, nu a serverului. Doi clienți cu profiluri identice se pot deci comporta diferit. Eliminarea excepției pentru a »repara« jurnalul doboară și tunelul, așa că păstrați-o și proiectați în jurul ei.

Citiți socketul, tabelul și formatul jurnalului împreună

Trei observații decid la ce cale vă uitați: unde ascultă socketul, ce interfață răspunde destinației și ce consemnează de fapt formatul jurnalului. Dacă ascultătorul este legat doar de adresa tunelului, o cerere publică nu poate ajunge la el deloc, ceea ce elimină imediat două rânduri. Dacă căutarea pentru client returnează dispozitivul tunelului, cererea a sosit cu o sursă internă, iar jurnalul ar trebui să arate asta.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Apoi citiți formatul, nu linia. Un câmp alimentat de un antet redirecționat consemnează o afirmație, nu un peer al socketului, iar afirmația contează doar când peerul imediat este un proxy de încredere. Scrierea ambelor valori în jurnal închide discuțiile ulterioare, pentru că peerul imediat și adresa substituită sunt fapte diferite și doar unul dintre ele a venit din rețea.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Alegeți punctul de intrare dorit și faceți DNS-ul să fie de acord

Dacă site-ul trebuie să fie doar prin tunel, dați-i un nume care pentru clienții VPN se rezolvă la adresa tunelului și aplicați politica pe socketul de ascultare. Un răspuns DNS divizat care returnează 10.24.0.1 pentru numele intern este o decizie de rutare deghizată în detaliu de rezolvare a numelor. Dacă site-ul trebuie să fie și public, păstrați două nume sau două porturi și lăsați jurnalul să spună care a servit cererea.

Regulile de permitere urmează aceeași logică. Permiterea pool-ului tunelului nu autorizează o cerere publică și nu va completa o adresă internă pe o conexiune care a sosit prin internet. Amestecarea ambelor puncte de intrare sub un singur nume transformă sursa consemnată într-un efect secundar al rutării clientului în loc de o alegere de proiectare.

Verificați calea, apoi politica

Confirmați calea cu o captură pe gateway și o cerere pe care o controlați. O captură pe dispozitivul tunelului și una pe interfața publică arată care a transportat octeții, iar ordinea pachetelor vă spune dacă a avut loc o traducere între ele.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Apoi verificați accesul în ambele sensuri: punctul de intrare numit dorit funcționează pentru clientul dorit, iar o cale publică neaprobată este refuzată, nu doar lentă. Un site generic de ecou IP demonstrează ceva despre ieșirea gateway-ului în internet și nimic despre acest site pe același host. Când o pagină și un WebSocket nu sunt de acord, comparați URL-urile, familiile de adrese și răspunsurile DNS înainte de a atinge configurația serverului.