Eén NIC of twee? De interfacelayout van een VPN-server bepalen

Eén fysieke adapter is genoeg voor veel VPN-servers, en het is ook geen universeel ontwerp. De versleutelde verbinding komt binnen op die adapter, het VPN-proces ontsleutelt hem, en daarna verlaat het interne verkeer het systeem via een virtuele interface voordat het een lokale dienst of een gerouteerd LAN bereikt. Of dat werkt hangt af van drie voorwaarden: waar de bestemming zich bevindt, of het LAN een terugweg naar de clientpool heeft, en of één gedeelde fysieke link de isolatie oplevert die je claimt. Beantwoord die drie en het aantal adapters volgt.

De drie voorwaarden die het bepalen

De eerste voorwaarde is de bestemming. Een dienst op de VPN-host zelf is alleen bereikbaar via de tunnelinterface, terwijl een host op het LAN doorsturing en een terugweg vereist. De tweede voorwaarde is die terugweg, omdat het LAN-apparaat moet weten hoe het de clientpool bereikt, via een route of via vertaling op de server.

De derde voorwaarde is scheiding. Eén adapter betekent dat elk pakket, versleuteld of niet, één link en meestal één beleidsketen deelt, dus een isolatieclaim die op aparte hardware berust, wordt door één interface niet ingelost. Dat is een feit over het pad, niet over hoe het besturingssysteem is geconfigureerd. Je kunt het tunnelverkeer nog steeds filteren, maar je kunt geen grens claimen die je niet hebt.

Geen van de drie gaat over het aantal poorten op de behuizing. Ze gaan over routering, eigenaarschap van adressen en hoeveel het ontwerp van fysieke scheiding afhangt.

Twee adapters blijven een legitieme keuze wanneer fysieke zones, aparte uplinks, doorvoer of een herstelpad buiten de band dat rechtvaardigen. Dat zijn concrete eisen, en het loont ze te benoemen voordat iemand hardware bestelt.

Wanneer de dienst op de VPN-host draait

Het eenvoudigste geval heeft helemaal geen doorsturing nodig. De daemon ontvangt de pakketten van de client op de tunnelinterface en geeft ze aan een lokale socket, en het antwoord komt via dezelfde interface terug. Voor de host is het adres uit de clientpool een echt lokaal adres.

Toch moeten twee dingen kloppen: de dienst moet luisteren op een adres dat de tunnel kan bereiken, en de firewall van de host moet verkeer accepteren dat op de tunnelinterface aankomt. Beide zijn zichtbaar in de opdrachten hieronder.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Een dienst alleen aan het openbare adres binden, of per ongeluk de tunnelinterface filteren, levert een verbinding op die de host bereikt en daarna sterft. Dat lijkt op een VPN-storing en is meestal een socket- of firewallbeslissing.

Wanneer de bestemming op het LAN staat

Hier verdient een ontwerp met één adapter zijn reputatie van weerbarstig. De server moet de pakketten van de client richting het LAN doorsturen, en het LAN-apparaat moet antwoorden terugsturen naar de clientpool. Of je draagt die pool als route op het LAN, of je vertaalt het bronadres op de server zodat antwoorden bij de server zelf terugkomen.

Beide antwoorden zijn legitiem en ze falen op verschillende manieren. Een terugroute houdt het oorspronkelijke clientadres zichtbaar voor de bestemming, wat goed is voor logboeken en slecht voor firewallregels die LAN-adressen veronderstellen. Vertaling houdt het LAN eenvoudig en verbergt de identiteit van de client voor de bestemming.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Een asymmetrisch pad is het klassieke symptoom: het verzoek van de client komt aan, het antwoord vertrekt via een andere router, en de verbinding loopt aan beide uiteinden zonder fout af op een time-out. Leg aan beide zijden vast voordat je iets over de tunnel concludeert.

Waarom een alias geen tweede zone maakt

Een tweede adres op dezelfde adapter zetten, of een dummy-interface maken die een tweede poort nabootst, verandert heel weinig. De pakketten verlaten nog steeds dezelfde fysieke link, dezelfde switchpoort en meestal dezelfde firewallketen, dus er ontstaat geen nieuwe grens tussen beide. Het is configuratiegemak, geen segmentatie. Het als zonegrens behandelen is de manier waarop een isolatieclaim alleen op papier overleeft.

Een aparte zone vereist een echte scheiding in het pad, en dat is de eis waaraan een tweede adapter voldoet. Als een regel ervan afhangt dat verkeer richting VPN nooit een broadcastdomein deelt met verkeer richting LAN, kan één kabel die eigenschap niet leveren, hoe de host ook geadresseerd is.

Waar een product een topologie met meerdere interfaces documenteert voor een specifieke modus, volg dan de documentatie van dat product in plaats van een omweg te bedenken. Leveranciers wijzigen ook de ondersteunde topologieën tussen releases, wat een andere reden is om de huidige gids te lezen en niet een schermafbeelding van een oude wizard.

Controleer de layout tegen het verkeer dat je toestaat

Som de verkeersklassen op die de server moet dragen: client naar host, client naar LAN, host naar LAN en de versleutelde buitenverbinding. Elke klasse heeft een bron, een bestemming en een interface, en de layout moet alle vier tegelijk vervullen. Een ontwerp dat er drie aankan, is meestal het ontwerp dat tickets oplevert.

Bevestig daarna de werkelijke interfaces en de werkelijke capture, niet het diagram in het ontwerpdocument. De opdrachten hieronder printen beide weergaven.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Als de capture aan de buitenkant het versleutelde verkeer toont en de capture aan de binnenkant het ontsleutelde verkeer op de tunnelinterface, terwijl de fysieke adapter beide draagt, doet één NIC het werk. Als de capture aan de binnenkant leeg is, zit het probleem in de tunnel of in de doorstuurregels, niet in het aantal adapters. Bepaal de topologie op basis van die twee captures en de routetabel, en de volgende wijziging heeft iets om tegen af te meten.