Geroteerde VPN of gebrugde LAN vir ’n skakel van tak na lab

Daar is twee maniere om ’n tak by ’n tuislab uit te bring, en die verskil is nie ’n instelling nie. Jy kan tussen afsonderlike voorvoegsels roeteer, sodat elke werf sy eie uitsendingsdomein hou, of jy kan die twee LAN's in een brug, sodat uitsendings en discovery-verkeer optree asof almal in dieselfde kamer is. Roetering is die ontwerp wat kontak met ’n werklike netwerk oorleef. Brugging is die ontwerp wat die eerste week maklik maak en die eerste onderbreking interessant maak. Die vergelyking hieronder handel oor wat elkeen jou gee en wat dit kos, gevolg deur hoe om die geroteerde weergawe toetsbaar te maak.

Twee maniere om te verbind, een duidelike afweging

’n Geroteerde skakel behandel die tuislab as ’n afgeleë netwerk met sy eie adressering. Die tak vra vir die lab-voorvoegsel, die tonnel dra daardie pakkette, en die lab-poort antwoord uit sy eie subnet. Niks aan die tak se ARP-tabel verander nie, en niks van die lab se DHCP-omvang bereik die tak nie.

’n Gebrugde skakel strek een Laag 2-domein oor albei werven. Discovery-protokolle werk, toestelle verskyn outomaties, en elke uitsending, elke ARP-versoek en elke multicast-pakket is nou ’n kandidaat om die tonnel oor te steek, wat ’n groot hoeveelheid verkeer is wat gedra word deur protokolle wat vir ’n plaaslike segment ontwerp is en nie vir ’n WAN met ’n ander MTU en ’n wisselende rondtyd nie.

Wat roetering jou gee

Die eerste voordeel is die omvang van die skade. ’n Lus, ’n rogue DHCP-bediener of ’n uitsendingsvloed bly op die werf wat dit veroorsaak het, want ’n roeteerder stuur nie uitsendings aan nie. Die tweede is adresseringshelderheid: die tak-voorvoegsel en die lab-voorvoegsel is afsonderlik, so ’n pakket se bestemming sê vir jou watter werf moet antwoord, en ’n vuurmuur-reël kan „tak na lab-subnet“ sê eerder as „oral na oral“.

Die derde is dat dit pas by wat die tonnel werklik vervoer. ’n IPsec-beleid is ’n paar voorvoegsels, en die aanstuurpad aan elke kant is gewone IP-roetering met aansturing geaktiveer op die poort:

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

Wat jy prysgee, is discovery per uitsending. Dit is ’n werklike verlies, en dit moet doelbewus vervang word eerder as om dit te omseil deur alles te brug.

Wat brugging kos

Brugging moet Laag 2-rame oor ’n tonnel dra, wat ’n inkapseling soos GRE of VXLAN oor IPsec beteken eerder as ’n gewone beleidsgebaseerde tonnel. Sodra dit bestaan, deel die twee werven ’n foutdomein. Spanning tree sien die tonnel as ’n skakel, uitsendingsverkeer vreet tonnelbandwydte, en enige toestel wat ’n segment met lae latency verwag, gedra hom verkeerd op maniere wat van albei kante moeilik toe te skryf is.

Dit verwyder ook die adresseringskontrole wat jou eerlik hou. Met een plat voorvoegsel is ’n dubbele adres nie ’n roeteringsfout nie, maar twee gashere wat mekaar stilweg se verkeer steel, en oorvleuelende voorvoegsels tussen ’n tak en ’n lab is algemeen in tuislab-opstellings, so brugging los nie daardie konflik op nie; dit versprei dit.

Die sekuriteitsargument is die een wat dit gewoonlik beslis. ’n Brug strek die segment waarop link-local-protokolle werk, so ’n toestel in die tak kan praat met lab-toestelle wat nooit bedoel was om van buite bereikbaar te wees nie. As die lab ’n hypervisor, ’n stoorkonsole en ’n bestuurskoppelvlak op dieselfde plat netwerk het, is dit nou een segment saam met die tak.

Name sonder uitsending

Die rede waarom mense brug, is gewoonlik discovery: ’n drukker, ’n mediatoestel of ’n lab-gasheer wat nooit in ’n lys verskyn nie. Die geroteerde antwoord is ’n naamdiens. Publiseer die lab-gashere in ’n sone wat die tak se resolver kan bereik, en laat gebruikers dan per naam verbind eerder as om die netwerk te skandeer. Dit is meer werk vooraf en aansienlik minder werk by elke toekomstige verandering.

Multicast-discovery is die moeiliker geval, en dit verdien presisie. Protokolle soos mDNS gebruik link-local multicast, wat roeteerders nie by verstek aanstuur nie, so ’n lab-gasheer wat uit ’n discovery-lys ontbreek, kan steeds by sy gedokumenteerde adres bereikbaar wees. As ’n spesifieke diens werklik multicast vereis, beplan daardie een protokol, met ’n weerkaatser of ’n gerigte aanstuur-reël, eerder as om die hele LAN as ’n algemene herstelling te brug.

’n Weerkaatser is ook nie ’n gratis wins nie. Dit voer dieselfde spraaksame verkeer in wat jy wou vermy, een diens op ’n slag, en dit het ’n eienaar nodig wat sal opmerk wanneer ’n toestel meer begin adverteer as voorheen. Kies dit per diens, en skryf neer waarom. Teken aan watter diens dit nodig gehad het en wat dit adverteer, want ’n firmware-opdatering kan daardie lys verander sonder om iemand te sê.

Maak die geroteerde ontwerp toetsbaar

Kies een teiken, soos ’n lab-webkoppelvlak op sy eie bediener-subnet, en bewys dit in albei rigtings. Bevestig op ’n gasheer in die tak die adres en die luisterende diens plaaslik, verbind dan deur die tonnel en herhaal. ’n Tonnel wat op is, bewys dat die poorte dit eens is; dit bewys niks oor die gasheer se vuurmuur of die terugroete nie.

Die lab se normale poort het ’n roete terug na die tak-voorvoegsel nodig tensy die ontwerp die bron doelbewus vertaal, en die bediener se eie vuurmuur moet die toegelate afgeleë reeks aanvaar. Nie een van dié twee word deur ’n suksesvolle tonnel opgestel nie. Die aanstuur-notas van strongSwan beskryf die pakketpad wat aan elke kant moet werk.

Toets dan ook ’n geweierde bestemming. ’n Tak-gebruiker wat een toepassing nodig het, het nie die hypervisor-konsole nodig nie, en die enigste manier om te weet dat die beleid werklik is, is om juis dit te probeer wat dit behoort te weier. Teken die voorvoegsels, die resolver-afhanklikheid en die toetsresultate aan, en ’n toekomstige verandering aan een van die werven kan in minute hersien word eerder as om uit die geheue herbou te word.