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

Å presentere en LAN-enhet på en av gatewayens egne tunneladresser krever bare én linje NAT. Tilkoblingen feiler likevel, fordi enheten som svarer ikke aner at klientens adresse er nåbar gjennom den gatewayen. Følg pakken fra klienten innover, følg deretter svaret tilbake utover, og den manglende halvdelen blir tydelig.

Start med klientens syn

Klienten i dette eksempelet sitter i VPN-poolen 10.62.0.0/24 og kobler til 10.62.0.1 på port 8080. Den adressen tilhører gatewayen selv, så pakken ankommer gatewayens kjerne og ikke en annen peer. Bak gatewayen er LAN-et 172.21.4.0/24. Gatewayen har 172.21.4.10, og enheten som faktisk betjener HTTP er 172.21.4.40.

En adresse som tilhører en annen VPN-peer kan ikke byttes med gatewayens tjenesteadresse. Hvis klienten kobler til en peers adresse, er ingen gateway-regel involvert i det hele tatt, og hele denne gjennomgangen er den feil.

Avgrens destinasjonstranslasjonen med vilje

Den smale versjonen presenterer én port og skriver bare om destinasjonen. Pakken beholder protokollen og kilden sin, og det er det som gjør resten av gjennomgangen 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 uten kriterier for protokoll og port er den brede versjonen: den beholder hvilken port klienten enn valgte, og endrer bare adressen. Det er legitimt når hele verten skal presenteres, og galt når én tjeneste var hensikten. Les regelen tilbake og bekreft grensesnittnavnet. En DNAT-regel på feil grensesnitt treffer ingenting, noe som gir samme tidsavbrudd som en manglende regel og kaster bort en time på å se på enheten.

La videresendingsgrensen være enig

Translasjon endrer headeren, men gir ikke tillatelse. Med en standardregel for forkastning trenger den videresendte flyten sin egen aksept, og returretingen trenger regelen for etablert forbindelse som policyen din sannsynligvis 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 aksept for hver DNAT-flyt er bredere enn dette designet og vil også tillate mappinger som noen legger til senere. Navngi destinasjonen og porten, og la resten forbli stengt. Hvis tellerne på videresendingsregelen blir stående på null mens NAT-tellerne stiger, blir pakken forkastet før regelen din. Les kjedeordenen i stedet for å legge til en annen kopi.

Enheten må svare på en eller annen måte

Etter translasjonen ser enheten en kilde i 10.62.0.0/24. Svaret går til standardgatewayen, som er LAN-ruteren, ikke VPN-gatewayen, med mindre noe forteller den noe annet. To ordninger retter på det, og de er ikke likeverdige. En rute på enheten eller på LAN-ruteren sender 10.62.0.0/24 til 172.21.4.10 og bevarer klientens kilde. En avgrenset kildetranslasjon skjuler i stedet klienten bak 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

Velg etter hva tjenesten trenger. Policy per klient og meningsfulle logger vil ha den rutede formen; en enhet som ikke kan gis en rute, eller en tjeneste som rett og slett må se en LAN-adresse, peker mot den oversatte formen. Ikke grip etter en global masquerade-regel for å få ett svar til å virke. Den skjuler hver klient for hver destinasjon og bryter stille policyene som avhenger av kildeadresser.

Ikke test fra gatewayen selv

En forespørsel generert på gatewayen til 10.62.0.1 går ut gjennom OUTPUT-kjeden, ikke gjennom den innkommende PREROUTING. Feilen eller suksessen sier ingenting om regelen som vender mot klienten, og det er slik folk konkluderer med at en fungerende regel er ødelagt.

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

Kjør en ekte klientforespørsel og les begge. conntrack-oppføringen viser translasjonen som ble brukt, og opptakene viser om forespørselen gikk over til LAN-et og om et svar kom tilbake mot tunnelen. Bruk en ny tilkobling etter at du har endret regler, fordi eksisterende tilstand beholder sin tidligere mapping og vil fortsette å feile på den gamle måten. Bekreft deretter hele samtalen: enhetens adresse, videresendingstillatelsen og svarruten beskriver alle samme flyt.