Ĉioportaj plusendoj povas engluti vian WireGuard-auskultanton
Larĝa plusenda regulo povas engluti la proprajn WireGuard- kaj SSH-auskultantojn de la enirejo. Elektu mallarĝajn regulojn aŭ apartan publikan adreson, poste testu la regadan vojon.
Publika enirejo jam funkciigas WireGuard sur UDP 51820, SSH sur 22, kaj unu aplikaĵon, kiu devas esti atingebla el la interreto. La tentiga regulo plusendas ĉiun pordon al la peer kaj konsideras la aferon finita. Sur WireGuard-enirejo tiu regulo povas kapti la propran transporton de la tunelo kaj ŝlosi vin el la maŝino, kiu finigas ĝin. Publikigo estas enkursiga decido kun escepto por la regada ebeno, ne unu linio de DNAT.
Publika eniro, tunela eniro: elektu unu
Publikigi servon kreas novan interretan enirpunkton. Ĝi ne samas kiel doni VPN-membrecon al peer, ĉar la vizitanto neniam aliĝas al la tunelo kaj la enirejo fariĝas la publika vizaĝo de la backend. Tiu distingo decidas la publikon de la regulo kaj ĝian atestilon.
Administraj interfacoj malofte apartenas al tiu pozicio. Administra paĝo atingata de rajtigitaj VPN-klientoj tenas sian ataksurfacon ene de la tunelo kaj evitas elmeti ensalutan formularon al arbitra skanado. Publikaj aplikaĵaj finpunktoj ankoraŭ bezonas propran TLS-atestilon, aŭtentikigon kaj rapidlimigon; la ĉifrita WireGuard-salto ne protektas la kruron de la vizitanto ĝis la enirejo.
Se la servo vere devas esti publika, notu la gastigan nomon, la atestilon, kiu kovras ĝin, kaj la vizitantajn intervalojn, kiuj devas atingi ĝin. Tiuj tri faktoj poste decidas la formon de la regulo kaj la filtran politikon. Io ajn ekster ili estas ampleksa disvastiĝo sur publika auskultanto.
Unu pordo enen, unu backend eksteren
Uzu unu publikan pordon kaj unu backend-servon. En ĉi tiu ekzemplo eth0 portas la publikan adreson 198.51.100.20, la tunela adreso de la enirejo estas 10.200.0.1, kaj la peer funkciigas la aplikaĵon sur 10.200.0.7. Publika TCP 9443 mapiĝas al TCP 8443 de la peer:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1La regulo SNAT kongruas kun la tradukita backend kaj la origina publika celo, do alia konekto al la sama backend-servo restas ekster ĉi tiu mapado. Ĝi ankaŭ kaŝas la adreson de la vizitanto de la peer, kaj tio estas la kompromiso, kiu faras fontokonservan enkursigitan revenon aparta dezajno. La referenco pri iptables-etendaĵoj dokumentas ambaŭ celojn kaj iliajn kongruajn opciojn.
Plusendo ankoraŭ devas esti ebligita, kaj la filtra ĉeno bezonas permeson por la tradukita celo kaj pordo plus establitaj respondoj. La ĉeno FORWARD vidas la tradukitan celon post DNAT, do regulo skribita kontraŭ la publika adreso ne kongruas kun la plusendita pako. Skribu la permeson kontraŭ la backend-oparo, ne la publika.
La peer devas akcepti la servan konekton el la tunela adreso de la enirejo kaj sendi la respondon reen tra la tunelo. Ĝia AllowedIPs devas rajtigi la fonton, kiun ĝi efektive ricevas, kio sub fonta traduko estas la tunela adreso de la enirejo, kaj larĝa rikordo 0.0.0.0/0 sur ĉiu peer ne necesas por ĉi tiu dezajno. Kion faligas la revenan trafikon estas peer, kies listo preterlasas tiun adreson, aŭ fontokonserva dezajno, kiu plusendas la propran adreson de la vizitanto, do kontrolu la fonton, kiun la peer vere vidas, ne tiun en via regulo.
Tenu la proprajn auskultantojn de la enirejo ekster la regulo
Anstataŭigu la pordan kongruon per regulo kovranta ĉiun TCP- kaj UDP-celon, kaj la propra WireGuard-ingo de la enirejo falas en ĝin. Cela traduko okazas antaŭ ol la maŝino decidas, ke pako estas loka, do UDP 51820 povas finiĝi ĉe la peer anstataŭ ĉe la procezo, kiu tenas ĉiun peer-konekton. La regulo ŝarĝiĝas sukcese kaj la tunelo mortas, kio estas malfacile legebla fuŝo de la peer-flanko.
SSH, observaj agentoj kaj ajna alia servo gastigata sur la enirejo havas la saman elmeton. Regulo, kiu plusendas ĉion, ne distingas la regadan ebenon de la publikigita aplikaĵo, kaj la unua restartigo post la ŝanĝo estas kiam la ŝloso fariĝas evidenta. La regulo por ĉio ne avertas pri la servo, kiun ĝi silente prenas. Vi malkovras ĝin, kiam la sekva konekto malsukcesas.
Se larĝa plusendo vere necesas, rezervu la regadajn pordojn antaŭ la regulo por ĉio aŭ uzu apartan publikan adreson por publikigo. La dua opcio estas pli pura, ĉar la regada adreso tenas sian propran politikon, sed la provizanto devas liveri tiun adreson; aldoni DNS-rikordon ne asignas unu.
Larĝa TCP- kaj UDP-plusendo ankaŭ ne estas ĉiuj protokoloj. ICMP, IPv6, vojo-MTU-retrokuplo kaj la ekstera VPN-transporto bezonas sian propran politikon, kaj regulo kovranta TCP kaj UDP lasas tiujn kazojn al la defaŭlta ĉeno.
Elektu la modelon antaŭ ol skribi regulojn
Kvar formoj kovras la plej multajn enirejajn publikigojn, kaj la elekto dependas de kiom da servoj vi funkciigas kaj kiom da risko pri la regada ebeno vi toleras. La suba tabelo ordigas ilin de la plej mallarĝa al la plej larĝa.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Komencu per la mallarĝa modelo eĉ se vi atendas pli da servoj poste. Ĝi estas la plej facile revidebla, kaj transformi aron de mallarĝaj reguloj en reviziitan regulon por ĉio estas pli simpla ol malkovri, kiun auskultanton kaptis larĝa regulo. Kiun ajn modelon vi elektos, tenu la regulojn ĉe la posedanto de la fajroŝirmilo. Apliki iptables-liniojn apud UFW- aŭ nftables-agordo, kiu ankaŭ administras la samajn ĉenojn, produktas politikon, kiu ŝanĝiĝas laŭ la boota ordo.
Pruvu kaj la publikigon kaj la regadan vojon
Testu de rajtigita ekstera kliento per la aprobita gastiga nomo kaj atestilo valida por ĝi. Konfirmu, kiu backend respondis, poste kontrolu, ke nerilataj publikaj pordoj restas malpermesitaj. Malŝaltita atestila kontrolo ne estas sukcesa HTTPS-testo, kaj konekto, kiu atingas la malĝustan backend, estas pli malbona ol malsukcesa.
Post tio, kontrolu la enirejon mem: konektu WireGuard-peer, malfermu SSH-sesion kaj konfirmu, ke observado ankoraŭ raportas. La publikigita servo povas funkcii dum la regada ebeno estas rompita, do ambaŭ kontroloj apartenas al la sama ŝanĝa fenestro. Restartigu unufoje por pruvi, ke la reguloj reapplikiĝas en la atendata ordo, poste forigu la publikigon kaj konfirmu, ke la forigo vere kongruas kun la aldono. Granda aro da startaj aldonoj kun nekompleta forigo estas kiel provizora testo fariĝas permanenta malfermo.