Aling source address ang itatala ng NGINX para sa isang VPN client?

Tatlong client address ang lumilitaw sa isang setup ng NGINX at OpenVPN sa parehong host, isa para sa bawat rutang maaaring tahakin ng isang kahilingan. Iba ang hitsura sa nakikinig na socket ng browser na umaabot sa tunnel address, ng browser na umaabot sa pampublikong address, at ng programang lumalabas sa daan ng internet ng gateway. Magpasya kung aling ruta ang tinitingnan mo bago unawain ang linya ng log. Nakasalalay ang pasya sa destinasyong ginamit ng client, sa eksepsiyong hawak nito para sa panlabas na endpoint ng VPN, at sa kung may nagko-convert ng packet sa daan.

Magpasya ayon sa destinasyon, hindi ayon sa kung sino ang user

Magsimula sa address kung saan ipinadala ang kahilingan, dahil ang address na iyon ang pumipili ng ruta. Dumarating sa tunnel interface ang kahilingan sa tunnel address ng host na may panloob na address ng client bilang source. Karaniwang dumarating sa interface na nakaharap sa internet ang kahilingan sa pampublikong address ng host na may pampublikong address ng client, kahit may nakatayong tunnel ang parehong laptop sa sandaling iyon. Ang pagiging kasapi sa pool ng VPN ay katangian ng ruta ng packet, hindi katangiang sumusunod sa user.

Ang ikatlong hanay na iyon ang unang dapat suriin kapag lumitaw sa log ang isang VPN user na may address na walang kinalaman sa tunnel. Ipinapaliwanag din nito kung bakit ang dalawang user sa parehong profile ay makakagawa ng magkaibang entry: magkaiba ang kanilang sariling access network, at walang sumusulat muli nito sa loob ng tunnel.

Bakit gumagawa ng ikalawang pampublikong ruta ang panlabas na endpoint

Kailangang maabot ng client ang pampublikong address ng gateway para maitayo ang tunnel, kaya kailangang may ruta patungo sa address na iyon sa labas ng tunnel. Kapag inililipat ng client ang lahat ng trapiko papasok, nagpapanatili ang matinong implementasyon ng tahasang host route patungo sa pampublikong address ng server para maiwasan ang tunnel na umaasa sa sarili nito. Hindi nagtatangi ang eksepsiyong iyon sa mga serbisyo, kaya sinusunod ito ng anumang kahilingan sa parehong pampublikong address, kasama ang kahilingan ng browser sa site na naka-host sa gateway.

Ito ang mekanismong nasa likod ng karamihan ng nakakalitong ulat sa larangang ito, at nakasalalay ito sa implementasyon ng client at hindi ng server. Kaya maaaring magkaiba ang ugali ng dalawang client na may magkatulad na profile. Kapag inalis ang eksepsiyon para »ayusin« ang log, bumabagsak din ang tunnel, kaya panatilihin ito at magdisenyo sa paligid nito.

Basahin nang sabay ang socket, ang talahanayan at ang format ng log

Tatlong obserbasyon ang nagtatakda kung aling ruta ang tinitingnan mo: kung saan nakikinig ang socket, aling interface ang tumutugon sa destinasyon, at ano talaga ang itinatala ng format ng log. Kung nakatali lamang ang listener sa tunnel address, hindi ito maaabot ng pampublikong kahilingan, na agad nag-aalis ng dalawang hanay. Kung ibinabalik ng lookup para sa client ang tunnel device, dumarating ang kahilingan na may panloob na source at dapat itong ipakita ng log.

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

Pagkatapos basahin ang format at hindi ang linya. Ang field na pinapakain ng ipinasang header ay nagtatala ng claim, hindi ng socket peer, at mahalaga lamang ang claim kapag ang agarang peer ay isang pinagkakatiwalaang proxy. Ang pagsulat ng parehong halaga sa log ay nagtatapos ng mga pagtatalo sa hinaharap, dahil magkaibang katotohanan ang agarang peer at ang pinalitang address at isa lamang sa kanila ang galing sa network.

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

Piliin ang entry point na gusto mo at pagkasunduin ang DNS

Kung ang site ay para lamang sa tunnel, bigyan ito ng pangalang nagre-resolve sa tunnel address para sa mga VPN client at ipatupad ang patakaran sa nakikinig na socket. Ang split-DNS na sagot na nagbabalik ng 10.24.0.1 para sa panloob na pangalan ay desisyon sa routing na nakasuot ng detalye ng paglutas ng pangalan. Kung kailangan ding maging pampubliko ang site, panatilihin ang dalawang pangalan o dalawang port at hayaang sabihin ng log kung alin ang nagsilbi sa kahilingan.

Ang mga tuntunin ng allow ay sumusunod sa parehong lohika. Ang pagpayag sa pool ng tunnel ay hindi nagbibigay ng awtoridad sa pampublikong kahilingan, at hindi nito pupunan ang panloob na address sa koneksiyong dumating sa internet. Ang paghahalo ng dalawang entry point sa ilalim ng isang pangalan ay ginagawang side effect ng routing ng client ang naitalang source sa halip na desisyon sa disenyo.

I-verify ang ruta, pagkatapos ang patakaran

Kumpirmahin ang ruta sa pamamagitan ng capture sa gateway at kahilingang kontrolado mo. Ang capture sa tunnel device at isa sa pampublikong interface ay nagpapakita kung alin ang nagdala ng bytes, at ang pagkakasunod-sunod ng packet ay nagsasabi kung may conversion na nangyari sa pagitan nila.

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

Pagkatapos i-verify ang access sa dalawang direksiyon: gumagana ang nakaplanong pinangalanang entry para sa nakaplanong client, at ang hindi aprubadong pampublikong ruta ay tinatanggihan sa halip na mabagal lamang. Ang pangkalahatang IP-echo site ay nagpapatunay ng isang bagay tungkol sa labasan ng gateway sa internet at wala tungkol sa site na ito sa parehong host. Kapag hindi nagkasundo ang isang pahina at isang WebSocket, ihambing ang kanilang URL, pamilya ng address at sagot ng DNS bago hawakan ang konfigurasyon ng server.