Hokker boarneadres sil NGINX foar in VPN-klant yn it log skriuwe?

Bepaal wat NGINX njonken OpenVPN op ien host sjocht: in ynterne tunneladres, in iepenbier útgongsadres of in trochstjoerde peer, ôfhinklik fan it nommen paad.

Yn in NGINX-plus-OpenVPN-opsetsel op deselde host ferskine trije klantadressen, ien foar elk paad dat in fersyk nimme kin. In browser dy't it tunneladres oanrekket, in browser dy't it iepenbiere adres oanrekket en in programma dat fia it ynternetpaad fan 'e gateway nei bûten giet, sjogge der by de harkjende socket allegear oars út. Bepaal hokker paad jo sjogge foardat jo de logrigel ynterpretearje. De beslissing hinget ôf fan 'e bestimming dy't de klant brûkte, fan 'e útsûndering dy't er foar it bûtenste VPN-einpunt hat en fan 'e fraach oft iets it pakket ûnderweis oerset.

Bepaal op bestimming, net op wa't de brûker is

Begjin mei it adres dêr't it fersyk hinne stjoerd waard, want dat adres kiest it paad. In fersyk nei it tunneladres fan 'e host komt op 'e tunnelinterface oan mei it ynterne adres fan 'e klant as boarne. In fersyk nei it iepenbiere adres fan 'e host komt meastentiids op 'e ynternet-rjochte interface oan mei it iepenbiere adres fan 'e klant, sels as deselde laptop op dat stuit in tunnel oprjochte hat. Lidmaatskip fan 'e VPN-pool is dus in eigenskip fan it pakketpaad, net in eigenskip dy't de brûker folget.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Just dy tredde rige is it wurdich earst te kontrolearjen as in VPN-brûker yn it log ferskynt mei in adres dat neat mei de tunnel te meitsjen hat. It ferklearret ek wêrom't twa brûkers op itselde profyl ferskillende ynskriuwings meitsje kinne: harren eigen tagongsnetwurken ferskille en neat yn 'e tunnel skriuwt dat oer.

Wêrom't it bûtenste einpunt in twadde iepenbier paad makket

De klant moat it iepenbiere adres fan 'e gateway berikke om de tunnel op te rjochtsjen, dus moat der bûten de tunnel in rûte nei dat adres bestean. As in klant al it ferkear nei binnen ta omleit, hâldt in ferstannige ymplemintaasje in eksplisite hostrûte foar it iepenbiere adres fan 'e server om in tunnel te foarkommen dy't fan himsels ôfhinklik is. Dy útsûndering is net selektyf oer tsjinsten, dus elk fersyk nei itselde iepenbiere adres folget him, ynklusyf in browserfersyk nei in side dy't op 'e gateway draaid wurdt.

Dit is it meganisme efter de measte betiizjende rapporten op dit mêd, en it is per klantymplemintaasje ynstee fan per server. Twa klanten mei identike profylen kinne har dus oars gedrage. It fuortheljen fan 'e útsûndering om it log te »repareren« hellet de tunnel mei del, dus hâld him en ûntwerp deromhinne.

Lês de socket, de tabel en it logformaat tegearre

Trije waarnimmings bepale hokker paad jo sjogge: wêr't de socket harket, hokker interface de bestimming beantwurdet en wat it logformaat echt fêstleit. As de harker allinne oan it tunneladres bûn is, kin in iepenbier fersyk him hielendal net berikke, wat twa rijen daliks útslút. As it sykjen foar de klant it tunnelapparaat weromjout, is it fersyk mei in ynterne boarne oankommen en soe it log dat sjen litte moatte.

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

Lês dan it formaat ynstee fan 'e rigel. In fjild dat troch in trochstjoerde kop fiede wurdt, registrearret in bewearing, net in socketpeer, en de bewearing docht der allinne ta as de direkte peer in fertroude proxy is. It skriuwen fan beide wearden yn it log besljochtet lettere diskusjes, want de direkte peer en it ferfongen adres binne ferskillende feiten en mar ien fan beide kaam fan it netwurk.

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

Kies it ynfierpunt dat jo wolle en lit DNS dermei iens wêze

As de side allinne fia de tunnel berikber wêze moat, jou har dan in namme dy't foar VPN-klanten nei it tunneladres oplost en hanthavenje belied op 'e harkjende socket. In split-DNS-antwurd dat 10.24.0.1 foar de ynterne namme weromjout, is in rûtebeslissing yn 'e klean fan in detail oer namme-oplossing. As de side ek iepenbier wêze moat, hâld twa nammen of twa poarten en lit it log jo sizze hokker fan beide it fersyk betsjinne hat.

Tastienningsregels folgje deselde logika. It tastean fan 'e tunnelpool machtiget gjin iepenbier fersyk en it sil gjin yntern adres folje op in ferbining dy't oer it ynternet kaam. It mingen fan beide ynfierpunten ûnder ien namme makket de fêstleine boarne in bywurking fan klantrouting ynstee fan in ûntwerpkar.

Kontrolearje it paad, dan it belied

Befêstigje it paad mei in opname op 'e gateway en in fersyk dat jo sels beheare. In opname op it tunnelapparaat en ien op 'e iepenbiere interface litte sjen hokker de bytes droegen hat, en de folchoarder fan 'e pakketten fertelt jo oft der in oersetting tusken plakfûn hat.

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

Kontrolearje dan tagong yn beide rjochtingen: it bedoelde neamde ynfierpunt wurket foar de bedoelde klant en in net-goedkarde iepenbier paad wurdt wegere ynstee fan allinne mar stadich te wêzen. In algemiene IP-echoside bewiist wat oer de ynternetútgong fan 'e gateway en neat oer dizze side op deselde host. As in side en in WebSocket fan miening ferskille, fergelykje harren URL's, adresfamyljes en DNS-antwurden foardat jo de serverkonfiguraasje oanreitsje.

Relatearre artikelen