Nagho-host ang gateway ng sarili nitong admin page: panloob o pampublikong address

Sinasagot ng admin page mula sa telepono sa mobile data at nag-time out mula sa laptop na sumali sa VPN. Walang sira sa tunnel, dahil hindi kailanman pumapasok dito ang kahilingan. Naresolba ang hostname sa pampublikong address ng gateway, at ang address na iyon ay maaabot lamang mula sa labas ng tunnel na tinatapos nito. Ang pag-aayos nito ay nangangahulugang bigyan ang serbisyo ng pribadong pasukan, hindi ilipat ang panlabas na dulo.

Naglo-load ang pahina mula sa labas at hindi sa tunnel

Dalawang magkaibang kahilingan ang inihahambing. Mula sa mobile data, direktang naaabot ng browser ang pampublikong address. Mula sa loob ng tunnel, naresolba ang parehong pangalan sa parehong pampublikong address, at ang packet ay kailangan nang lumabas sa tunnel upang maabot ang isang address sa sariling malayong bahagi ng tunnel. Parehong pangalan, parehong address, dalawang lubos na magkaibang posisyon.

Pinipili ng ruta ng destinasyon ang isang address, hindi ang port. Walang alam sa routing table na ang port 443 ay para sa administrasyon at ang port 1194 ay ang transport, kaya pareho silang itinuturing na parehong destinasyon.

Kaya minsan gumagana ang pahina at minsan hindi, depende sa pangalan at network na ginamit ng kliyente. Problema ito sa landas at hindi problema sa pagpapatunay. Mahusay na nagpapatunay ang dalawang kliyente.

Panatilihing maaabot ang panlabas na dulo

Ang mga full-tunnel profile ay nangangailangan ng ruta ng eksepsiyon para sa dulo ng VPN, at ang opsyong redirect-gateway ng OpenVPN ay dokumentado nang eksakto iyon: ang malayong dulo ay nagpapanatili ng ruta sa pamamagitan ng dating umiiral na gateway upang ang tunnel ay hindi mag-ruta sa sarili nito. Alisin ang eksepsiyong iyon at ang naka-encrypt na transport ay susunod sa tunnel, na nagtatapos sa session sa isang loop. Ang eksepsiyong iyon ang dahilan kung bakit nananatiling maaabot ang address ng dulo mula sa loob ng tunnel.

Ang kinahinatnan ay nananatiling maaabot ang pampublikong address mula sa kliyente, at iyon din ang dahilan kung bakit ang kahilingan ng browser sa address na iyon ay maaaring sumunod sa parehong eksepsiyon at lumabas nang hindi pumapasok sa tunnel. Ginagawa ng eksepsiyon ang trabaho nito, at ang pangalan ang gumagawa ng pinsala.

Basahin ang desisyon ng ruta at hindi ang listahan ng interface bago baguhin ang anuman. Ang mga utos sa ibaba ay nagpi-print ng desisyon at hindi ng imbentaryo. Patakbuhin ang mga ito mula sa kliyenteng nabigo.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Kung ipinapakita ng paghahanap ang ruta ng dulo sa pamamagitan ng pisikal na gateway, tama ang pag-uugali at ang admin page ay ipinapadala lamang sa maling landas. Doon nagiging pag-aayos ang resolusyon ng pangalan.

Bigyan ang serbisyo ng pribadong pangalan

Kailangan ng serbisyo ng pangalan na naresolba sa address ng gateway sa loob ng tunnel, habang pinapanatili ang semantika ng sertipiko at hostname na inaasahan ng aplikasyon. Ang pribadong record ng zone para sa pangalan ng administrasyon ang karaniwang sagot, at iniiwan nitong hindi nagalaw ang pangalan ng transport.

Huwag muling ituro ang pangalan ng transport sa panloob na address, dahil susubukan ng susunod na pagtatatag ng tunnel na maabot ang isang address na umiiral lamang sa loob ng tunnel. Ang pagkakamaling iyon ay gumagawa ng VPN na gumagana nang eksaktong isang beses.

Suriin din ang parehong pamilya ng address, dahil ang naiwang AAAA record ay maaaring magpadala sa browser sa lugar na hindi kailanman sakop ng pribadong plano.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Itugma ang patakaran sa lugar kung saan tumatakbo ang proseso

Ang katutubong prosesong nakikinig sa gateway ay naaabot sa pamamagitan ng landas ng lokal na input, kaya ang input chain at ang socket binding ang nagpapasya kung tatanggapin ang kahilingan. Ang mga tuntunin ng forwarding at IP forwarding ay hindi nagpapasagot sa lokal na tagapakinig. Payagan ang mga pinagmulan ng tunnel sa patakaran ng input at kumpirmahin na ang proseso ay nakatali sa address na maaabot ng tunnel.

Ang container na inilathala sa port ng host ay sumusunod sa ibang landas, dahil ang packet ay isinasalin sa destinasyon at ipinapasa. Ang kahilingang iyon ay nakakatagpo ng patakaran ng forwarding ng host at ng sariling mga tuntunin ng Docker, kaya ang gumaganang katutubong tagapakinig ay maaaring mabuhay kasama ng container na tumatanggi sa parehong port.

Mahalaga ang pagkakasunod-sunod ng pagsisimula sa parehong kaso, dahil ang pagtali sa address na lumilitaw lamang pagkatapos umangat ang tunnel ay tahimik na nabigo sa boot.

Suriin ang pribadong pag-access at ang tinanggihang pampublikong landas

Gumawa ng bagong pinangalanang kahilingan mula sa awtorisadong kliyente na buo ang sariling mga pagsusuri ng pagkakakilanlan ng aplikasyon. Pagkatapos ay subukan ang parehong serbisyo mula sa labas ng tunnel at kumpirmahin na hindi ito sumasagot. Ang pribadong pangalan ay kaginhawahan at hindi paghihigpit, at ang tagapakinig na nakatali pa rin sa pampublikong address ay nakalantad pa rin. Ang huling pagsusuring iyon ang nilalaktawan ng karamihan ng pagsusuri.

Basahin ang mga pagtali at ang estado ng filter at hindi ang hostname na natanggap ng mga gumagamit. Ang pagkalantad ay katangian ng socket at hindi ng pangalan. Ang pagkakaibang iyon ay nakakaligtas sa bawat pagbabago ng DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Kapag ibinalik ng panloob na kahilingan ang pahina at nag-time out ang panlabas na kahilingan, may isang sinadyang pribadong landas ang serbisyo at nananatiling maaabot ang transport. Kapag sumasagot pa rin ang panlabas na kahilingan, kailangang paliitin ang tagapakinig o ang inilathalang entry ng container bago ilarawan ng sinuman ang serbisyo bilang panloob lamang.