Hvaða upprunavistfang skráir NGINX fyrir VPN-biðlara?
Ákvarðaðu hvað NGINX sér við hlið OpenVPN á sama hýsli: innra gönguvistfang, opinbert útgangsvistfang eða framsendan jafningja, eftir þeirri leið sem farin var.
Þrjú biðlaravistföng birtast í NGINX- og OpenVPN-uppsetningu á sama hýsli, eitt fyrir hverja leið sem beiðni getur farið. Vafri sem kemur á gönguvistfangið, vafri sem kemur á opinbera vistfangið og forrit sem fer út um netleið gáttarinnar líta allt öðruvísi út á hlustunarsokkinum. Ákvarðaðu hvaða leið þú ert að skoða áður en þú túlkar log-línuna. Ákvörðunin veltur á áfangastaðnum sem biðlarinn notaði, undantekningunni sem hann heldur fyrir ytra VPN-endapunktinn og hvort eitthvað þýðir pakkann á leiðinni.
Ákvarðaðu eftir áfangastað, ekki eftir því hver notandinn er
Byrjaðu á vistfanginu sem beiðnin var send á, því það vistfang velur leiðina. Beiðni á gönguvistfang hýsilsins berst á gönguviðmótið með innra vistfang biðlarans sem uppruna. Beiðni á opinbert vistfang hýsilsins berst venjulega á viðmótið sem snýr að netinu með opinberu vistfangi biðlarans, jafnvel þótt sami fartölvan hafi göng uppsett á þeirri stundu. Að tilheyra VPN-hópnum er því eiginleiki pakkaleiðarinnar, ekki eiginleiki sem fylgir notandanum.
| 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 |
Þriðja röðin er sú sem vert er að skoða fyrst þegar VPN-notandi birtist í log-inu með vistfang sem hefur ekkert með göngin að gera. Hún útskýrir líka hvers vegna tveir notendur á sama sniði geta myndað mismunandi færslur: eigin aðgangsnet þeirra eru ólík og ekkert í göngunum skrifar yfir það.
Hvers vegna ytri endapunkturinn býr til aðra opinbera leið
Biðlarinn verður að ná opinberu vistfangi gáttarinnar til að koma göngunum á, svo leið að því vistfangi verður að vera til utan gangnanna. Þegar biðlari beinir allri umferð inn á við heldur skynsamleg útfærsla sér skýrri hýsil-leið að opinberu vistfangi þjónsins til að forðast göng sem ráðast af sjálfum sér. Sú undantekning er ekki valin eftir þjónustum, svo sérhver beiðni á sama opinbert vistfang fylgir henni, þar á meðal vafrabeiðni á vef sem hýstur er á gáttinni.
Þetta er fyrirkomulagið að baki flestum ruglingslegum skýrslum á þessu sviði og það ræðst af útfærslu biðlarans frekar en þjónsins. Tveir biðlarar með sömu snið geta því hegðað sér á mismunandi hátt. Að fjarlægja undantekninguna til að »laga« log-ið fellir göngin líka, svo haltu henni og hannaðu í kringum hana.
Lestu sokkið, töfluna og log-sniðið saman
Þrjár athuganir ráða því hvaða leið þú ert að skoða: hvar sokkið hlustar, hvaða viðmót svarar áfangastaðnum og hvað log-sniðið skráir í raun. Ef hlustandinn er aðeins bundinn við gönguvistfangið getur opinber beiðni alls ekki náð til hans, sem útilokar tvær raðir í einu. Ef uppflettingin fyrir biðlarann skilar göngutækinu kom beiðnin með innra uppruna og log-ið ætti að sýna það.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44Lestu síðan sniðið frekar en línuna. Reitur sem fær næringu úr framsendum haus skráir fullyrðingu, ekki jafningja soksins, og fullyrðingin skiptir aðeins máli þegar næsti jafningi er treyst umboðsþjónn. Að skrifa bæði gildin í log-ið gerir upp síðari deilur, því næsti jafningi og hið staðgengna vistfang eru ólík staðreyndir og aðeins önnur þeirra kom úr netinu.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confVeldu innganginn sem þú vilt og láttu DNS samræmast
Ef vefurinn á að vera aðeins í gegnum göngin skaltu gefa honum nafn sem leysist í gönguvistfangið fyrir VPN-biðlara og framfylgja stefnu á hlustunarsokkinu. Klofin DNS-svör sem skila 10.24.0.1 fyrir innra nafnið er leiðarákvörðun í búningi smáatriðis um nafnupplausn. Ef vefurinn verður líka að vera opinber skaltu halda tveimur nöfnum eða tveimur pörtum og láta log-ið segja þér hvort sinnti beiðninni.
Leyfisreglur fylgja sömu rökvísi. Að leyfa gagnahópinn heimilar ekki opinbera beiðni og mun ekki fylla innra vistfang á tengingu sem kom um netið. Að blanda báðum inngöngum undir einu nafni gerir skráða upprunann að aukaverkun leiðar biðlarans í stað hönnunarákvörðunar.
Staðfestu leiðina, svo stefnuna
Staðfestu leiðina með töku á gáttinni og beiðni sem þú stýrir. Taka á göngutækinu og önnur á opinbera viðmótinu sýna hvor bar bætin, og röð pakkanna segir þér hvort þýðing átti sér stað á milli.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5Staðfestu síðan aðgang í báðar áttir: fyrirhugaði nefndi inngangurinn virkar fyrir fyrirhugaðan biðlara og ósamþykkt opinber leið er hafnað frekar en að vera bara hæg. Almennt IP-bergmálsvefsvæði sannar eitthvað um netútgang gáttarinnar og ekkert um þennan vef á sama hýsli. Þegar síða og WebSocket eru ósammála skaltu bera saman slóðir þeirra, vistfangafjölskyldur og DNS-svör áður en þú snertir þjónauppsetninguna.