Welk bronadres logt NGINX voor een VPN-client?

In een NGINX-plus-OpenVPN-opstelling op dezelfde host verschijnen drie clientadressen, één voor elk pad dat een verzoek kan nemen. Een browser die het tunneladres benadert, een browser die het openbare adres benadert en een programma dat via het internetpad van de gateway naar buiten gaat, zien er allemaal anders uit bij de luisterende socket. Bepaal welk pad u bekijkt voordat u de logregel interpreteert. De beslissing hangt af van de bestemming die de client gebruikte, van de uitzondering die hij voor het buitenste VPN-eindpunt heeft en van de vraag of iets onderweg het pakket vertaalt.

Beslis op bestemming, niet op wie de gebruiker is

Begin bij het adres waarnaar het verzoek is verzonden, want dat adres kiest het pad. Een verzoek naar het tunneladres van de host komt binnen op de tunnelinterface met het interne adres van de client als bron. Een verzoek naar het openbare adres van de host komt meestal binnen op de naar internet gerichte interface met het openbare adres van de client, zelfs wanneer dezelfde laptop op dat moment een tunnel heeft opgezet. Lidmaatschap van de VPN-pool is dus een eigenschap van het pakketpad, niet een eigenschap die de gebruiker volgt.

Precies die derde rij is het eerst waard om te controleren wanneer een VPN-gebruiker in de log verschijnt met een adres dat niets met de tunnel te maken heeft. Het verklaart ook waarom twee gebruikers met hetzelfde profiel verschillende regels kunnen opleveren: hun eigen toegangsnetwerken verschillen, en niets in de tunnel schrijft dat over.

Waarom het buitenste eindpunt een tweede openbaar pad maakt

De client moet het openbare adres van de gateway bereiken om de tunnel op te zetten, dus moet er buiten de tunnel een route naar dat adres bestaan. Wanneer een client al het verkeer naar binnen omleidt, houdt een verstandige implementatie een expliciete hostroute naar het openbare adres van de server aan om een tunnel te vermijden die van zichzelf afhangt. Die uitzondering is niet selectief voor diensten, dus elk verzoek naar hetzelfde openbare adres volgt hem, inclusief een browserverzoek naar een site die op de gateway wordt gehost.

Dit is het mechanisme achter de meeste verwarrende meldingen op dit gebied, en het ligt aan de clientimplementatie en niet aan de server. Twee clients met identieke profielen kunnen zich daarom anders gedragen. De uitzondering weghalen om de log te »repareren« haalt de tunnel mee onderuit, dus houd hem en ontwerp eromheen.

Lees de socket, de tabel en het logformaat samen

Drie waarnemingen beslissen welk pad u bekijkt: waar de socket luistert, welke interface de bestemming beantwoordt en wat het logformaat werkelijk vastlegt. Als de luisteraar alleen aan het tunneladres is gebonden, kan een openbaar verzoek hem helemaal niet bereiken, wat meteen twee rijen uitsluit. Als de opzoeking voor de client het tunnelapparaat teruggeeft, kwam het verzoek binnen met een interne bron en zou de log dat moeten tonen.

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

Lees daarna het formaat in plaats van de regel. Een veld dat door een doorgestuurde header wordt gevoed, legt een bewering vast, niet een socket-peer, en de bewering telt alleen wanneer de onmiddellijke peer een vertrouwde proxy is. Beide waarden in de log schrijven beslecht latere discussies, omdat de onmiddellijke peer en het vervangen adres verschillende feiten zijn en slechts één ervan van het netwerk kwam.

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

Kies het gewenste ingangspunt en laat DNS meewerken

Als de site alleen via de tunnel bereikbaar moet zijn, geef hem dan een naam die voor VPN-clients naar het tunneladres oplost en handhaaf beleid op de luisterende socket. Een gesplitst DNS-antwoord dat 10.24.0.1 voor de interne naam teruggeeft, is een routeringsbeslissing in het kostuum van een naamresolutiedetail. Als de site ook openbaar moet zijn, houd dan twee namen of twee poorten aan en laat de log zeggen welke het verzoek heeft bediend.

Toestemmingsregels volgen dezelfde logica. De tunnelpool toestaan machtigt geen openbaar verzoek en vult geen intern adres in op een verbinding die via internet binnenkwam. Beide ingangspunten onder één naam mengen maakt van de vastgelegde bron een neveneffect van clientroutering in plaats van een ontwerpkeuze.

Controleer eerst het pad, dan het beleid

Bevestig het pad met een opname op de gateway en een verzoek dat u beheert. Een opname op het tunnelapparaat en een op de openbare interface laten zien welke de bytes droeg, en de volgorde van de pakketten vertelt u of er tussen beide een vertaling plaatsvond.

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

Controleer daarna toegang in beide richtingen: het bedoelde benoemde ingangspunt werkt voor de bedoelde client, en een niet-goedgekeurd openbaar pad wordt geweigerd in plaats van alleen langzaam te zijn. Een algemene IP-echosite bewijst iets over de internetuitgang van de gateway en niets over deze site op dezelfde host. Wanneer een pagina en een WebSocket het oneens zijn, vergelijk dan hun URL's, adresfamilies en DNS-antwoorden voordat u de serverconfiguratie aanraakt.