Unu publika gastiganto por VPN kaj retejo: kiel dividi la rolojn

Unu maŝino povas plenumi ĉiujn tri bezonojn samtempe: fini tunelojn, respondi per HTTPS kaj plusendi inter du privataj LAN-oj. Ĉu tio estas prudenta dependas de tri aferoj, kiujn vi povas decidi sur papero: kiu posedas la publikan adreson, kiu posedas ĉiun paron de pordo kaj protokolo, kaj al kiu procezo estas permesite plusendi pakaĵojn. Se vi faros tion ĝuste, la dividita gastiganto estas nenio rimarkinda. Se vi faros tion malĝuste, vi pasigos semajnfinon ĉe servo, kiu startas pure kaj neniam respondas.

Tio, kio sekvas, estas decida proceduro, ne konstruplano. Ĉiu paŝo finiĝas per la kontrolo, kiu pruvas, ke la rolo, kiun vi ĵus aldonis, estas vere izolita.

Elektu la posedanton de la adreso antaŭ la pordoj

Tunela finpunkto kaj retservilo povas dividi unu kernon; dividi unu adreson, pordon kaj protokolon samtempe estas tio, kio fiaskas. WireGuard kutime prenas UDP 51820, OpenVPN prenas UDP 1194 aŭ TCP 443, kaj retservilo prenas TCP 443. La paro, kiu doloras, estas OpenVPN super TCP 443 apud HTTPS, ĉar ambaŭ volas la saman ingon kaj la kerno donas ĝin al tiu, kiu ligis unue. Nur demultipleksilo antaŭe, kiel sslh aŭ TLS-konscia prokura servilo, lasas ilin dividi tiun pordon, kaj ĝi aldonas komponenton, kies paneo aspektas precize kiel fajromura problemo.

Rigardu la posedantojn antaŭ ol ŝanĝi ion ajn: ss -lntup presas la lokan adreson, pordon kaj procezon por ĉiu aŭskultanta ingo. Du vicoj kun 0.0.0.0:443 signifas, ke la dua servo neniam ligis, kiom ajn gaja estis ĝia init-skripto. Ponto ankaŭ movas la posedanton. Kiam eth0 aliĝas al br0, la IP moviĝas al br0 kaj ĉiu fajromura regulo, kiu nomas eth0 ĉesas kongrui, do ligu servojn al la ponto kaj konfirmu per ip -br addr.

La sama posedregulo klarigas surprizon, kiu aperas ĉe virtualaj maŝinoj. Tunela servilo, kiu funkcias ene de gasto en la sama LAN, konservas la adreson de la gasto, do konektoj celantaj la propran adreson de la gastiganto restas ĉe la gastiganto kaj la tunelo de la gasto neniam vidas ilin, kion ajn sugestas la klienta profilo.

Enkursigu inter la du LAN-oj aŭ NAT-u unu flankon

Du LAN-oj, kiuj ne vidas unu la alian, povas ĉiu alvoki la publikan gastiganton, kiu poste plusendas inter la tuneloj. Tiu enkursigita dezajno bezonas tri aferojn: ŝaltitan plusendadon, itineron al ĉiu fora prefikso, kaj plusendan politikon, kiu lasas la trairon pasi. sysctl -w net.ipv4.ip_forward=1 kovras la unuan, ip route add 10.20.0.0/24 dev wg1 la duan, kaj nftables-linio kiel nft add rule inet filter forward iifname "wg0" oifname "wg1" accept la trian.

Fonta NAT estas pli facile aldoni kaj pli malfacile sencimigi. Maskado reverkas la klientan adreson, do la fora flanko vidas la hubon anstataŭ la veran gastiganton, kaj ĝiaj alirreguloj kaj protokoloj ĉesas esti utilaj por atribuo. Kiam ambaŭ retoj estas viaj, enkursigu. Kiam unu flanko apartenas al tria partio, kiu ne aldonos revenan itineron, NAT estas la opcio, kiun oni liveras ĉi-semajne. Ĉiukaze skribu la adresplanon, ĉar du interkovrantaj /24 ne povas esti enkursigataj per iu ajn kvanto da agordo.

Nenio en tio, ke vi agas kiel interreta eliro por tekkomputilo, malhelpas la saman skatolon fini envenantajn tunelojn. Nur interkovrantaj adresoj faras tion, kaj tial la adresplano estas la dokumento, kiu gravas.

Testu la dividon dum du roloj estas haltigitaj

La utila testado estas subtraho: haltigu du rolojn kaj konfirmu, ke la tria ankoraŭ respondas. Reta peto devus finiĝi kun la tunela servo malsupre, kaj tunela manpremo devus finiĝi kun la retservilo haltigita. Se ambaŭ funkcias nur kiam ĉio funkcias, vi havas hazardan dependecon: komunan fajromuran tabelon, vagantan itineron aŭ nomon montrantan al la malĝusta adreso.

Tri komandoj faras tiun testadon konkreta. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ pruvas, ke la loka aŭskultanto respondas sen ekstera DNS, wg show ĉe la kliento pruvas, ke la manpremo finiĝis, kaj tcpdump -ni any port 51820 ĉe la hubo apartigas enkursigan problemon de ŝlosila problemo. Manpremo, kiu neniam aperas en la kaptaĵo, mortis antaŭ la gastiganto: fajromuro de la provizanto, malĝusta publika adreso aŭ NAT-regulo survoje.

Ripetu la subtrahon por la plusendataj LAN-oj. Kun unu samtavolano malkonektita, ping tra la hubo devus fiaski; kun ĝi rekonektita, la ping devus restariĝi sen tuŝi regulon. Ping, kiu restariĝas nur post restartigo de la tunelo, montras al politiko anstataŭ al atingeblo, kaj tio estas alia korekto.

Tenu la regulan aron legebla dum vi subtrahas rolojn. nft list ruleset devus montri unu akceptan regulon por direkto, kiun vi vere bezonas, kaj plusenda ĉeno, kiu akceptas ĉion, ne estas apartigo, ĝi estas funkcianta demonstracio.

Alirlinioj nur IPv6 kaj IPv4-servoj

Kelkaj alirlinioj donas atingeblon nur per IPv6, kaj servoj ankoraŭ devas esti publikigataj per IPv4. La tunelo mem vojaĝas per tiu familio, kiu ankoraŭ pasigas trafikon, dum la publikigita servo sidas sur adreso ene de la tunelo. Tio inversigas la kutiman supozon kaj silente rompas monitoradon: fajromura regulo aŭ uptime-kontrolo skribita por la IPv4-vojo nun observas interfacon, kiu portas nenion.

Testu ĉiun familion aparte per curl -4 kaj curl -6, ĉar unu sukcesa peto diras nenion pri la vojo, kiun vi ne provis. Porda posedo ne ŝanĝiĝas inter familioj, sed la aŭskultanto ŝanĝiĝas: ss -lntup listigas IPv4- kaj IPv6-ingojn kiel apartajn vicojn, kaj 0.0.0.0:443 ne kovras [::]:443, krom se la procezo petis dunuban ingon.

Servo, kiu respondas en unu familio kaj rifuzas en la alia, kutime estas aŭskultanta problemo, ne enkursiga. Antaŭ ol nomi la dezajnon finita, konfirmu, ke ĉiu rolo posedas sian propran adreson aŭ pordon, ke plusendado estas ŝaltita kaj permesita, kaj ke ĉiu rolo ankoraŭ respondas dum la aliaj du estas haltigitaj.