Bewaar of SNAT die IP's van VPN-kliënte by die wolkrand

Om die adres van die VPN-kliënt regdeur na die toepassing te hou, maak dat elke logreël en elke inskrywing in die toelatingslys dieselfde ding beteken. Om dit by die wolkrand te herskryf, maak die roetetabel eenvoudiger en die logs minder nuttig. Nie een van die twee keuses is op sigself verkeerd nie, en die argument wat dit beslis, gaan selde oor prestasie. Drie voorwaardes beslis dit: of die toepassing moet weet watter mens gekoppel het, of die wolkweefsel die bron sal aanvaar wat jy bedoel om te stuur, en wie bereid is om daarna die terugroete te besit.

Drie voorwaardes beslis dit

Begin by die toepassing se vereiste, nie by die netwerkdiagram nie. As magtiging of oudit van die individuele kliëntadres afhang, dan is die behoud daarvan 'n funksionele vereiste en is vertaling 'n regressie. As die toepassing net moet weet dat verkeer deur die afstandtoegangpad aangekom het, is 'n vertaalde adres voldoende en baie goedkoper om te bedryf.

Die tweede voorwaarde is meganies. 'n Virtuele netwerk vertrou nie outomaties 'n pakket wat 'n adres beweer wat nie aan die sturende koppelvlak toegewys is nie. Die meeste wolkweefsels dwing dit af, op verskillende maniere en onder verskillende name, en 'n ontwerp wat dit ignoreer, sal in 'n diagram korrek lyk en in produksie stilweg laat val.

Die derde is organisatories. Om bronne te bewaar beteken dat die roetetabel van die toepassing-subnet vir die kliëntvoorvoegsel terug na die poort moet wys, en elke span wat later 'n subnet byvoeg, moet daardie roete konsekwent hou. Dit is een keer 'n klein koste, en 'n herhalende een oor dosyne rekeninge. Beslis wie dit betaal voordat jy die gedrag belowe.

'n Roete is nie toestemming om te spoof nie

Om 'n terugroete by te voeg, sê vir jou subnet waar antwoorde moet heen gaan. Dit sê nie vir die weefsel dat die instansie wat daardie pakkette aanstuur, dit met 'n vreemde bron mag uitstuur nie. Op AWS is die relevante beheer bron- en bestemmingkontrole, en dit is per instansie sigbaar:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Skakel dit af vir die instansie wie se gedokumenteerde werk aanstuur is, en vir niks anders nie. Elke toepassing-VM wat die kontrole aangeskakel hou, is een masjien minder wat gebruik kan word om verkeer met 'n geleende bron uit te stuur. As jou platform nie AWS is nie, soek die ekwivalente anti-spoofing- of toegelate-adres-instelling eerder as om aan te neem die gedrag dra oor.

'n Vinnige pakketopname besleg die vraag vinniger as om die konsole te lees. As antwoorde uitgaan en die kliënt sien dit nooit nie, is dit die weefsel wat die vervalste bron weggooi, nie die toepassing wat faal nie.

Wat vertaling koop, en wat dit kos

Om die bron by die poort te herskryf, laat die terugpadprobleem ineenstort. Die toepassing sien een adres wat hy al weet hoe om te bereik, en die kliëntvoorvoegsel hoef nooit in 'n wolkroetetabel te verskyn nie. Op Linux is die reël een lyn, en dit is die moeite werd om die nouste weergawe te skryf wat jy kan:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Let op wat die toepassing nou aanteken: 10.40.3.10 vir elke gebruiker, op elke verbinding, vir altyd. Enige adres-toelatingslys wat op daardie waarde gebou is, verleen nou toegang aan die hele afstandtoegang-bevolking, en enige voorvalondersoek moet na die poort teruggaan om te antwoord wie dit was.

Die oplossing is nie om vertaling te laat vaar nie, dit is om op te hou om voor te gee die adres is 'n identiteit. Dra die kliënt se identiteit in 'n geauthentiseerde veld, teken dit by die poort aan saam met die vertaalde tupel, en laat die toepassing daarop aansluit. Sonder die aansluitingsleutel verander vertaling 'n netwerkprobleem in 'n permanente forensiese een.

Die aflos is 'n ander koppelvlak

'n Omgekeerde instaanbediener voor die toepassing omseil die vraag na die geroteerde pad heeltemal. Die instaanbediener maak sy eie agterkantverbinding oop, so die kliëntvoorvoegsel hoef nooit binne die virtuele netwerk roetebaar te wees nie, en die toepassing kan identiteit in 'n kopstuk ontvang wat die instaanbediener stel.

Daardie kopstuk is net betroubaar wanneer die agterkant dit van die instaanbediener aanvaar en van niks anders nie. In nginx-terme beteken dit om die betroubare eweknie eksplisiet te noem eerder as om te glo wat ook al aankom:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Enige kliënt wat die agterkant direk kan bereik, kan dieselfde kopstuk vervals, so die agterkant moet onbereikbaar wees behalwe deur die instaanbediener. Dit is 'n firewallfeit, nie 'n konfigurasiemening nie, en dit is die aanname wat mense oorslaan wanneer hulle die brokkie kopieer.

Die aflos verander ook wat jy koop. Jy kry 'n identiteit op toepassingsvlak en 'n natuurlike plek om dit aan te teken; jy gee algemeenheid op, want elke nuwe protokol het sy eie instaanbedienerondersteuning nodig. Vir HTTP-dienste is daardie ruil gewoonlik goed, en vir enigiets wat nie HTTP is nie, is dit gewoonlik glad nie beskikbaar nie.

Skryf neer wat elke grens sien

Wat jy ook al kies, die ontwerphersiening moet eindig met een tabel wat die bronadres en die bewysbare identiteit by elke hop noem. Sonder dit lewer die eerste voorval drie spanne op wat elkeen 'n ander kliënt beskryf.

Kies dan. Bewaar wanneer die toepassing se magtiging werklik van die kliëntadres afhang en jy die roete kan besit. Vertaal wanneer dit nie die geval is nie en jy identiteit buite band kan dra, en gebruik die AWS-riglyne vir aanstuurinstansies vir die platformspecifieke aanstuurinstellings. Gryp na 'n aflos wanneer die diens HTTP praat en jy wil hê identiteit moet heeltemal ophou 'n adres wees.