Routad VPN eller bryggat LAN för en förbindelse mellan filial och labb

Det finns två sätt att låta en filial nå ett hemmalabb, och skillnaden är inte en inställning. Du kan routa mellan olika prefix, så att varje plats behåller sin egen broadcastdomän, eller brygga de två LAN:en till ett, så att broadcasts och discoverytrafik beter sig som om alla satt i samma rum. Routing är den design som klarar kontakten med ett riktigt nätverk. Bryggning är den design som gör första veckan enkel och första avbrottet intressant. Jämförelsen nedan handlar om vad var och en ger dig och vad den kostar, följt av hur du gör den routade varianten testbar.

Två sätt att ansluta, en uppenbar avvägning

En routad länk behandlar hemmalabbet som ett fjärrnätverk med egen adressering. Filialen frågar efter labbprefixet, tunneln bär dessa paket, och labbgatewayen svarar från sitt eget subnät. Inget i filialens ARP-tabell ändras, och inget av labbets DHCP-område når filialen.

En bryggad länk sträcker ut en enda Layer 2-domän över båda platserna. Discoveryprotokoll fungerar, enheter dyker upp automatiskt, och varje broadcast, varje ARP-förfrågan och varje multicastpaket är nu en kandidat att korsa tunneln, vilket är en stor mängd trafik som bärs av protokoll designade för ett lokalt segment och inte för ett WAN med annan MTU och varierande svarstid.

Vad routing ger dig

Den första fördelen är skadans omfattning. En loop, en rogue DHCP-server eller en broadcastflod stannar på den plats som skapade den, eftersom en router inte vidarebefordrar broadcasts. Den andra är adresseringsklarhet: filialprefixet och labbprefixet är olika, så ett pakets destination talar om vilken plats som ska svara, och en brandväggsregel kan säga ”filial till labbsubnät” i stället för ”överallt till överallt”.

Den tredje är att det matchar vad tunneln faktiskt transporterar. En IPsec-policy är ett par prefix, och vidarebefordringsvägen på varje sida är vanlig IP-routing med forwarding aktiverat på gatewayen:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Det du ger upp är discovery via broadcast. Det är en verklig förlust, och den bör ersättas medvetet i stället för att kringgås genom att brygga allt.

Vad bryggning kostar

Bryggning måste bära Layer 2-ramar över en tunnel, vilket innebär en inkapsling som GRE eller VXLAN över IPsec i stället för en vanlig policybaserad tunnel. När det finns delar de två platserna en feldomän. Spanning tree ser tunneln som en länk, broadcasttrafik tar tunnelbandbredd, och varje enhet som förutsätter ett segment med låg latens beter sig fel på sätt som är svåra att härleda från någon av ändarna.

Det tar också bort adresseringskontrollen som håller dig ärlig. Med ett enda platt prefix är en dubbel adress inte ett routingfel utan två värdar som tyst stjäl trafik från varandra, och överlappande prefix mellan en filial och ett labb är vanliga i hemmalabbsuppsättningar, så bryggning löser inte den konflikten; den sprider den.

Säkerhetsargumentet är det som brukar avgöra saken. En brygga sträcker ut det segment där link-local-protokoll arbetar, så en enhet i filialen kan prata med labbenheter som aldrig var menade att vara nåbara utifrån. Har labbet en hypervisor, en lagringskonsol och ett hanteringsgränssnitt på samma platta nät, är det nu ett segment tillsammans med filialen.

Namn utan broadcast

Anledningen till att folk bryggar är oftast discovery: en skrivare, en medieenhet eller en labbvärd som aldrig dyker upp i en lista. Det routade svaret är en namntjänst. Publicera labbvärdarna i en zon som filialens resolver kan nå, och låt sedan användarna ansluta via namn i stället för att skanna nätet. Det är mer arbete i början och betydligt mindre arbete vid varje framtida ändring.

Multicastdiscovery är det svårare fallet, och det förtjänar precision. Protokoll som mDNS använder link-local multicast, som routrar inte vidarebefordrar som standard, så en labbvärd som saknas i en discoverylista kan fortfarande nås på sin dokumenterade adress. Om en specifik tjänst verkligen kräver multicast, planera den enda tjänsten, med en reflector eller en riktad vidarebefordringsregel, i stället för att brygga hela LAN:et som en allmän reparation.

En reflector är inte heller någon gratis vinst. Den importerar samma pratsamma trafik som du försökte undvika, en tjänst i taget, och den behöver en ägare som märker när en enhet börjar annonsera mer än den brukade. Välj den per tjänst, och skriv ned varför. Anteckna vilken tjänst som behövde den och vad den annonserar, för en firmwareuppdatering kan ändra den listan utan att berätta för någon.

Gör den routade designen testbar

Välj ett mål, till exempel ett webbgränssnitt i labbet på ett eget serversubnät, och bevisa det i båda riktningarna. Bekräfta på en värd i filialen adressen och den lyssnande tjänsten lokalt, anslut sedan genom tunneln och upprepa. En tunnel som är uppe bevisar att gatewayerna är överens; den bevisar inget om värdens brandvägg eller returvägen.

Labbets normala gateway behöver en väg tillbaka till filialprefixet om inte designen medvetet översätter källan, och serverns egen brandvägg måste acceptera det tillåtna fjärrområdet. Ingen av dem konfigureras av en lyckad tunnel. strongSwans vidarebefordringsanteckningar beskriver den paketväg som måste fungera på varje sida.

Testa sedan också en nekad destination. En filialanvändare som behöver en applikation behöver inte hypervisorkonsolen, och det enda sättet att veta att policyn är verklig är att prova just det den bör neka. Anteckna prefixen, resolverberoendet och testresultaten, och en framtida ändring på någon av platserna kan granskas på minuter i stället för att byggas upp från minnet.