Minkä lähdeosoitteen NGINX kirjaa VPN-asiakkaalle?
Päätä, mitä NGINX näkee OpenVPN:n rinnalla samalla isännällä: sisäisen tunneliosoitteen, julkisen lähtöosoitteen vai välitetyn vastapuolen, kuljettua polkua myöten.
Samalla isännällä NGINX- ja OpenVPN-asennuksessa näkyy kolme asiakasosoitetta, yksi kutakin polkua kohti, jonka pyyntö voi valita. Tunneliosoitteeseen osuva selain, julkiseen osoitteeseen osuva selain ja yhdyskäytävän internetpolkua pitkin poistuva ohjelma näyttävät kaikki erilaisilta kuuntelevalla pistokkeella. Päätä, mitä polkua katsot, ennen kuin tulkitset lokiriviä. Päätös riippuu asiakkaan käyttämästä kohteesta, sen ulkoiselle VPN-päätepisteelle pitämästä poikkeuksesta ja siitä, kääntääkö jokin pakettia matkalla.
Päätä kohteen, älä käyttäjän henkilöllisyyden perusteella
Aloita osoitteesta, johon pyyntö lähetettiin, koska se osoite valitsee polun. Pyyntö isännän tunneliosoitteeseen saapuu tunneliliittymälle asiakkaan sisäinen osoite lähteenä. Pyyntö isännän julkiseen osoitteeseen saapuu yleensä internetiin päin olevalle liittymälle asiakkaan julkisella osoitteella, vaikka samalla kannettavalla olisi tunnelia sillä hetkellä pystyssä. VPN-altaaseen kuuluminen on siis paketin polun ominaisuus, ei käyttäjää seuraava ominaisuus.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
Juuri tätä kolmatta riviä kannattaa katsoa ensin, kun lokiin ilmestyy VPN-käyttäjä osoitteella, jolla ei ole mitään tekemistä tunnelin kanssa. Se selittää myös, miksi kaksi samaa profiilia käyttävää käyttäjää voi tuottaa erilaisia merkintöjä: heidän omat käyttöverkkonsa eroavat, eikä mikään tunnelissa kirjoita sitä yli.
Miksi ulkoinen päätepiste luo toisen julkisen polun
Asiakkaan on saavutettava yhdyskäytävän julkinen osoite tunnelin muodostamiseksi, joten reitin kyseiseen osoitteeseen on oltava olemassa tunnelin ulkopuolella. Kun asiakas ohjaa kaiken liikenteen sisäänpäin, järkevä toteutus pitää palvelimen julkiselle osoitteelle eksplisiittisen isäntäreitin välttääkseen tunnelin, joka riippuu itsestään. Poikkeus ei ole palvelukohtainen, joten jokainen samaan julkiseen osoitteeseen tuleva pyyntö noudattaa sitä, mukaan lukien selaimen pyyntö yhdyskäytävällä isännöidylle sivustolle.
Tämä on mekanismi useimpien tämän alueen hämmentävien raporttien takana, ja se johtuu asiakastoteutuksesta eikä palvelimesta. Siksi kaksi samanlaista profiilia käyttävää asiakasta voi käyttäytyä eri tavoin. Poikkeuksen poistaminen lokin »korjaamiseksi« kaataa myös tunnelin, joten pidä se ja suunnittele sen ympärille.
Lue pistoke, taulukko ja lokiformaatti yhdessä
Kolme havaintoa ratkaisee, mitä polkua katsot: missä pistoke kuuntelee, mikä liittymä vastaa kohteeseen ja mitä lokiformaatti todella tallentaa. Jos kuuntelija on sidottu vain tunneliosoitteeseen, julkinen pyyntö ei voi saavuttaa sitä lainkaan, mikä sulkee heti pois kaksi riviä. Jos asiakkaan haku palauttaa tunnelilaitteen, pyyntö saapui sisäisellä lähteellä ja lokin pitäisi näyttää se.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44Lue sitten formaattia rivin sijaan. Välitetyn otsakkeen syöttämä kenttä tallentaa väitteen, ei pistokkeen vastapuolta, ja väitteellä on merkitystä vain, kun välitön vastapuoli on luotettu välityspalvelin. Molempien arvojen kirjaaminen lokiin ratkaisee myöhemmät väittelyt, koska välitön vastapuoli ja korvattu osoite ovat eri tosiasioita ja vain toinen niistä tuli verkosta.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confValitse haluamasi sisääntulopiste ja saa DNS samaan
Jos sivuston on oltava vain tunnelin kautta, anna sille nimi, joka VPN-asiakkaille ratkeaa tunneliosoitteeksi, ja valvo käytäntöä kuuntelevalla pistokkeella. Split-DNS-vastaus, joka palauttaa sisäiselle nimelle 10.24.0.1, on reitityspäätös nimenselvityksen yksityiskohdan asussa. Jos sivuston on oltava myös julkinen, pidä kaksi nimeä tai kaksi porttia ja anna lokin kertoa, kumpi pyyntöä palveli.
Sallintasäännöt noudattavat samaa logiikkaa. Tunnelialtaan salliminen ei valtuuta julkista pyyntöä eikä täytä sisäistä osoitetta yhteydelle, joka saapui internetin kautta. Molempien sisääntulopisteiden sekoittaminen yhden nimen alle tekee tallennetusta lähteestä asiakasreitityksen sivuvaikutuksen suunnittelupäätöksen sijaan.
Varmista polku ja sitten käytäntö
Vahvista polku yhdyskäytävällä tehtävällä kaappauksella ja pyynnöllä, jota hallitset. Kaappaus tunnelilaitteella ja julkisella liittymällä näyttävät, kumpi kuljetti tavut, ja pakettien järjestys kertoo, tapahtuiko niiden välissä käännös.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5Varmista sitten pääsy molempiin suuntiin: aiottu nimetty sisääntulo toimii aiotulle asiakkaalle ja hyväksymätön julkinen polku hylätään eikä vain ole hidas. Yleinen IP-kaikusivusto todistaa jotain yhdyskäytävän internetlähdöstä eikä mitään tästä samalla isännällä olevasta sivustosta. Kun sivu ja WebSocket ovat eri mieltä, vertaa niiden URL-osoitteita, osoiteperheitä ja DNS-vastauksia ennen palvelinkokoonpanon koskemista.