Watter bronadres sal NGINX vir 'n VPN-kliënt in die log skryf?

Drie kliëntadresse verskyn in 'n NGINX-plus-OpenVPN-opstelling op dieselfde gasheer, een vir elke roete wat 'n versoek kan volg. 'n Blaaier wat die tonneladres tref, 'n blaaier wat die openbare adres tref, en 'n program wat deur die poort se internetroete uitgaan, lyk almal anders by die luistersok. Bepaal watter roete jy sien voordat jy die logreël vertolk. Die beslissing hang af van die bestemming wat die kliënt gebruik het, die uitsondering wat dit vir die buitenste VPN-eindpunt het, en of iets die pakkie onderweg vertaal.

Besluit volgens bestemming, nie volgens wie die gebruiker is nie

Begin met die adres waarnatoe die versoek gestuur is, want daardie adres kies die roete. 'n Versoek na die gasheer se tonneladres kom op die tonnelkoppelvlak aan met die kliënt se binneste adres as bron. 'n Versoek na die gasheer se openbare adres kom gewoonlik op die internetgerigte koppelvlak aan met die kliënt se openbare adres, selfs wanneer dieselfde skootrekenaar op daardie oomblik 'n tonnel opgerig het. Lidmaatskap van die VPN-poel is dus 'n eienskap van die pakkieroete, nie 'n eienskap wat die gebruiker volg nie.

Daardie derde ry is die een wat jy eerste moet nagaan wanneer 'n VPN-gebruiker in die log verskyn met 'n adres wat niks met die tonnel te doen het nie. Dit verduidelik ook waarom twee gebruikers op dieselfde profiel verskillende inskrywings kan lewer: hulle eie toegangsnetwerke verskil, en niks in die tonnel skryf dit oor nie.

Waarom die buitenste eindpunt 'n tweede openbare roete skep

Die kliënt moet die poort se openbare adres bereik om die tonnel op te rig, so 'n roete na daardie adres moet buite die tonnel bestaan. Wanneer 'n kliënt alle verkeer na binne herlei, hou 'n sinvolle implementering 'n eksplisiete gasheerreël vir die bediener se openbare adres om 'n tonnel te vermy wat van homself afhanklik is. Daardie uitsondering is nie kieskeurig oor dienste nie, so enige versoek na dieselfde openbare adres volg dit, insluitend 'n blaaierversoek vir 'n werf wat op die poort gehuisves word.

Dit is die meganisme agter die meeste verwarrende verslae in hierdie gebied, en dit is per kliëntimplementering eerder as per bediener. Twee kliënte met identiese profiele kan dus anders optree. Om die uitsondering te verwyder om die log te »herstel« neem die tonnel saam af, so hou dit en ontwerp daaromheen.

Lees die sok, die tabel en die logformaat saam

Drie waarnemings beslis watter roete jy sien: waar die sok luister, watter koppelvlak die bestemming antwoord, en wat die logformaat werklik aanteken. As die luisteraar slegs aan die tonneladres gebind is, kan 'n openbare versoek dit glad nie bereik nie, wat twee rye dadelik uitsluit. As die opsoek vir die kliënt die tonneltoestel teruggee, het die versoek met 'n binneste bron aangekom en die log behoort dit te wys.

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

Lees dan die formaat eerder as die reël. 'n Veld wat deur 'n deurgestuurde kop gevoed word, teken 'n bewering aan, nie 'n sokpeer nie, en die bewering maak net saak wanneer die onmiddellike peer 'n vertroude instaanbediener is. Om beide waardes in die log te skryf, besleg later argumente, want die onmiddellike peer en die vervangde adres is verskillende feite en net een daarvan het van die netwerk gekom.

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

Kies die toegangspunt wat jy wil hê en laat DNS saamstem

As die werf net-deur-tonnel moet wees, gee dit 'n naam wat vir VPN-kliënte na die tonneladres oplos, en handhaaf beleid op die luistersok. 'n Split-DNS-antwoord wat 10.24.0.1 vir die interne naam teruggee, is 'n roetebesluit in die gewaad van 'n naamoplossingsbesonderheid. As die werf ook openbaar moet wees, hou twee name of twee poorte en laat die log jou sê watter een die versoek bedien het.

Toelatingsreëls volg dieselfde logika. Om die tonnelpoel toe te laat, magtig nie 'n openbare versoek nie, en dit sal nie 'n binneste adres op 'n verbinding vul wat oor die internet aangekom het nie. Om beide toegangspunte onder een naam te meng, maak die aangetekende bron 'n newe-effek van kliëntroetering eerder as 'n ontwerpkeuse.

Verifieer die roete, dan die beleid

Bevestig die roete met 'n opname op die poort en 'n versoek wat jy beheer. 'n Opname op die tonneltoestel en een op die openbare koppelvlak wys watter die grepe gedra het, en die volgorde van die pakkies sê of 'n vertaling tussen hulle plaasgevind het.

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

Verifieer dan toegang in beide rigtings: die bedoelde genoemde toegang werk vir die bedoelde kliënt, en 'n nie-goedgekeurde openbare roete word geweier eerder as net stadig. 'n Algemene IP-eggowerf bewys iets oor die poort se internetuitgang en niks oor hierdie werf op dieselfde gasheer nie. Wanneer 'n bladsy en 'n WebSocket verskil, vergelyk hulle URL's, adresfamilies en DNS-antwoorde voordat jy aan die bedienerkonfigurasie raak.