Routeret VPN eller broet LAN for en forbindelse mellem filial og lab

Der er to måder at få en filial til at nå et hjemmelab, og forskellen er ikke en indstilling. Du kan route mellem forskellige prefixer, så hvert sted beholder sit eget broadcastdomæne, eller du kan bro de to LAN'er sammen til ét, så broadcasts og discoverytrafik opfører sig, som om alle sad i samme rum. Routing er det design, der overlever kontakten med et rigtigt netværk. Broing er det design, der gør den første uge nem og den første driftsforstyrrelse interessant. Sammenligningen nedenfor handler om, hvad hver af dem giver dig, og hvad den koster, efterfulgt af hvordan du gør den routerede version testbar.

To måder at forbinde på, én oplagt afvejning

En routeret forbindelse behandler hjemmelabbet som et fjernnetværk med sin egen adressering. Filialen spørger efter labprefixet, tunnelen bærer disse pakker, og lab-gatewayen svarer fra sit eget subnet. Intet ved filialens ARP-tabel ændres, og intet af labbets DHCP-område når filialen.

En broet forbindelse udstrækker ét Layer 2-domæne over begge steder. Discoveryprotokoller virker, enheder dukker automatisk op, og hver broadcast, hver ARP-anmodning og hver multicastpakke er nu en kandidat til at krydse tunnelen, hvilket er en stor mængde trafik båret af protokoller, der er designet til et lokalt segment og ikke til et WAN med en anden MTU og en varierende rundturstid.

Hvad routing giver dig

Den første fordel er skadens omfang. Et loop, en rogue DHCP-server eller en broadcastflod bliver på det sted, der skabte den, fordi en router ikke videresender broadcasts. Den anden er adresseringsklarhed: filialprefixet og labprefixet er forskellige, så en pakkes destination fortæller dig, hvilket sted der skal svare, og en firewallregel kan sige »filial til labsubnet« i stedet for »overalt til overalt«.

Den tredje er, at det passer til det, tunnelen faktisk transporterer. En IPsec-politik er et par prefixer, og videresendelsesstien på hver side er almindelig IP-routing med forwarding slået til 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 giver afkald på, er discovery via broadcast. Det er et reelt tab, og det bør erstattes bevidst i stedet for at blive omgået ved at bro alt.

Hvad broing koster

Broing skal bære Layer 2-rammer over en tunnel, hvilket betyder en indkapsling som GRE eller VXLAN over IPsec i stedet for en almindelig politikbaseret tunnel. Når det findes, deler de to steder et fejldomæne. Spanning tree ser tunnelen som et link, broadcasttrafik spiser tunnelbåndbredde, og enhver enhed, der forventer et segment med lav latenstid, opfører sig forkert på måder, der er svære at henføre fra begge ender.

Det fjerner også den adresseringskontrol, der holder dig ærlig. Med ét fladt prefix er en dobbelt adresse ikke en routingfejl, men to hosts, der stille stjæler trafik fra hinanden, og overlappende prefixer mellem en filial og et lab er almindelige i hjemmelabopsætninger, så broing løser ikke den konflikt; den fordeler den.

Sikkerhedsargumentet er det, der normalt afgør sagen. En bro udstrækker det segment, hvor link-local-protokoller virker, så en enhed i filialen kan tale med labenheder, der aldrig var ment at skulle kunne nås udefra. Har labbet en hypervisor, en storage-konsol og en administrationsgrænseflade på samme flade netværk, er det nu ét segment sammen med filialen.

Navne uden broadcast

Grunden til, at folk broer, er som regel discovery: en printer, en medieenhed eller en labhost, der aldrig dukker op i en liste. Det routerede svar er en navnetjeneste. Udgiv labhostene i en zone, som filialens resolver kan nå, og lad derefter brugerne forbinde via navn i stedet for at scanne netværket. Det er mere arbejde på forhånd og betydeligt mindre arbejde ved hver fremtidig ændring.

Multicastdiscovery er det sværere tilfælde, og det fortjener præcision. Protokoller som mDNS bruger link-local multicast, som routere ikke videresender som standard, så en labhost, der mangler i en discoveryliste, kan stadig nås på sin dokumenterede adresse. Hvis en bestemt tjeneste virkelig kræver multicast, så planlæg den ene tjeneste, med en reflector eller en målrettet videresendelsesregel, i stedet for at bro hele LAN'et som en generel reparation.

En reflector er heller ikke en gratis gevinst. Den importerer den samme snaksomme trafik, som du prøvede at undgå, én tjeneste ad gangen, og den kræver en ejer, der bemærker, når en enhed begynder at annoncere mere, end den plejede. Vælg den per tjeneste, og skriv ned hvorfor. Noter hvilken tjeneste der havde brug for den, og hvad den annoncerer, for en firmwareopdatering kan ændre den liste uden at fortælle nogen det.

Gør det routerede design testbart

Vælg ét mål, for eksempel en webgrænseflade i labbet på sit eget serversubnet, og bevis det i begge retninger. Bekræft på en host i filialen adressen og den lyttende tjeneste lokalt, og forbind derefter gennem tunnelen og gentag. En tunnel, der er oppe, beviser, at gatewayerne er enige; den beviser intet om hostfirewallen eller returruten.

Labbets normale gateway har brug for en rute tilbage til filialprefixet, medmindre designet bevidst oversætter kilden, og serverens egen firewall skal acceptere det tilladte fjerne område. Ingen af de to konfigureres af en vellykket tunnel. strongSwans videresendelsesnoter beskriver den pakkesti, der skal virke på hver side.

Test derefter også en afvist destination. En filialbruger, der har brug for én applikation, har ikke brug for hypervisor-konsollen, og den eneste måde at vide, at politikken er reel, er at prøve netop det, den bør afvise. Noter prefixerne, resolverafhængigheden og testresultaterne, og en fremtidig ændring på et af stederne kan gennemgås på minutter i stedet for at blive genopbygget fra hukommelsen.