Konservi aŭ SNAT la IP-adresojn de VPN-klientoj ĉe la nuba limo

Konservi la adreson de la VPN-kliento ĝis la aplikaĵo igas ĉiun protokollinion kaj ĉiun enskribon en la permeslisto signifi la saman aferon. Reskribi ĝin ĉe la nuba rando igas la enkursigan tabelon pli simpla kaj la protokolojn malpli utilaj. Neniu el la du elektoj estas malĝusta per si mem, kaj la argumento, kiu decidas ĝin, malofte temas pri rendimento. Tri kondiĉoj decidas: ĉu la aplikaĵo devas scii, kiu homo konektiĝis, ĉu la nuba strukturo akceptos la fonton, kiun vi intencas sendi, kaj kiu poste pretas respondeci pri la revena vojo.

Tri kondiĉoj decidas

Komencu per la postulo de la aplikaĵo, ne per la reta diagramo. Se rajtigo aŭ revizio dependas de la individua klienta adreso, tiam konservi ĝin estas funkcia postulo kaj tradukado estas regreso. Se la aplikaĵo nur bezonas scii, ke trafiko alvenis tra la fora alira vojo, tradukita adreso sufiĉas kaj estas multe pli malmultekosta por funkciigi.

La dua kondiĉo estas mekanika. Virtuala reto ne aŭtomate fidas pakaĵon, kiu pretendas adreson, kiun oni ne atribuis al la senda interfaco. Plej multaj nubaj strukturoj devigas tion, laŭ diversaj manieroj kaj sub diversaj nomoj, kaj dizajno, kiu ignoras ĝin, aspektos ĝuste en diagramo kaj silente falos en produktado.

La tria estas organiza. Konservi fontojn signifas, ke la enkursiga tabelo de la aplikaĵa subreto devas montri reen al la pordego por la klienta prefikso, kaj ĉiu teamo, kiu poste aldonas subreton, devas teni tiun vojon konsekvenca. Tio estas unufoja malgranda kosto kaj ripetiĝanta kosto trans dekoj da kontoj. Decidu, kiu pagas ĝin, antaŭ ol vi promesos la konduton.

Vojo ne estas permeso trompi

Aldoni revenan vojon diras al via subreto, kien la respondoj devas iri. Ĝi ne diras al la strukturo, ke la instanco, kiu plusendas tiujn pakaĵojn, rajtas elsendi ilin kun fremda fonto. En AWS la koncerna kontrolo estas la kontrolo de fonto kaj celo, kaj ĝi videblas por ĉiu instanco:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Malŝaltu ĝin nur por la instanco, kies dokumentita tasko estas plusendado, kaj por nenio alia. Ĉiu aplikaĵa VM, kiu lasas la kontrolon ŝaltita, estas unu maŝino malpli, kiun oni povas uzi por elsendi trafikon kun pruntita fonto. Se via platformo ne estas AWS, serĉu la ekvivalentan agordon por kontraŭtrompado aŭ permesitaj adresoj anstataŭ supozi, ke la konduto transdonos.

Rapida kapto de pakaĵoj solvas la demandon pli rapide ol legi la konzolon. Se respondoj eliras kaj la kliento neniam vidas ilin, la strukturo forĵetas la falsitan fonton, kaj ne la aplikaĵo fiaskas.

Kion aĉetas tradukado kaj kion ĝi kostas

Reskribi la fonton ĉe la pordego forigas la problemon de la revena vojo. La aplikaĵo vidas unu adreson, kiun ĝi jam scias kiel atingi, kaj la klienta prefikso neniam devas aperi en nuba enkursiga tabelo. En Linux la regulo estas unu linio, kaj indas skribi la plej mallarĝan version, kiun vi povas:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Rimarku, kion la aplikaĵo nun registras: 10.40.3.10 por ĉiu uzanto, ĉe ĉiu konekto, por ĉiam. Ĉiu adresa permeslisto konstruita sur tiu valoro nun donas aliron al la tuta fora-alira loĝantaro, kaj ĉiu incidenta revizio devas reveni al la pordego por respondi, kiu estis tiu.

La solvo ne estas rezigni pri tradukado, ĝi estas ĉesi ŝajnigi, ke la adreso estas identeco. Portu la klientan identecon en aŭtentikigita kampo, registru ĝin ĉe la pordego kune kun la tradukita opo, kaj lasu la aplikaĵon kunigi laŭ ĝi. Sen la kuniga ŝlosilo tradukado konvertas retan problemon en daŭran kriminalistikan problemon.

La relajso estas alia interfaco

Inversa prokurilo antaŭ la aplikaĵo tute evitigas la demandon pri la enkursigita vojo. La prokurilo malfermas sian propran backend-konekton, do la klienta prefikso neniam bezonas esti enkursigebla ene de la virtuala reto, kaj la aplikaĵo povas ricevi identecon en kaplinio, kiun la prokurilo starigas.

Tiu kaplinio estas fidinda nur tiam, kiam la backend akceptas ĝin de la prokurilo kaj de nenio alia. En nginx-terminoj tio signifas eksplicite nomi la fidindan partneron anstataŭ kredi ĉion, kio alvenas:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Ĉiu kliento, kiu povas atingi la backend rekte, povas falsi la saman kaplinian, do la backend devas esti neatingebla krom per la prokurilo. Tio estas fakto pri fajroŝirmilo, ne opinio pri agordo, kaj ĝuste tiun supozon homoj preterlasas, kiam ili kopias la fragmenton.

La relajso ankaŭ ŝanĝas, kion vi aĉetas. Vi ricevas identecon je aplikaĵ-nivelo kaj naturan lokon por registri ĝin; vi fordonas ĝeneralecon, ĉar ĉiu nova protokolo bezonas sian propran prokurilan subtenon. Por HTTP-servoj tiu interŝanĝo kutime bonas, kaj por io ajn, kio ne estas HTTP, ĝi kutime tute ne disponeblas.

Skribu, kion vidas ĉiu limo

Kion ajn vi elektas, la dizajna revizio devus finiĝi per unu tabelo, kiu nomas la fontan adreson kaj la pruveblan identecon ĉe ĉiu salto. Sen ĝi la unua incidento produktas tri teamojn, kiuj ĉiu priskribas alian klienton.

Tiam elektu. Konservu, kiam la rajtigo de la aplikaĵo vere dependas de la klienta adreso kaj vi povas respondeci pri la vojo. Traduku, kiam tio ne estas la kazo kaj vi povas porti identecon ekster kanalo, kaj uzu la gvidadon de AWS pri plusendaj instancoj por la platformspecifaj plusendaj agordoj. Rifuĝu al relajso, kiam la servo parolas HTTP kaj vi volas, ke identeco ĉesu esti adreso.