Kiun fontan adreson NGINX protokolos por VPN-kliento?

Tri klientaj adresoj aperas en agordo de NGINX kaj OpenVPN sur la sama gastiganto, po unu por ĉiu vojo, kiun peto povas preni. Retumilo, kiu aliras la tunelan adreson, retumilo, kiu aliras la publikan adreson, kaj programo, kiu eliras tra la interreta vojo de la pordego, ĉiuj aspektas malsame ĉe la aŭskultanta ingo. Decidu, kiun vojon vi rigardas, antaŭ ol interpreti la protokolan linion. La decido dependas de la celo, kiun la kliento uzis, de la escepto, kiun ĝi tenas por la ekstera VPN-finpunkto, kaj ĉu io tradukas la paketon survoje.

Decidu laŭ celo, ne laŭ tio, kiu estas la uzanto

Komencu per la adreso, al kiu la peto estis sendita, ĉar tiu adreso elektas la vojon. Peto al la tunela adreso de la gastiganto alvenas sur la tunela interfaco kun la interna adreso de la kliento kiel fonto. Peto al la publika adreso de la gastiganto kutime alvenas sur la interret-aliverta interfaco kun la publika adreso de la kliento, eĉ kiam la sama tekkomputilo havas tunelon starigitan en tiu momento. Membreco en la VPN-baseno do estas eco de la paketa vojo, ne eco, kiu sekvas la uzanton.

Ĝuste tiun trian vicon indas kontroli unue, kiam VPN-uzanto aperas en la protokolo kun adreso, kiu tute ne rilatas al la tunelo. Ĝi ankaŭ klarigas, kiel du uzantoj kun la sama profilo povas produkti malsamajn rikordojn: iliaj propraj aliraj retoj malsamas, kaj nenio en la tunelo superskribas tion.

Kial la ekstera finpunkto kreas duan publikan vojon

La kliento devas atingi la publikan adreson de la pordego por starigi la tunelon, do itinero al tiu adreso devas ekzisti ekster la tunelo. Kiam kliento alidirektas la tutan trafikon enen, prudenta efektivigo tenas eksplicitan gastigantan itineron por la publika adreso de la servilo por eviti tunelon, kiu dependas de si mem. Tiu escepto ne estas selekta pri servoj, do ĉiu peto al la sama publika adreso sekvas ĝin, inkluzive de retumila peto al retejo gastigata sur la pordego.

Tio estas la mekanismo malantaŭ la plej multaj konfuzaj raportoj en ĉi tiu kampo, kaj ĝi apartenas al la klienta efektivigo prefere ol al la servilo. Du klientoj kun identaj profiloj tial povas konduti malsame. Forigi la escepton por »ripari« la protokolon faligas ankaŭ la tunelon, do tenu ĝin kaj desegnu ĉirkaŭ ĝi.

Legu la ingon, la tabelon kaj la protokolan formaton kune

Tri observoj decidas, kiun vojon vi rigardas: kie la ingo aŭskultas, kiu interfaco respondas la celon, kaj kion la protokola formato efektive registras. Se la aŭskultanto estas ligita nur al la tunela adreso, publika peto tute ne povas atingi ĝin, kio tuj ekskludas du vicojn. Se la serĉo por la kliento redonas la tunelan aparaton, la peto alvenis kun interna fonto kaj la protokolo devus montri ĝin.

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

Poste legu la formaton prefere ol la linion. Kampo nutrita per plusendita kaplinio registras aserton, ne ingan kunulon, kaj la aserto gravas nur kiam la tuja kunulo estas fidinda prokurilo. Skribi ambaŭ valorojn en la protokolon finas postajn disputojn, ĉar la tuja kunulo kaj la anstataŭigita adreso estas malsamaj faktoj kaj nur unu el ili venis el la reto.

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

Elektu la enirejon, kiun vi volas, kaj igi DNS konsenti

Se la retejo devas esti nur tunela, donu al ĝi nomon, kiu por VPN-klientoj solviĝas al la tunela adreso, kaj plenumu politikon ĉe la aŭskultanta ingo. Split-DNS-respondo redonanta 10.24.0.1 por la interna nomo estas itinera decido en la kostumo de nom-solva detalo. Se la retejo devas esti ankaŭ publika, tenu du nomojn aŭ du pordojn kaj lasu la protokolon diri, kiu servis la peton.

Permesaj reguloj sekvas la saman logikon. Permesi la tunelan basenon ne rajtigas publikan peton, kaj ĝi ne plenigos internan adreson ĉe konekto, kiu alvenis tra la interreto. Miksi ambaŭ enirejojn sub unu nomo igas la registritan fonton kromefiko de klienta itinero anstataŭ desegna elekto.

Kontrolu la vojon, poste la politikon

Konfirmu la vojon per kapto ĉe la pordego kaj peto, kiun vi regas. Kapto ĉe la tunela aparato kaj unu ĉe la publika interfaco montras, kiu portis la bajtojn, kaj la ordo de la paketoj diras al vi, ĉu traduko okazis inter ili.

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

Poste kontrolu aliron en ambaŭ direktoj: la celata nomita enirejo funkcias por la celata kliento, kaj neaprobita publika vojo estas rifuzata anstataŭ nur malrapida. Ĝenerala IP-eĥa retejo pruvas ion pri la interreta eliro de la pordego kaj nenion pri ĉi tiu retejo sur la sama gastiganto. Kiam paĝo kaj WebSocket malkonsentas, komparu iliajn URL-ojn, adresajn familiojn kaj DNS-respondojn antaŭ ol tuŝi la servilan agordon.