Vilken källadress loggar NGINX för en VPN-klient?

Tre klientadresser dyker upp i en NGINX- och OpenVPN-installation på samma värd, en för varje väg en begäran kan ta. En webbläsare som når tunneladressen, en webbläsare som når den offentliga adressen och ett program som går ut via gatewayens internetväg ser alla olika ut vid den lyssnande socketen. Bestäm vilken väg du tittar på innan du tolkar loggraden. Beslutet beror på vilket mål klienten använde, vilket undantag den har för VPN:ens yttre slutpunkt och om något översätter paketet på vägen.

Bestäm efter mål, inte efter vem användaren är

Börja med adressen som begäran skickades till, eftersom den adressen väljer vägen. En begäran till värdens tunneladress kommer in på tunnelgränssnittet med klientens inre adress som källa. En begäran till värdens offentliga adress kommer vanligtvis in på det internetvända gränssnittet med klientens offentliga adress, även när samma bärbara dator har en tunnel upprättad i det ögonblicket. Medlemskap i VPN-poolen är därför en egenskap hos paketets väg, inte en egenskap som följer användaren.

Just den tredje raden är värd att kontrollera först när en VPN-användare dyker upp i loggen med en adress som inte har något med tunneln att göra. Den förklarar också varför två användare med samma profil kan ge olika poster: deras egna åtkomstnät skiljer sig, och inget i tunneln skriver över det.

Varför den yttre slutpunkten skapar en andra offentlig väg

Klienten måste nå gatewayens offentliga adress för att upprätta tunneln, så en rutt till den adressen måste finnas utanför tunneln. När en klient omdirigerar all trafik inåt behåller en förnuftig implementering en explicit värdrutt till serverns offentliga adress för att undvika en tunnel som beror av sig själv. Undantaget är inte selektivt när det gäller tjänster, så varje begäran till samma offentliga adress följer det, inklusive en webbläsarbegäran till en webbplats som ligger på gatewayen.

Detta är mekanismen bakom de flesta förvirrande rapporterna på området, och den hör till klientimplementeringen snarare än servern. Två klienter med identiska profiler kan därför bete sig olika. Tar man bort undantaget för att »laga« loggen faller tunneln med, så behåll det och designa runt det.

Läs socketen, tabellen och loggformatet tillsammans

Tre observationer avgör vilken väg du tittar på: var socketen lyssnar, vilket gränssnitt som svarar på målet och vad loggformatet faktiskt registrerar. Om lyssnaren bara är bunden till tunneladressen kan en offentlig begäran inte nå den alls, vilket utesluter två rader direkt. Om uppslagningen för klienten returnerar tunnel-enheten kom begäran in med en inre källa, och loggen borde visa det.

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

Läs sedan formatet i stället för raden. Ett fält som matas av en vidarebefordrad header registrerar ett påstående, inte en socket-peer, och påståendet spelar bara roll när den närmaste peeren är en betrodd proxy. Att skriva båda värdena i loggen avgör senare diskussioner, eftersom den närmaste peeren och den ersatta adressen är olika fakta och bara en av dem kom från nätet.

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

Välj den ingångspunkt du vill ha och få DNS att hålla med

Om webbplatsen ska vara enbart via tunneln, ge den ett namn som för VPN-klienter löser ut till tunneladressen och genomdriv policy på den lyssnande socketen. Ett delat DNS-svar som returnerar 10.24.0.1 för det interna namnet är ett routingbeslut i kostym av en detalj om namnlösning. Om webbplatsen också måste vara offentlig, behåll två namn eller två portar och låt loggen säga vilken som betjänade begäran.

Tillåtelseregler följer samma logik. Att tillåta tunnelpoolen ger inte behörighet till en offentlig begäran och fyller inte i någon inre adress på en anslutning som kom över internet. Att blanda båda ingångspunkterna under ett namn gör den registrerade källan till en bieffekt av klientroutning i stället för ett designval.

Verifiera vägen, sedan policyn

Bekräfta vägen med en avlyssning på gatewayen och en begäran du kontrollerar. En avlyssning på tunnel-enheten och en på det offentliga gränssnittet visar vilken som bar byten, och paketens ordning talar om ifall en översättning skedde mellan dem.

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

Verifiera sedan åtkomst i båda riktningarna: den avsedda namngivna ingången fungerar för den avsedda klienten, och en icke godkänd offentlig väg avvisas i stället för att bara vara långsam. En generisk IP-eko-webbplats bevisar något om gatewayens internetutgång och inget om den här webbplatsen på samma värd. När en sida och en WebSocket är oense, jämför deras URL:er, adressfamiljer och DNS-svar innan du rör serverkonfigurationen.