Sillatud saidid vajavad endiselt kohaliku internetiväljundi otsust

VLAN-i laiendus läbis puhtalt: mõlema saidi hostid näevad üksteist, failijagamine töötab ja printerid vastavad. Siis märkab keegi väiksemal saidil, et iga allalaadimine kasutab teise saidi internetiliini, ja pilet saabub ribalaiuse kaebusena. Sild tegi täpselt seda, mida temalt paluti. See kandis kaadreid kahe hoone vahel ega omanud kunagi arvamust, millist ruuterit peaksid need kaadrid interneti jaoks kasutama.

Sild kannab kaadreid, mitte otsuseid

Kihi 2 laiendus paneb kaks asukohta välja nägema ühe leviedastusdomeenina, seega ARP-päringud, DHCP leviedastused ja sama alamvõrgu liiklus läbivad kõik tunnelit. See on kogu teenus, mida see pakub. Miski sillal ei kontrolli sihtiaadressi, ei võrdle seda saidi ühendusliiniga ega suuna liiklust lähemale väljundile. Iga klient teeb endiselt oma kohaliku või kaugotsuse, kasutades aadressi ja maski, millega see konfigureeriti.

Pange sellesse jagatud alamvõrku kaks ruuterit ja mõlemast saab tõenäoline lüüs, ükskõik kas kumbki on selle kliendi lähedal, kes seda kasutab.

Kuidas klient oma lüüsi valib

RFC 1122-s kirjeldatud IPv4 otsus on lihtne. Sihtkoht kliendi ühendatud alamvõrgu sees saavutatakse otse, ARP-iga, ja sellest väljapoole jääv sihtkoht läheb konfigureeritud vaikelüüsile. Seetõttu saab sama alamvõrgu liiklus saidite vahel sillast läbi minna ilma igasuguse ruuteri osaluseta ja seetõttu sõltub internetiliiklus täielikult lüüsi aadressist, mille klient sai. Need kaks käitumist on sõltumatud ja töötav failijagamine tõestab ainult esimest.

Kui väikese saidi klient konfigureeriti suure saidi ruuteriga, läbivad tema internetikaadrid kõigepealt tunneli ja väljuvad sealt.

VPN-seadme enda vaikemarsruudi muutmine ei liiguta selle kliendi lüüsi, sest klient ei kasuta seadet ruuterina üldse. Seadmel on vaja ka eraldi marsruuti oma kaugpartnerini, et neid kaadreid kandev tunnel püsiks, ja nende kahe segamine on see, kuidas sillalaiendus oma enda transpori maha võtab.

Laske DHCP-l kavatsetud väljundit väljendada

Valik 3 DHCP vastuses annab kliendi alamvõrgus olevate ruuterite aadresside loendi eelistusjärjekorras ja kliendid võtavad tavaliselt esimese, mis vastab. Mehhanism on korras; omandivorm on koht, kus disainid viltu lähevad. Kirjutage üles, mida tegelik rendileping igal saidil annab, selle asemel et eeldada, et lähim DHCP server annab lähima lüüsi.

Käitage ühte koordineeritud jaotajat või kahte, mis on selgesõnaliselt sama poliitika jaoks konfigureeritud, ja andke poliitikale omanik. Kaugsaidi lisatud teine sõltumatu jaotaja ei loo lokaalsust, vaid loob sama leviedastusdomeeni jaoks kaks võimu.

Ärge määrake ühte lüüsi aadressi kahele sõltumatult aktiivsele ruuterile ainult selleks, et mõlema saidi seaded näeksid identsed välja. Jagatud virtuaalne aadress sillatud segmendi ulatuses on esimese hüppe liiasuslahendus omade nõuetega ja käsitsi tehtud versioon tekitab ARP konflikte, mis näevad välja nagu vahelduv paketikadu. Kui rakendus ei vaja tegelikult jagatud kihi 2 segmenti, on eraldi marsruuditud prefiksid kohalike vaikelüüsidega lihtsamad käitada ja intsidendi ajal kergemini seletatavad.

Testige nelja asja eraldi

Küsige nelja vaatlust, mitte ühte. Võtke igal saidil uus DHCP rendileping ja kirjutage üles saadud ruuter ja mask. Jõudke teisel saidil sama alamvõrgu teenuseni ja kinnitage, et tee on sild, mitte marsruuditud ümbersõit. Tooge igal saidil midagi avalikust internetist ja kinnitage, milline ühendusliin seda kandis. Seejärel laske tunnel alla ja vaadake, mis katkeb, sest sait, mis kaotab kogu ühenduvuse, kui sild ebaõnnestub, sõltus kauglüüsist, ilma et keegi märkaks.

Need neli tulemust ütlevad, kas teil on saidiülene sild, kohalik väljund või juhuslik tagasivedu, ja nende kogumine võtab kümme minutit.

Disainipõhimõte pole glamuursne: sildamine otsustab kättesaadavuse, DHCP otsustab lüüsi ja seadme marsruutimistabel otsustab tunneli enda tee. Hoidke need kolm eraldi vestlustes, sest üks muudatus, mis proovib parandada kõiki kolme, rikub tavaliselt kaks.