Rutet VPN eller broet LAN for en forbindelse mellom filial og lab

Det finnes to måter å la en filial nå et hjemmelab, og forskjellen er ikke en innstilling. Du kan rute mellom ulike prefikser, slik at hvert sted beholder sitt eget kringkastingsdomene, eller du kan bro de to LAN-ene til ett, slik at kringkasting og oppdagelsestrafikk oppfører seg som om alle satt i samme rom. Ruting er designet som overlever kontakt med et ekte nettverk. Broing er designet som gjør den første uken enkel og det første avbruddet interessant. Sammenligningen nedenfor handler om hva hver av dem gir deg og hva den koster, etterfulgt av hvordan du gjør den rutete versjonen testbar.

To måter å koble sammen på, én åpenbar avveining

En rutet lenke behandler hjemmelaben som et fjernnettverk med egen adressering. Filialen spør etter labprefikset, tunnelen bærer disse pakkene, og labgatewayen svarer fra sitt eget subnett. Ingenting ved filialens ARP-tabell endres, og ingenting av labens DHCP-område når filialen.

En broet lenke strekker ett Layer 2-domene over begge steder. Oppdagelsesprotokoller virker, enheter dukker opp automatisk, og hver kringkasting, hver ARP-forespørsel og hver multicastpakke er nå en kandidat for å krysse tunnelen, som er en stor mengde trafikk båret av protokoller laget for et lokalt segment og ikke for et WAN med en annen MTU og en varierende rundturstid.

Hva ruting gir deg

Den første fordelen er skadeomfanget. En løkke, en rogue DHCP-server eller en kringkastingsflom blir på stedet som skapte den, fordi en ruter ikke videresender kringkasting. Den andre er adresseringsklarhet: filialprefikset og labprefikset er forskjellige, så en pakkes destinasjon forteller deg hvilket sted som skal svare, og en brannmurregel kan si «filial til labsubnett» i stedet for «overalt til overalt».

Den tredje er at det passer til det tunnelen faktisk transporterer. En IPsec-policy er et par prefikser, og videresendingsveien på hver side er vanlig IP-ruting med forwarding slått på i 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 gir opp, er oppdagelse via kringkasting. Det er et reelt tap, og det bør erstattes bevisst i stedet for å omgås ved å bro alt.

Hva broing koster

Broing må bære Layer 2-rammer over en tunnel, som betyr en innkapsling som GRE eller VXLAN over IPsec i stedet for en vanlig policybasert tunnel. Når det finnes, deler de to stedene et feildomene. Spanning tree ser tunnelen som en lenke, kringkastingstrafikk spiser tunnelbåndbredde, og enhver enhet som forutsetter et segment med lav latenstid, oppfører seg feil på måter som er vanskelige å tilskrive fra noen av endene.

Det fjerner også adresseringskontrollen som holder deg ærlig. Med ett flatt prefiks er en dobbel adresse ikke en rutefeil, men to verter som stille stjeler trafikk fra hverandre, og overlappende prefikser mellom en filial og en lab er vanlige i hjemmelaboppsett, så broing løser ikke den konflikten; den fordeler den.

Sikkerhetsargumentet er det som vanligvis avgjør saken. En bro strekker segmentet der link-local-protokoller virker, så en enhet i filialen kan snakke med labenheter som aldri var ment å være tilgjengelige utenfra. Har laben en hypervisor, en lagringskonsoll og et administrasjonsgrensesnitt på samme flate nett, er det nå ett segment sammen med filialen.

Navn uten kringkasting

Grunnen til at folk broer, er vanligvis oppdagelse: en skriver, en medieenhet eller en labvert som aldri dukker opp i en liste. Det rutete svaret er en navnetjeneste. Publiser labvertene i en sone som filialens resolver kan nå, og la brukerne deretter koble til med navn i stedet for å skanne nettverket. Det er mer arbeid på forhånd og betydelig mindre arbeid ved hver fremtidige endring.

Multicastoppdagelse er det vanskeligere tilfellet, og det fortjener presisjon. Protokoller som mDNS bruker link-local multicast, som rutere ikke videresender som standard, så en labvert som mangler i en oppdagelsesliste kan fortsatt nås på sin dokumenterte adresse. Hvis en bestemt tjeneste virkelig krever multicast, planlegg den ene tjenesten, med en reflector eller en målrettet videresendingsregel, i stedet for å bro hele LAN-et som en generell reparasjon.

En reflector er heller ikke noen gratis gevinst. Den importerer den samme pratsomme trafikken du prøvde å unngå, én tjeneste om gangen, og den trenger en eier som merker når en enhet begynner å annonsere mer enn den pleide. Velg den per tjeneste, og skriv ned hvorfor. Noter hvilken tjeneste som trengte den og hva den annonserer, for en fastvareoppdatering kan endre den listen uten å si fra til noen.

Gjør det rutete designet testbart

Velg ett mål, for eksempel et webgrensesnitt i laben på et eget serversubnett, og bevis det i begge retninger. Bekreft på en vert i filialen adressen og den lyttende tjenesten lokalt, koble deretter gjennom tunnelen og gjenta. En tunnel som er oppe beviser at gatewayene er enige; den beviser ingenting om vertens brannmur eller returveien.

Labens normale gateway trenger en rute tilbake til filialprefikset med mindre designet bevisst oversetter kilden, og serverens egen brannmur må godta det tillatte eksterne området. Ingen av dem konfigureres av en vellykket tunnel. strongSwans videresendingsnotater beskriver pakkeveien som må virke på hver side.

Test deretter også en avvist destinasjon. En filialbruker som trenger én applikasjon, trenger ikke hypervisorkonsollen, og den eneste måten å vite at policyen er ekte, er å prøve nettopp det den skal avvise. Noter prefiksene, resolveravhengigheten og testresultatene, og en framtidig endring på et av stedene kan gjennomgås på minutter i stedet for å bygges opp på nytt fra hukommelsen.