Ett nätverkskort eller två? Att avgöra en VPN-servers gränssnittslayout

Ett fysiskt nätverkskort räcker för många VPN-servrar, och det är inte heller en universell lösning. Den krypterade anslutningen kommer in på det kortet, VPN-processen dekrypterar den och därefter lämnar den inre trafiken via ett virtuellt gränssnitt innan den når en lokal tjänst eller ett routat LAN. Om det fungerar beror på tre villkor: var målet ligger, om LANet har en returväg till klientpoolen och om en enda delad fysisk länk ger den isolering du hävdar. Svara på de tre och antalet kort följer.

De tre villkoren som avgör

Det första villkoret är målet. En tjänst på själva VPN-värden nås bara via tunnelgränssnittet, medan en värd på LANet kräver vidarebefordran och en returväg. Det andra villkoret är den returvägen, eftersom LAN-enheten måste veta hur den når klientpoolen, antingen via en rutt eller via översättning på servern.

Det tredje villkoret är separering. Ett kort betyder att varje paket, krypterat eller inte, delar en länk och vanligtvis en policykedja, så ett isoleringspåstående som bygger på separat hårdvara uppfylls inte av ett enda gränssnitt. Det är ett faktum om vägen, inte om hur operativsystemet är konfigurerat. Du kan fortfarande filtrera tunneltrafiken, men du kan inte hävda en gräns du inte har.

Inget av de tre handlar om antalet portar på chassit. De handlar om routing, ägarskap av adresser och hur mycket designen beror på fysisk separering.

Två kort är fortfarande ett legitimt val när fysiska zoner, separata upplänkar, genomströmning eller en återställningsväg utanför bandet motiverar det. Det är konkreta krav, och de är värda att formulera innan någon beställer hårdvara.

När tjänsten körs på VPN-värden

Det enklaste fallet behöver ingen vidarebefordran alls. Daemonen tar emot klientens paket på tunnelgränssnittet och lämnar dem till en lokal socket, och svaret kommer tillbaka samma väg. För värden är adressen i klientpoolen en riktig lokal adress.

Två saker måste ändå stämma: tjänsten måste lyssna på en adress som tunneln kan nå, och värdens brandvägg måste acceptera trafik som kommer in på tunnelgränssnittet. Båda syns i kommandona nedan.

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

Att binda en tjänst enbart till den publika adressen, eller att av misstag filtrera tunnelgränssnittet, ger en anslutning som når värden och sedan dör. Det ser ut som ett VPN-fel och är oftast ett beslut om socket eller brandvägg.

När målet ligger på LANet

Här får en design med ett kort sitt rykte om att vara krånglig. Servern måste vidarebefordra klientens paket mot LANet, och LAN-enheten måste skicka svaren tillbaka till klientpoolen. Antingen bär du poolen som en rutt på LANet, eller så översätter du källadressen på servern så att svaren kommer tillbaka till servern själv.

Båda svaren är legitima och de misslyckas på olika sätt. En returrutt håller klientens ursprungliga adress synlig för målet, vilket är bra för loggar och dåligt för brandväggsregler som förutsätter LAN-adresser. Översättning håller LANet enkelt och döljer klientens identitet för målet.

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

En asymmetrisk väg är det klassiska symptomet: klientens begäran kommer in, svaret går ut via en annan router och anslutningen tar slut på tid utan fel i någon ände. Fånga trafik på båda sidor innan du drar någon slutsats om tunneln.

Varför ett alias inte skapar en andra zon

Att lägga en andra adress på samma kort, eller skapa ett dummy-gränssnitt som imiterar en andra port, ändrar mycket lite. Paketen går fortfarande ut via samma fysiska länk, samma switchport och vanligtvis samma brandväggskedja, så ingen ny gräns uppstår mellan dem. Det är konfigurationsbekvämlighet, inte segmentering. Att behandla det som en zongräns är hur ett isoleringspåstående bara överlever på papper.

En separat zon kräver en verklig separering i vägen, och det kravet uppfyller ett andra kort. Om en regel bygger på att trafik mot VPN aldrig delar broadcastdomän med trafik mot LAN, kan en enda kabel inte ge den egenskapen, oavsett hur värden adresseras.

Där en produkt dokumenterar en topologi med flera gränssnitt för ett visst läge, följ produktens dokumentation i stället för att hitta på en kringgående lösning. Leverantörer ändrar också de topologier som stöds mellan versioner, vilket är ännu ett skäl att läsa den aktuella guiden och inte en skärmbild från en gammal guide.

Kontrollera layouten mot den trafik du tillåter

Lista de trafikklasser som servern ska bära: klient till värd, klient till LAN, värd till LAN och den krypterade yttre anslutningen. Varje klass har en källa, ett mål och ett gränssnitt, och layouten måste uppfylla alla fyra samtidigt. En design som hanterar tre av dem är oftast den som genererar ärenden.

Bekräfta sedan de faktiska gränssnitten och den faktiska fångsten, inte diagrammet i designdokumentet. Kommandona nedan skriver ut båda vyerna.

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

Om fångsten utifrån visar den krypterade trafiken och fångsten inifrån visar den dekrypterade trafiken på tunnelgränssnittet medan det fysiska kortet bär båda, gör ett enda kort jobbet. Om fångsten inifrån är tom ligger problemet i tunneln eller i vidarebefordringsreglerna, inte i antalet kort. Avgör topologin utifrån de två fångsterna och routingtabellen, så har nästa ändring något att mätas mot.