Isang port ng OpenVPN, tatlong serbisyo: bakit mahalaga ang mga panloob na port

Isang sesyon ng SSH, isang web app at isang paghahanap ng pangalan ay maaaring magbahagi ng isang koneksyon ng VPN nang hindi naglalaban sa mga port. Ang kliyente ay bumubuo ng isang naka-encrypt na daloy patungo sa gateway, at ang bawat pag-uusap ng aplikasyon ay naglalakbay sa loob nito. Sa labas, tanging ang sariling transportasyon at port ng tunnel ang nakikita. Sa loob, ang bawat serbisyo ay nagpapanatili ng sarili nitong port at kailangan pa rin ng sarili nitong pahintulot.

Ano ang dinadala ng panlabas na daloy, at ano ang itinatago nito

Binabalot ng kliyente ang bawat packet sa transportasyon ng tunnel bago ito umalis sa makina. Ang panlabas na daloy ay may isang port ng destinasyon, itinakda nang i-configure ang VPN. Sa loob ng balot, ang bawat orihinal na packet ay nagpapanatili ng address at port ng serbisyong pinupuntahan nito. Tinatanggal ng gateway ang balot at nagru-route ayon sa panloob na header, kaya nakikita ng destinasyon ang isang ordinaryong kliyenteng dumarating mula sa network.

Kaya ang pagkuha sa interface ng WAN ay nagpapakita ng isang pag-uusap, hindi tatlo. Ang mga panloob na port ay lumilitaw lamang pagkatapos ng decapsulation. Iyon ang dahilan kung bakit ang isang butas sa firewall ay maaaring magdala ng SSH, HTTPS at DNS nang sabay.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Ang dokumentasyon ng TUN/TAP ay sumasaklaw sa paglipat kung saan ang isang naka-route na aparatong TUN ay nagpapasa ng mga packet ng IP sa pagitan ng kernel at ng isang proseso sa espasyo ng gumagamit. Ang paglipat na iyon ang nagpapakita ng panloob na header sa code ng routing at firewall ng gateway. Ipinaliwanag din nito kung bakit walang sinasabi ang panlabas na port tungkol sa kung aling mga serbisyo ang pinapayagan.

Ang forward ng NAT ay pag-aari ng tagapakinig, hindi ng mga aplikasyon

Ang isang self-hosted na gateway sa likod ng NAT ng IPv4 ay nangangailangan ng isang papasok na salin: ang pampublikong address at port ay naka-map sa tagapakinig ng VPN. Walang tuntuning kailangan para sa SSH, HTTPS o DNS dahil lang naaabot sila ng mga gumagamit ng tunnel. Ang paglalathala ng mga port na iyon ay maglalantad ng mga serbisyong pinoprotektahan na ng tunnel. Inilalarawan ng tuntunin ng forward ang maaabot ng tagapakinig, hindi isang pahintulot para sa anumang nasa loob.

Totoo rin ang kabaligtaran. Ang pagbukas ng port ng tunnel ay walang ibang inilalantad, kaya ang serbisyong maaabot lamang sa pamamagitan ng tunnel ay pinapanatiling sarado ang pampublikong ibabaw nito. Ang paghihiwalay na iyon ang karaniwang dahilan upang panatilihing pribado ang serbisyo.

Ang panloob na patakaran ang lugar kung saan talagang napagpasyahan ang pag-access

Pinoprotektahan ng encryption ang landas; hindi ito nagbibigay ng awtoridad sa destinasyon. Pinipili ng mga ruta ng kliyente kung aling mga prefix ang pumapasok sa tunnel, pinagpapasyahan ng patakaran ng forward ng gateway kung makakaalis ang mga packet, at pinagpapasyahan ng firewall at login ng destinasyon kung sasagot ang serbisyo. Ang DNS ang pinakamalinaw na kaso: ang pagdadala ng mga query ay hindi nagpapangyaring tanggapin ng resolver ang mga ito mula sa iyong pool ng kliyente. Ang bawat layer ay maaaring tumanggi nang mag-isa.

Subukan ang bawat serbisyo nang hiwalay sa tunnel. Ang matagumpay na paghahanap ay walang sinasabi tungkol sa port ng web, at ang matagumpay na kahilingan sa web ay walang sinasabi tungkol sa SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Kapag gumagana ang tunnel at lahat ay nabigo, basahin muna ang talahanayan ng ruta ng kliyente. Kapag nabigo ang isang serbisyo habang gumagana ang iba, nasa destinasyong iyon ang sira. Ang dalawang obserbasyong iyon ay tumuturo sa magkaibang may-ari, at ang paghahalo sa kanila ay nag-aaksaya ng oras.

Gumuhit ng parehong linya ang WireGuard

Pinangalanan ng WireGuard ang panlabas na tagapakinig nito na ListenPort, at ang panloob na aplikasyon ay gumagamit pa rin ng port ng serbisyong kailangan nito. AllowedIPs ay isang hanay ng mga naka-route na prefix, hindi isang listahan ng pinapayagang port ng serbisyo. Ang pagbasa nito bilang allowlist ng port ay gumagawa ng mga tuntuning hindi tumutugma sa ginagawa ng tunnel. Iba ang pagpapangalan; hindi iba ang paglalapat.

Payagan ang serbisyo sa patakaran ng lokal na input kapag tumatakbo ito sa host mismo, o sa patakaran ng forward kapag nasa likod ng host na iyon. Ang pagkakaiba ang nagpapasya kung aling set ng tuntunin ang nakakakita ng packet.

Ang pangkalahatang hugis ay isang panlabas na transportasyon na may maraming panloob na pag-uusap. Ang mga produktong nangangailangan ng maraming panlabas na palitan, o ibang protocol ng IP, ay nagpapaalala na inilalarawan ng pattern ng isang pampublikong port ang disenyong ito at hindi ang bawat VPN.