Publicera en LAN-tjänst på VPN-gatewayens egen adress

Att presentera en LAN-enhet på en av gatewayens egna tunneladresser kräver bara en rad NAT. Anslutningen misslyckas ändå, eftersom enheten som svarar inte har en aning om att klientens adress går att nå via den gatewayen. Följ paketet från klienten inåt och följ sedan svaret tillbaka utåt, så blir den saknade halvan uppenbar.

Börja med klientens perspektiv

Klienten i det här exemplet sitter i VPN-poolen 10.62.0.0/24 och ansluter till 10.62.0.1 på port 8080. Den adressen tillhör gatewayen själv, så paketet kommer till gatewayens kärna och inte till en annan peer. Bakom gatewayen är LAN:et 172.21.4.0/24. Gatewayen har 172.21.4.10 och enheten som faktiskt betjänar HTTP är 172.21.4.40.

En adress som tillhör en annan VPN-peer går inte att byta ut mot gatewayens tjänsteadress. Om klienten ansluter till en peers adress är ingen gateway-regel inblandad alls, och hela den här genomgången är fel fall.

Avgränsa destinationstranslationen med avsikt

Den smala varianten presenterar en port och skriver bara om destinationen. Paketet behåller sitt protokoll och sin källa, och det är det som gör resten av genomgången intressant.

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 utan kriterier för protokoll och port är den breda varianten: den behåller vilken port klienten än valde och ändrar bara adressen. Det är legitimt när hela värden ska presenteras och fel när en enda tjänst var avsikten. Läs tillbaka regeln och bekräfta gränssnittsnamnet. En DNAT-regel på fel gränssnitt matchar ingenting, vilket ger samma tidsgräns som en saknad regel och slösar bort en timme på att titta på enheten.

Låt vidarebefordringsgränsen vara överens

Translation ändrar huvudet men ger inget tillstånd. Med en standardprincip för förkastning behöver det vidarebefordrade flödet sitt eget tillstånd, och returriktningen behöver regeln för etablerad anslutning som din policy förmodligen redan 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

Ett ovillkorligt tillstånd för varje DNAT-flöde är bredare än den här designen och kommer också att tillåta mappningar som någon annan lägger till senare. Namnge destinationen och porten, och låt resten vara stängd. Om räknarna på vidarebefordringsregeln stannar på noll medan NAT-räknarna stiger kastas paketet före din regel. Läs kedjeordningen i stället för att lägga till en andra kopia.

Enheten måste svara på något sätt

Efter translationen ser enheten en källa i 10.62.0.0/24. Svaret går till dess standardgateway, som är LAN-routern och inte VPN-gatewayen, om inte något säger något annat. Två arrangemang löser det och de är inte likvärdiga. En rutt på enheten eller på LAN-routern skickar 10.62.0.0/24 till 172.21.4.10 och bevarar klientens källa. En begränsad källtranslation gömmer istället klienten bakom gatewayens LAN-adress.

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älj efter vad tjänsten behöver. Policy per klient och meningsfulla loggar vill ha den routade formen; en enhet som inte kan ges en rutt, eller en tjänst som helt enkelt måste se en LAN-adress, pekar mot den översatta formen. Ta inte till en global masquerade-regel för att få ett enda svar att fungera. Den gömmer varje klient för varje destination och bryter tyst de policies som beror på källadresser.

Testa inte från gatewayen själv

En förfrågan som skapas på gatewayen till 10.62.0.1 lämnar via OUTPUT-kedjan, inte via den inkommande PREROUTING. Dess misslyckande eller framgång säger ingenting om regeln som vänder sig mot klienten, och det är så folk drar slutsatsen att en fungerande regel är trasig.

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

Kör en riktig klientförfrågan och läs båda. conntrack-posten visar den translation som användes, och fångsterna visar om förfrågan gick över till LAN:et och om ett svar kom tillbaka mot tunneln. Använd en ny anslutning efter att du ändrat regler, eftersom befintligt tillstånd behåller sin tidigare mappning och kommer att fortsätta misslyckas på det gamla sättet. Bekräfta sedan hela samtalet: enhetens adress, vidarebefordringstillståndet och svarets rutt beskriver alla samma flöde.