Unu OpenVPN-pordo, tri servoj: kial gravas internaj pordoj

Unu SSH-sesio, unu reta aplikaĵo kaj unu nomserĉo povas kunhavigi unu solan VPN-konekton sen batali pri pordoj. La kliento konstruas unu ĉifritan fluon al la pordego, kaj ĉiu aplikaĵa interparolo vojaĝas ene de ĝi. Ekstere videblas nur la propra transporto kaj pordo de la tunelo. Interne ĉiu servo konservas sian propran pordon kaj ankoraŭ bezonas sian propran permeson.

Kion portas la ekstera fluo, kaj kion ĝi kaŝas

La kliento envolvas ĉiun paketon en la transporton de la tunelo antaŭ ol ĝi lasas la maŝinon. Tiu ekstera fluo havas unu celan pordon, fiksitan kiam la VPN estis agordita. Ene de la envolvaĵo, ĉiu originala paketo konservas la adreson kaj pordon de la servo, kiun ĝi celas. La pordego forigas la envolvaĵon kaj vojigas laŭ la interna kaploko, tiel ke la celo vidas ordinarajn klienton alvenantan el la reto.

Kaptaĵo sur la WAN-interfaco do montras unu interparolon, ne tri. La internaj pordoj aperas nur post malkapsuligo. Tial unu sola malfermaĵo de fajroŝirmilo povas porti SSH, HTTPS kaj DNS samtempe.

# 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

La dokumentaro pri TUN/TAP pritraktas la transdonon, per kiu vojigita TUN-aparato pasigas IP-paketojn inter la kerno kaj procezo en uzantspaco. Ĝuste tiu transdono igas la internan kaplokon videbla al la vojiga kaj fajroŝirmila kodo de la pordego. Ĝi ankaŭ klarigas, kial la ekstera pordo diras nenion pri tio, kiuj servoj estas permesitaj.

La NAT-plusendo apartenas al la aŭskultanto, ne al la aplikaĵoj

Memgastigita pordego malantaŭ IPv4-NAT bezonas unu envenantan tradukon: la publika adreso kaj pordo mapitaj al la VPN-aŭskultanto. Neniu regulo necesas por SSH, HTTPS aŭ DNS nur ĉar tuneluzantoj atingas ilin. Publikigi tiujn pordojn malkovrus servojn, kiujn la tunelo jam protektas. La plusenda regulo priskribas atingeblon de la aŭskultanto, ne permeson por io ajn interne.

Ankaŭ la malo validas. Malfermi la tunelan pordon malkovras nenion alian, do servo atingebla nur tra la tunelo restigas sian publikan surfacon fermita. Tiu disigo kutime estas ĝuste la kialo teni la servon privata.

La interna politiko estas kie aliro efektive decidiĝas

Ĉifrado protektas la vojon; ĝi ne rajtigas celon. Klientaj vojigoj elektas, kiuj prefiksoj eniras la tunelon, la plusenda politiko de la pordego decidas ĉu paketoj rajtas lasi ĝin, kaj la fajroŝirmilo de la celo kune kun ensaluto decidas ĉu la servo respondas. DNS estas la plej klara kazo: porti demandojn ne igas resolvilon akcepti ilin el via klienta baseno. Ĉiu tavolo povas memstare diri ne.

Testu ĉiun servon aparte tra la tunelo. Sukcesa serĉo diras nenion pri la reta pordo, kaj sukcesa reta peto diras nenion pri SSH.

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

Kiam la tunelo funkcias kaj ĉio malsukcesas, legu unue la vojigan tabelon de la kliento. Kiam unu servo malsukcesas dum la aliaj funkcias, la difekto estas ĉe tiu celo. Tiuj du observoj montras al malsamaj posedantoj, kaj miksi ilin malŝparas tempon.

WireGuard desegnas la saman linion

WireGuard nomas sian eksteran aŭskultanton per ListenPort, kaj interna aplikaĵo ankoraŭ uzas ajnan servan pordon, kiun ĝi bezonas. AllowedIPs estas aro de vojigitaj prefiksoj, ne listo de permesitaj servaj pordoj. Legi ĝin kiel permesliston de pordoj produktas regulojn, kiuj ne kongruas kun tio, kion la tunelo faras. La nomado diferencas; la tavoligo ne.

Permesu la servon en la loka eniga politiko kiam ĝi funkcias sur la finpunkto mem, aŭ en la plusenda politiko kiam ĝi situas malantaŭ tiu finpunkto. La distingo decidas, kiun regulan aron la paketo vidas.

La ĝenerala formo estas unu ekstera transporto kun multaj internaj interparoloj. Produktoj, kiuj bezonas plurajn eksterajn interŝanĝojn aŭ alian IP-protokolon, memorigas, ke la ŝablono de unu publika pordo priskribas ĉi tiun dezajnon kaj ne ĉiun VPN-on.