A duhet të aplikoni SNAT në një përcjellje porte drejt një nënrrjeti VPN?

Përcjellja e një porte drejt një hosti që qëndron pas klientit VPN të router-it dështon në një mënyrë që duket si problem muri zjarri, sepse kërkesa mbërrin qartë. Shërbimi regjistron një lidhje, klienti pret dhe asgjë nuk kthehet. Përkthimi i destinacionit bëri punën e tij; paketa e kthimit është pjesa që humbi. Një rregull selektiv i NAT burimor në router e rregullon këtë, dhe pjesa interesante është të vendosni sa i ngushtë mund të jetë ai rregull.

Pse përgjigja merr një rrugë tjetër

Përcjellja e portës rishkruan ku shkon një paketë, kurrë nga erdhi. Adresa e klientit të internetit mbetet në fushën e burimit gjatë gjithë tunelit, kështu që shërbimi i largët sheh një të huaj dhe përgjigjet në të vetmen mënyrë që njeh: përmes portës së vet të paracaktuar. Ajo portë është koncentratori VPN në anën e largët, i cili nuk ka rrugë kthimi drejt një adrese publike arbitrare.

Shikoni një kapje në ndërfaqen e tunelit dhe asimetria është e dukshme: paketat e kërkesës dalin, asgjë nuk hyn. Zinxhiri i përcjelljes lejoi rrjedhën dhe tuneli e transportoi, kështu që hedhja ndodh pasi hosti i largët ka zgjedhur tashmë një rrugë kthimi.

Një rregull burimor mjaft i ngushtë për t'u besuar

Bëjeni router-in burimin të cilit i përgjigjet hosti i largët. Në këtë rregullim adresa WAN është 203.0.113.24, LAN-i është 192.168.88.0/24, adresa e tunelit të router-it është 172.20.5.1, dhe shërbimi përgjigjet në 172.20.5.40:8443. Rregulli më poshtë përputhet me paketën pas përkthimit të destinacionit, prandaj emërton adresën e përkthyer dhe jo atë publike. Asgjë në të nuk varet nga adresa e klientit, dhe pikërisht ky është thelbi.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Çdo përputhje në atë rresht ekziston për ta mbajtur rishkrimin lokal për një shërbim në një tunel. Hiqni ndërfaqen ose portën dhe rishkruani më shumë trafik sesa kërkon problemi, dhe kështu një rregullim i synuar bëhet mister për personin tjetër.

Kur një maskë e përgjithshme është zgjedhja e ndershme

Nëse router-i përcjell shumë shërbime në të njëjtin nënrrjet VPN, rregulli për çdo shërbim bëhet një listë që askush nuk e mirëmban. Maskimi i gjithçkaje që largohet nga ndërfaqja e tunelit është më i thjeshtë dhe i parashikueshëm, me koston e fshehjes së klientit origjinal nga çdo host në anën e largët. Zgjidhni atë kur regjistrat atje nuk përdoren për atribuim; mbani rregullin e ngushtë kur përdoren.

Të dyja opsionet dështojnë edhe ndryshe. Një rregull i ngushtë që mungon prish një shërbim; një maskë e gjerë që përputhet me shumë mund të rishkruajë në heshtje trafikun që tashmë funksiononte, duke përfshirë lidhjet dalëse të vetë router-it.

Kontrolloni numëruesit përpara se të publikoni

Rregullat që nuk përputhen kurrë duken identike me rregullat që funksionojnë derisa të numëroni paketat. Lexoni përsëri tabelën me numërues bajtësh përpara se të lidhet ndonjë klient, pastaj lidhuni nga një rrjet që nuk është LAN dhe lexojeni përsëri. Dy lexime janë ajo që e kthen një hamendje në fakt. Publikoni përcjelljen vetëm pasi e dyta të lëvizë.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Një numërues zero në rregullin burimor pas një lidhjeje reale do të thotë që përputhja është e gabuar, zakonisht sepse destinacioni ose porta nuk përputhen me paketën pas përkthimit. Nëse numëruesi rritet por klienti ende skadon në kohë, rruga e kthimit është rregulluar dhe diçka tjetër po e hedh përgjigjen, kështu që shikoni më pas politikën e përcjelljes në anën e largët. Qasja në metodën e kapëses nga brenda LAN është problem i veçantë dhe kërkon rregullin e vet, jo një version më të gjerë të këtij.