Udgiv en LAN-tjeneste på VPN-gatewayens egen adresse

Følg en videresendt port fra klienten til enheden og tilbage: afgræns destinationstranslationen, og beslut derefter, om svar bliver rutet eller oversat.

At præsentere en LAN-enhed på en af gatewayens egne tunneladresser kræver kun én linje NAT. Forbindelsen fejler stadig, fordi den enhed, der svarer, ikke aner, at klientens adresse kan nås gennem den gateway. Følg pakken fra klienten indad, følg derefter svaret tilbage udad, og den manglende halvdel bliver tydelig.

Begynd med klientens syn

Klienten i dette eksempel sidder i VPN-puljen 10.62.0.0/24 og forbinder til 10.62.0.1 på port 8080. Den adresse tilhører gatewayen selv, så pakken ankommer til gatewayens kerne og ikke til en anden peer. Bag gatewayen er LAN'et 172.21.4.0/24. Gatewayen har 172.21.4.10, og den enhed, der faktisk betjener HTTP, er 172.21.4.40.

En adresse, der tilhører en anden VPN-peer, kan ikke udskiftes med gatewayens tjenesteadresse. Hvis klienten forbinder til en peers adresse, er ingen gateway-regel involveret overhovedet, og hele denne gennemgang er den forkerte.

Afgræns destinationstranslationen med vilje

Den snævre version præsenterer én port og omskriver kun destinationen. Pakken beholder sit protokol og sin kilde, og det er det, der gør resten af gennemgangen interessant.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

En regel uden kriterier for protokol og port er den brede version: den bevarer, hvilken port klienten nu valgte, og ændrer kun adressen. Det er legitimt, når hele værten skal præsenteres, og forkert, når én tjeneste var hensigten. Læs reglen tilbage, og bekræft grænsefladens navn. En DNAT-regel på den forkerte grænseflade matcher intet, hvilket giver samme timeout som en manglende regel og spilder en time på at kigge på enheden.

Lad videresendelsesgrænsen være enig

Translation ændrer headeren, men giver ikke tilladelse. Med en standardpolitik for kassering har det videresendte flow brug for sin egen accept, og returretningen har brug for reglen for etableret forbindelse, som din politik sandsynligvis allerede har.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

En ubetinget accept for hvert DNAT-flow er bredere end dette design og vil også tillade mappinger, som nogen tilføjer senere. Navngiv destinationen og porten, og lad resten fejle lukket. Hvis tællerne på videresendelsesreglen bliver på nul, mens NAT-tællerne stiger, kasseres pakken før din regel. Læs kæderækkefølgen i stedet for at tilføje en anden kopi.

Enheden skal svare på en eller anden måde

Efter translation ser enheden en kilde i 10.62.0.0/24. Dens svar går til dens standardgateway, som er LAN-routeren, ikke VPN-gatewayen, medmindre noget fortæller den andet. To arrangementer løser det, og de er ikke ens. En rute på enheden eller på LAN-routeren sender 10.62.0.0/24 til 172.21.4.10 og bevarer klientens kilde. En afgrænset kildetranslation skjuler i stedet klienten bag gatewayens LAN-adresse.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Vælg efter, hvad tjenesten har brug for. Politik per klient og meningsfulde logfiler vil have den rutede form; en enhed, der ikke kan få en rute, eller en tjeneste, der simpelthen skal se en LAN-adresse, peger på den oversatte form. Grib ikke efter en global masquerade-regel for at få ét svar til at virke. Den skjuler hver klient for hver destination og ødelægger stille de politikker, der afhænger af kildeadresser.

Test ikke fra gatewayen selv

En anmodning genereret på gatewayen til 10.62.0.1 forlader gennem OUTPUT-kæden, ikke gennem den indgående PREROUTING. Dens fejl eller succes siger intet om reglen rettet mod klienten, og det er sådan, folk konkluderer, at en fungerende regel er i stykker.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Kør en rigtig klientanmodning, og læs begge. conntrack-posten viser den anvendte translation, og optagelserne viser, om anmodningen gik over til LAN'et, og om et svar kom tilbage mod tunnelen. Brug en ny forbindelse efter ændrede regler, fordi eksisterende tilstand beholder sin tidligere mapping og bliver ved med at fejle på den gamle måde. Bekræft derefter hele samtalen: enhedens adresse, videresendelsestilladelsen og svarruten beskriver alle samme flow.

Relaterede artikler