Kva for kjeldeadresse loggar NGINX for ein VPN-klient?

Tre klientadresser dukkar opp i eit NGINX- og OpenVPN-oppsett på same verten, éi for kvar veg ein førespurnad kan ta. Ein nettlesar som går til tunneladressa, ein nettlesar som går til den offentlege adressa, og eit program som går ut gjennom internetvegen til gatewayen, ser alle ulike ut ved den lyttande sockelen. Avgjer kva veg du ser på før du tolkar logglina. Avgjerda heng av kva mål klienten brukte, kva unntak han har for den ytre VPN-endepunktet, og om noko omset pakken på vegen.

Avgjer etter mål, ikkje etter kven brukaren er

Byrja med adressa førespurnaden vart send til, fordi den adressa vel vegen. Ein førespurnad til tunneladressa til verten kjem inn på tunnelgrensesnittet med den indre adressa til klienten som kjelde. Ein førespurnad til den offentlege adressa til verten kjem vanlegvis inn på grensesnittet som vender mot internett, med den offentlege adressa til klienten, jamvel når den same berbare datamaskina har ein tunnel oppretta i det augneblinken. Medlemskap i VPN-bassenget er difor ein eigenskap ved pakkevegen, ikkje ein eigenskap som følgjer brukaren.

Nettopp denne tredje rada er den det er verd å sjekke fyrst når ein VPN-brukar dukkar opp i loggen med ei adresse som ikkje har noko med tunnelen å gjere. Ho forklarer òg kvifor to brukarar med same profil kan gje ulike oppføringar: deira eigne tilgangsnett er ulike, og ingenting i tunnelen skriv over det.

Kvifor det ytre endepunktet lagar ein andre offentleg veg

Klienten må nå den offentlege adressa til gatewayen for å setje opp tunnelen, så det må finnast ein rute til den adressa utanfor tunnelen. Når ein klient leier all trafikk innover, held ei fornuftig implementering ei eksplisitt vertsrute til den offentlege adressa til tenaren for å unngå ein tunnel som er avhengig av seg sjølv. Det unntaket er ikkje selektivt med omsyn til tenester, så kvar førespurnad til den same offentlege adressa følgjer det, også ein nettlesarførespurnad til ein nettstad som er hosta på gatewayen.

Dette er mekanismen bak dei fleste forvirrande rapportane på dette feltet, og han ligg i klientimplementasjonen og ikkje i tenaren. To klientar med identiske profilar kan difor oppføre seg ulikt. Tek ein bort unntaket for å »reparere« loggen, fell tunnelen med, så hald på det og design kring det.

Les sockelen, tabellen og loggformatet saman

Tre observasjonar avgjer kva veg du ser på: kvar sockelen lyttar, kva grensesnitt som svarar på målet, og kva loggformatet faktisk registrerer. Viss lyttaren berre er bunden til tunneladressa, kan ein offentleg førespurnad ikkje nå han i det heile, noko som straks utelukkar to rader. Viss oppslaget for klienten gjev att tunnel-eininga, kom førespurnaden inn med ei indre kjelde, og loggen burde vise det.

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

Les så formatet i staden for lina. Eit felt som vert fôra av ein vidaresend header, registrerer ein påstand, ikkje ein sockelpart, og påstanden gjeld berre når den nære parten er ein påliteleg proxy. Å skrive begge verdiane i loggen avgjer seinare diskusjonar, fordi den nære parten og den erstatta adressa er ulike faktum og berre eitt av dei kom frå nettet.

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

Vel inngangspunktet du vil ha og få DNS til å seie det same

Viss nettstaden skal vere berre gjennom tunnelen, gje han eit namn som for VPN-klientar løyser ut til tunneladressa, og handhev politikk på den lyttande sockelen. Eit delt DNS-svar som gjev att 10.24.0.1 for det interne namnet, er eit rutingsval i kostyme av ein detalj om namneløysing. Viss nettstaden òg må vere offentleg, hald på to namn eller to portar og lat loggen seie kva som tente førespurnaden.

Løyvereglar følgjer same logikken. Å løyve tunnelbassenget gir ikkje rett til ein offentleg førespurnad, og det fyller ikkje ut ei indre adresse på ei tilkoping som kom over internett. Å blande begge inngangspunkta under eitt namn gjer den registrerte kjelda til ein sideverknad av klientruting i staden for eit designval.

Stadfest vegen, så politikken

Stadfest vegen med ein fangst på gatewayen og ein førespurnad du styrer. Ein fangst på tunnel-eininga og ein på det offentlege grensesnittet viser kva som bar byta, og rekkjefølgja på pakkane fortel deg om det skjedde ei omsetjing mellom dei.

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

Stadfest så tilgang i begge retningar: det tiltenkte namngjevne inngangspunktet verkar for den tiltenkte klienten, og ein ikkje-godkjend offentleg veg vert avvist i staden for berre å vere treg. Ein generell IP-ekko-nettstad provar noko om internettutgangen til gatewayen og ingenting om denne nettstaden på same verten. Når ei side og ein WebSocket er usamde, samanlikn URL-ane, adressefamiliane og DNS-svara deira før du rører ved tenarkonfigurasjonen.