Ruta VPN eller brua LAN for eit samband mellom filial og lab

Det finst to måtar å la ein filial nå eit heimelab på, og skilnaden er ikkje ei innstilling. Du kan rute mellom ulike prefiks, slik at kvar stad held sitt eige kringkastingsdomene, eller du kan brua dei to LAN-a til eitt, slik at kringkasting og oppdagingstrafikk oppfører seg som om alle sat i same rom. Ruting er designet som overlever kontakt med eit ekte nettverk. Bruing er designet som gjer den første veka enkel og det første avbrotet interessant. Samanlikninga nedanfor handlar om kva kvar av dei gjev deg og kva ho kostar, etterfølgt av korleis du gjer den ruta versjonen testbar.

To måtar å kople saman på, éi openberr avveging

Ei ruta lenkje handsamar heimelaben som eit fjernnettverk med eiga adressering. Filialen spør etter labprefikset, tunnelen ber desse pakkane, og labgatewayen svarar frå sitt eige subnett. Ingenting ved ARP-tabellen til filialen endrar seg, og ingenting av DHCP-området til laben når filialen.

Ei brua lenkje strekkjer eitt Layer 2-domene over begge stadene. Oppdagingsprotokollar verkar, einingar dukkar opp automatisk, og kvar kringkasting, kvar ARP-førespurnad og kvar multicastpakke er no ein kandidat for å krysse tunnelen, som er ei stor mengd trafikk båren av protokollar laga for eit lokalt segment og ikkje for eit WAN med ein annan MTU og ei varierande rundturstid.

Kva ruting gjev deg

Den første fordelen er skadeomfanget. Ei løkke, ein rogue DHCP-server eller ei kringkastingsflod blir på staden som skapte ho, fordi ein ruter ikkje videresender kringkasting. Den andre er adresseringsklarleik: filialprefikset og labprefikset er ulike, så destinasjonen til ein pakke fortel deg kva stad som skal svare, og ein brannmurregel kan seie «filial til labsubnett» i staden for «overalt til overalt».

Den tredje er at det passar til det tunnelen faktisk transporterer. Ein IPsec-policy er eit par prefiks, og videresendingsvegen på kvar side er vanleg 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 gjev opp, er oppdaging via kringkasting. Det er eit reelt tap, og det bør erstattast medvite i staden for å omgåast ved å brua alt.

Kva bruing kostar

Bruing må bera Layer 2-rammer over ein tunnel, som tyder ein innkapsling som GRE eller VXLAN over IPsec i staden for ein vanleg policybasert tunnel. Når det finst, deler dei to stadene eit feildomene. Spanning tree ser tunnelen som ei lenkje, kringkastingstrafikk et tunnelbandbreidd, og kvar eining som føreset eit segment med låg latenstid, oppfører seg feil på måtar som er vanskelege å tilskrive frå nokon av endane.

Det fjernar også adresseringskontrollen som held deg ærleg. Med eitt flatt prefiks er ei dobbel adresse ikkje ein rutefeil, men to vertar som stille stel trafikk frå kvarandre, og overlappande prefiks mellom ein filial og ein lab er vanlege i heimelaboppsett, så bruing løyser ikkje den konflikten; ho fordeler han.

Sikkerheitsargumentet er det som vanlegvis avgjer saka. Ei bru strekkjer segmentet der link-local-protokollar verkar, så ei eining i filialen kan snakke med labeiningar som aldri var meinte å vere tilgjengelege utanfrå. Har laben ein hypervisor, ein lagringskonsoll og eit administrasjonsgrensesnitt på same flate nett, er det no eitt segment saman med filialen.

Namn utan kringkasting

Grunnen til at folk bruar, er vanlegvis oppdaging: ein skrivar, ei medieeining eller ein labvert som aldri dukkar opp i ei liste. Det ruta svaret er ein namneteneste. Publiser labvertane i ei sone som resolvaren til filialen kan nå, og la brukarane deretter kople til med namn i staden for å skanne nettverket. Det er meir arbeid på førehand og betydeleg mindre arbeid ved kvar framtidig endring.

Multicastoppdaging er det vanskelegare tilfellet, og det fortener presisjon. Protokollar som mDNS brukar link-local multicast, som rutarar ikkje videresender som standard, så ein labvert som manglar i ei oppdagingsliste kan framleis nåast på den dokumenterte adressa si. Viss ein bestemt teneste verkeleg krev multicast, planlegg den eine tenesta, med ein reflector eller ein målretta videresendingsregel, i staden for å brua heile LAN-et som ein generell reparasjon.

Ein reflector er heller ikkje nokon gratis gevinst. Han importerer den same pratsame trafikken du prøvde å unngå, éi teneste om gongen, og han treng ein eigar som legg merke til når ei eining byrjar å annonsere meir enn ho pleidde. Vel han per teneste, og skriv ned kvifor. Noter kva teneste som trong han og kva ho annonserer, for ei fastvareoppdatering kan endre den lista utan å seie frå til nokon.

Gjer det ruta designet testbart

Vel eitt mål, til dømes eit webgrensesnitt i laben på eit eige serversubnett, og prov det i begge retningar. Stadfest på ein vert i filialen adressa og den lyttande tenesta lokalt, kople deretter gjennom tunnelen og gjenta. Ein tunnel som er oppe provar at gatewayane er samde; han provar ingenting om brannmuren til verten eller returvegen.

Den normale gatewayen til laben treng ein rute tilbake til filialprefikset med mindre designet medvite omset kjelda, og brannmuren til serveren sjølv må godta det tillatne eksterne området. Ingen av dei blir konfigurerte av ein vellukka tunnel. videresendingsnotata til strongSwan skildrar pakkevegen som må verke på kvar side.

Test deretter også ein avvist destinasjon. Ein filialbrukar som treng éin applikasjon, treng ikkje hypervisorkonsollen, og den einaste måten å vite at policyen er ekte, er å prøve nettopp det han skal avvise. Noter prefiksa, resolveravhengigheita og testresultata, og ei framtidig endring på ein av stadene kan gjennomgåast på minutt i staden for å byggjast opp på nytt frå minnet.