Vai jums jāpiemēro SNAT portu pāradresācijai uz VPN apakštīklu?

Porta pāradresācija uz resursdatoru, kas atrodas aiz paša maršrutētāja VPN klienta, neizdodas tā, ka tas izskatās pēc ugunsmūra problēmas, jo pieprasījums acīmredzami pienāk. Pakalpojums reģistrē savienojumu, klients gaida, un nekas neatgriežas. Galamērķa tulkošana izdarīja savu darbu; atgriešanās pakete ir tā daļa, kas pazuda. Viens selektīvs avota NAT noteikums maršrutētājā to izlabo, un interesantā daļa ir izlemt, cik šaurs šis noteikums var būt.

Kāpēc atbilde izvēlas citu ceļu

Porta pāradresācija pārraksta, kur pakete iet, nekad — no kurienes tā nāca. Interneta klienta adrese paliek avota laukā visā ceļā caur tuneli, tāpēc attālais pakalpojums redz svešinieku un atbild vienīgajā veidā, ko zina: caur savu noklusējuma vārteju. Šī vārteja ir VPN koncentrators otrā pusē, kuram nav maršruta atpakaļ uz patvaļīgu publisku adresi.

Vērojiet ierakstu tuneļa saskarnē, un asimetrija ir acīmredzama: pieprasījuma paketes iziet, iekšā nekas nenāk. Pāradresācijas ķēde atļāva plūsmu, un tunelis to nesa, tāpēc nomešana notiek pēc tam, kad attālais resursdators jau ir izvēlējies atgriešanās ceļu.

Avota noteikums, kas ir pietiekami šaurs, lai tam uzticētos

Padariet maršrutētāju par avotu, uz kuru atbild attālais resursdators. Šajā izkārtojumā WAN adrese ir 203.0.113.24, LAN ir 192.168.88.0/24, maršrutētāja tuneļa adrese ir 172.20.5.1, un pakalpojums atbild uz 172.20.5.40:8443. Tālāk dotais noteikums atbilst paketei pēc galamērķa tulkošanas, tāpēc tas nosauc tulkoto adresi, nevis publisko. Nekas tajā nav atkarīgs no klienta adreses, un tieši tas ir būtiskākais.

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

Katra atbilstība šajā rindā pastāv, lai pārrakstīšana paliktu lokāla vienam pakalpojumam vienā tunelī. Noņemiet saskarni vai portu, un jūs pārrakstāt vairāk trafika, nekā problēma prasa, un tā mērķēts labojums kļūst par mīklu nākamajam cilvēkam.

Kad visaptveroša maskarāde ir godīgā izvēle

Ja maršrutētājs pāradresē daudzus pakalpojumus tajā pašā VPN apakštīklā, noteikums katram pakalpojumam kļūst par sarakstu, ko neviens neuztur. Maskēt visu, kas iziet no tuneļa saskarnes, ir vienkāršāk un paredzamāk, par cenu, ka sākotnējais klients tiek paslēpts no katra resursdatora otrā pusē. Izvēlieties to, ja turienes žurnāli netiek izmantoti attiecināšanai; saglabājiet šauro noteikumu, ja tiek.

Abas iespējas arī neizdodas atšķirīgi. Trūkstošs šaurs noteikums salauž vienu pakalpojumu; plaša maskarāde, kas atbilst pārāk daudz, var klusi pārrakstīt trafiku, kas jau darbojās, tostarp paša maršrutētāja izejošos savienojumus.

Pirms publicēšanas pārbaudiet skaitītājus

Noteikumi, kas nekad neatbilst, izskatās identiski noteikumiem, kas darbojas, līdz saskaitāt paketes. Pārlasiet tabulu ar baitu skaitītājiem pirms jebkura klienta savienojuma, pēc tam savienojieties no tīkla, kas nav LAN, un izlasiet to vēlreiz. Divi nolasījumi ir tas, kas minējumu pārvērš faktā. Publicējiet pāradresāciju tikai pēc tam, kad otrais ir pakustējies.

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

Nulle skaitītājs avota noteikumā pēc reāla savienojuma nozīmē, ka atbilstība ir nepareiza, parasti tāpēc, ka galamērķis vai ports neatbilst paketei pēc tulkošanas. Ja skaitītājs kāpj, bet klients joprojām nonāk taimautā, atgriešanās ceļš ir salabots un kaut kas cits nomet atbildi, tāpēc tālāk apskatiet pāradresācijas politiku otrā pusē. Piekļuve ar matadatu no LAN iekšpuses ir atsevišķa problēma, un tai vajag savu noteikumu, nevis plašāku šī noteikuma versiju.