DNAT in 'n VPN-houer: deurvoer, nie INPUT nie

Die versoek kom aan met die tonnel-IP as adres en verlaat dieselfde houer met 'n naburige diens as adres. Tussen daardie twee oomblikke het DNAT die bestemming herskryf, en die pakket het opgehou om inset vir die VPN-houer te wees. Dit is nou deurvoer-verkeer, wat deur 'n ander reel beoordeel word. Daardie verskuiwing verduidelik waarom 'n vuurmuurreel wat vir die tonnel-adres reg lyk, geen effek het op die vertaalde verbinding nie.

Volg die pakket na die vertaling

Neem 'n klientpoel van 10.90.0.0/24 en 'n tonnel-adres van 10.90.0.1. Twee houers sit op een brug: 192.0.2.2 bedryf die VPN en 192.0.2.3 bedryf die toepassing. 'n Klient verbind na 10.90.0.1:8080, en die DNAT-reel in die VPN-houer se naamruimte herskryf dit na die toepassing se werklike adres en poort. 'n Roete stuur dan die pakket oor die brug. Daardie adresse is illustratief, nie 'n ontplooiingsresep nie.

Die poort waarop die toepassing werklik luister, kan verskil van enige poort wat op die gasheer gepubliseer is. Lees die luisteraar binne die houer eerder as om aan te neem dat albei nommers ooreenstem.

Toestemming hoort op die deurvoerpad

Die VPN-houer benodig IP-deurvoer en 'n deurvoerbesluit wat tot die klientpoel, die toepassing se adres en die beoogde poort beperk is. Gevestigde antwoorde benodig hul eie toelating. 'n Reel wat die oorspronklike tonnel-adres pas, sal na DNAT nie pas nie, want die bestemming het reeds verander. 'n INPUT-toelating is die verkeerde haak vir verkeer wat nie meer aan hierdie gasheer geadresseer is nie.

Hou die omvang smal: een bronreeks, een bestemming, een diens. 'n Toegeeflike deurvoerreel is makliker om te skryf en baie moeiliker om later te verdedig.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker se kettings is nie jou houer se kettings nie

Reels binne die houer se naamruimte is nie die Docker-gasheer se reels nie. Wanneer verkeer van die tonnel-koppelvlak na die brug oorgaan, kan die gasheer se brug-vuurmuur 'n ander besluit neem. Met Docker se iptables-agterkant is die gedokumenteerde deurvoerketting en die nadere-DNAT-pasplek waar daardie besluit verskyn.

Die Docker-vuurmuurverwysing beskryf daardie kettings en die passing na DNAT. Moenie 'n ontbrekende toelating regmaak deur Docker se vuurmuurbestuur af te skakel of elke ketting toegeeflik te maak nie, want dit verwyder die grens wat jy probeer gebruik.

Maak die terugpad 'n doelbewuste keuse

As die bronadres bewaar word, sien die toepassing 10.90.0.x en moet dit antwoorde terug deur die VPN-houer stuur. Sy gewone Docker-gateway sal hulle anders na die gasheer stuur, wat nie die tonnel besit nie. Die alternatief is 'n smal bronvertaling by die VPN-houer, wat die antwoord vereenvoudig maar die klient vir die toepassing verberg. Kies doelbewus en skryf neer watter een jy gekies het.

Toets 'n vars toegelate verbinding van 'n gewone klient, en bevestig dan dat onverwante poorte gesluit bly. Wanneer 'n pakket verdwyn, ondersoek die VPN-naamruimte, die toepassing se naamruimte en die toepassing se eie log. 'n Ping na die brug-gateway is nie 'n aanvaardingstoets vir die diens nie.

Hou die reels in die houer se ondersteunde opstartkonfigurasie, want interaktiewe wysigings verdwyn wanneer dit herskep word. 'n Gasheer-poortpublikasie is 'n ander blootstellingspad en is nie nodig net omdat die diens deur die tonnel bereikbaar is nie.