Ĉu migranta VPN-kliento povas gastigi servon por la oficejo?

Via oficeja tekokomputilo povas alvoki hejme kaj tamen liveri ion, kion la oficejo bezonas, sed nur kiam tri apartaj decidoj kongruas. La tunelo estas transporto, la interna adreso estas la celo, kaj politiko decidas, kiu rajtas frapi. Trakti iun ajn el tiuj kiel la tutan respondon produktas la konatan plendon: la gastigo respondas al pingoj sed la aplikaĵo neniam konektiĝas. La roloj ne samas, kaj la diferenco estas ĝuste tie, kie loĝas la projektlaboro.

La alvoka direkto diras nenion pri la serva direkto

Kiam kliento komencas tunelon, ĝi malfermas vojon, kiun ambaŭ direktoj povas uzi post kiam ĝi ekzistas. Ĉu nova konekto rajtas eniri de la centro al tiu kliento, estas demando de kluzpolitiko, ne eco de tiu, kiu alvokis. Ekzemple, ĉe enkursigita OpenVPN centro, la servilo bezonas itineron al la interna adreso de la kliento kaj plusendadon, kiu permesas egalan rilaton.

Imagu stokan sistemon, kiu demandas agenton en migrantaj tekokomputiloj, aŭ programiston, kiu bezonas testan API de laborejo hejme. Ambaŭ volas, ke la oficeja flanko komencu la interparolon, kio estas la malo de la kutima kliento-al-servilo ŝablono.

Gastigitaj malproksimaliraj produktoj varias ĉi tie, kaj la variado ne estas cimo. Kelkaj administrataj VPN-oj intence blokas nepetitajn konektojn al konektitaj klientoj, ĉar ilia modelo estas kliento-al-rimedo, ne rimedo-al-kliento. Legu la dokumentitan arkitekturon de la produkto antaŭ ol promesi al kolego, ke lia tekokomputilo povas agi kiel servilo.

Sekvu la revenan vojon antaŭ ol malfermi pordon

La vojo havas tri partojn: itinero sur la kluzo, kiu montras al la interna adreso de la kliento, politiko, kiu permesas la konkretan alvokanton, kaj aŭskultanta servo sur la celo. Ĉiu parto malsukcesas malsame, tial «la VPN funkcias» diras preskaŭ nenion.

La bona novaĵo estas, ke la interna vojo ne bezonas pordplusendadon sur la hejma enkursigilo de la kliento. Tio estas la senco publikigi la servon ĉe la tunela adreso anstataŭ ĉe la hejma WAN-adreso, kie la elmetiĝo kaj la NAT-reguloj estus tute aliaj. Hejma enkursigilo ankaŭ povas rifuzi hairpin-konekton alvenantan de la oficejo, do la WAN-itinero malsukcesas pro kialoj senrilataj al via VPN. Teni la trafikon ene de la tunelo evitas ambaŭ problemojn samtempe.

Kontrolu ankaŭ la celan flankon. Servo ligita nur al 127.0.0.1 ne povas akcepti konekton alvenantan sur la tunela interfaco, kiom ajn ĝustaj estas la itineroj de la kluzo. Gastiga fajromura regulo, kiu permesas la pordon nur el la loka subreto, ankaŭ forĵetos oficejan trafikon, kaj tiu regulo estas sendependa de la VPN-politiko super ĝi.

Nomoj kaj adresoj estas projektaj decidoj

Adreso ene de la tunelo ne aŭtomate estas nomo. Privata DNS-rikordo, kiun vi kontrolas, estas pli klara ol esperi, ke malkovra protokolo transirus la tunelon, ĉar loka plurdissenda nomrezolucio restas sur la loka segmento kaj ne fariĝas DNS inter subretoj.

Adresa stabileco same gravas. Se VPN-klientoj prenas el baseno kun mallongaj luoj, la interna adreso de la tekokomputilo ŝanĝiĝas inter sesioj kaj ĉiu legosigno, fajromura amplekso kaj monitora kontrolo konstruita sur ĝi rompiĝas silente. Uzu rezervon aŭ dokumentitan dinamikan ĝisdatigan vojon.

Interkonsentu la nomon kun tiu, kiu posedas la VPN-identecon, por ke la rikordo, la adresa atribuo kaj la alira politiko ŝanĝiĝu kune anstataŭ en tri apartaj biletoj.

Testu la servon, ne la membrecon

De la celo, konfirmu, kio aŭskultas kaj sur kiu adreso, poste konfirmu la vidon de la kluzo pri la revena vojo:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Nun testu de la oficeja flanko per vera peto anstataŭ eĥo. Sukcesa curl kontraŭ la servo pruvas la itineron, la politikon kaj la aŭskultanton samtempe, dum sukcesa ping pruvas nur, ke ICMP estas permesita. Se la peto malsukcesas, iru malantaŭen tra la tri partoj anstataŭ larĝigi la fajromuron kaj esperi.

Disponebleco apartenas al la sama interparolo. Tekokomputilo dormas, migras inter retoj kaj malkonektiĝas fine de la tago. Servo, kiu devas respondi en ajna horo, apartenas al ĉiam ŝaltita gastigo, dum servo laŭplejebla povas resti ĉe la kliento kun tiu limigo skribita.

Publikigu la rimedon intence, kun nomo, listo de permesitaj alvokantoj kaj posedanto, kaj la malproksima aparato fariĝas subtenata servo anstataŭ hazarda servilo.