Publiser ein LAN-teneste på den eigne adressa til VPN-gatewayen

Følg ein vidaresend port frå klienten til eininga og tilbake: avgrens omsetjinga av målet, og avgjer deretter om svar blir ruta eller omsette.

Å presentere ei LAN-eining på ei av dei eigne tunneladressene til gatewayen krev berre éi linje NAT. Tilkoplinga feilar likevel, fordi eininga som svarar ikkje anar at adressa til klienten er nåbar gjennom den gatewayen. Følg pakken frå klienten innover, følg deretter svaret tilbake utover, og den manglande halvdelen blir tydeleg.

Start med synet til klienten

Klienten i dette dømet sit i VPN-poolen 10.62.0.0/24 og koplar til 10.62.0.1 på port 8080. Den adressa høyrer til gatewayen sjølv, så pakken kjem til kjernen i gatewayen og ikkje til ein annan peer. Bak gatewayen er LAN-et 172.21.4.0/24. Gatewayen har 172.21.4.10, og eininga som faktisk tener HTTP er 172.21.4.40.

Ei adresse som høyrer til ein annan VPN-peer kan ikkje bytast med tenesteadressa til gatewayen. Viss klienten koplar til adressa til ein peer, er inga gateway-regel involvert i det heile, og heile denne gjennomgangen er den feil.

Avgrens omsetjinga av målet med vilje

Den smale versjonen presenterer éin port og skriv berre om målet. Pakken held på protokollen og kjelda si, og det er det som gjer 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

Ein regel utan kriterium for protokoll og port er den breie versjonen: han held på kva port klienten enn valde, og endrar berre adressa. Det er legitimt når heile verten skal presenterast, og gale når éin teneste var meininga. Les regelen tilbake og stadfest grensesnittnamnet. Ein DNAT-regel på feil grensesnitt treff ingenting, noko som gjev same tidsavbrot som ein manglande regel og kastar bort ein time på å sjå på eininga.

Lat vidaresendingsgrensa vere samd

Omsetjing endrar headeren, men gjev ikkje løyve. Med ein standardregel for forkasting treng den vidaresende flyten si eiga aksept, og returretninga treng regelen for etablert samband som policyen din truleg allereie 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

Ein vilkårslaus aksept for kvar DNAT-flyt er breiare enn dette designet og vil også tillate mappingar som nokon legg til seinare. Namngje målet og porten, og lat resten vere stengd. Viss teljarane på vidaresendingsregelen blir ståande på null medan NAT-teljarane stig, blir pakken forkasta før regelen din. Les kjederækkjefølgja i staden for å leggje til ein annan kopi.

Eininga må svare på ein eller annan måte

Etter omsetjinga ser eininga ei kjelde i 10.62.0.0/24. Svaret går til standardgatewayen, som er LAN-rutaren, ikkje VPN-gatewayen, med mindre noko fortel henne noko anna. To ordningar rettar på det, og dei er ikkje likeverdige. Ei rute på eininga eller på LAN-rutaren sender 10.62.0.0/24 til 172.21.4.10 og bevarer kjelda til klienten. Ei avgrensa kjeldeomsetjing skjuler i staden klienten bak LAN-adressa til gatewayen.

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

Vel etter kva tenesta treng. Policy per klient og meiningsfulle loggar vil ha den ruta forma; ei eining som ikkje kan få ei rute, eller ei teneste som rett og slett må sjå ei LAN-adresse, peikar mot den omsette forma. Ikkje grip etter ein global masquerade-regel for å få eitt svar til å verke. Han skjuler kvar klient for kvart mål og bryt stille policyane som er avhengige av kjeldadresser.

Ikkje test frå gatewayen sjølv

Ein førespurnad generert på gatewayen til 10.62.0.1 går ut gjennom OUTPUT-kjeda, ikkje gjennom den innkomande PREROUTING. Feilen eller suksessen seier ingenting om regelen som vender mot klienten, og det er slik folk konkluderer med at ein fungerande regel er øydelagd.

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

Køyr ein ekte klientførespurnad og les båe. conntrack-oppføringa viser omsetjinga som vart brukt, og opptaka viser om førespurnaden gjekk over til LAN-et og om eit svar kom tilbake mot tunnelen. Bruk ei ny tilkopling etter at du har endra reglar, fordi eksisterande tilstand held på den tidlegare mappinga si og vil halde fram med å feile på den gamle måten. Stadfest deretter heile samtalen: adressa til eininga, vidaresendingløyvet og svarruta skildrar alle same flyt.

Relaterte artiklar