Ruteeritud VPN või sillatud LAN haru ja labori vaheliseks ühenduseks

Haru ja kodulabori vahelise ühenduse saab teha kahel viisil ja erinevus ei ole seade. Võid ruteerida erinevate prefiksite vahel, nii et iga sait säilitab oma leviedastusdomeeni, või sillutada kaks LAN-i üheks, nii et leviedastused ja avastamisliiklus käituvad nii, nagu oleksid kõik samas ruumis. Ruteerimine on lahendus, mis peab vastu kokkupuutele tõelise võrguga. Sillutamine on lahendus, mis teeb esimese nädala lihtsaks ja esimese rikke huvitavaks. Alljärgnev võrdlus räägib sellest, mida kumbki annab ja mida see maksab, ning seejärel sellest, kuidas teha ruteeritud versioon testitavaks.

Kaks ühendamisviisi, üks ilmne kompromiss

Ruteeritud ühendus käsitleb kodulaborit oma adresseeringuga kaugvõrguna. Haru küsib labori prefiksit, tunnel kannab need paketid ja labori lüüs vastab oma alavõrgust. Haru ARP-tabelis ei muutu miski ja miski labori DHCP-ulatusest ei jõua haruni.

Sillatud ühendus laiendab ühte 2. kihi domeeni üle mõlema saidi. Avastamisprotokollid töötavad, seadmed ilmuvad automaatselt ja iga leviedastus, iga ARP-päring ja iga multicast-pakett on nüüd tunnelist läbimineku kandidaat, see tähendab suurt liiklushulka, mida kannavad protokollid, mis on loodud kohaliku segmendi jaoks, mitte WAN-i jaoks, millel on teine MTU ja muutuv edasi-tagasi aeg.

Mida ruteerimine sulle annab

Esimene eelis on kahju ulatus. Silmus, soovimatu DHCP-server või leviedastuste uputus jääb saiti, mis selle tekitas, sest ruuter ei edasta leviedastusi. Teine on adresseerimise selgus: haru prefiks ja labori prefiks on erinevad, nii et paketi sihtkoht ütleb sulle, milline sait peab vastama, ja tulemüüri reegel võib öelda „haru labori alavõrku” mitte „kõikjalt kõikjale”.

Kolmas on see, et see vastab sellele, mida tunnel tegelikult kannab. IPsec-poliitika on prefiksite paar ja edastustee kummaski servas on tavaline IP-ruteerimine, kus lüüsil on edastamine sisse lülitatud:

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

Sellest, millest loobud, on leviedastusel põhinev avastamine. See on tõeline kaotus ja see tuleks asendada teadlikult, mitte mööda minna kõige sillutamisest.

Mida sillutamine maksab

Sillutamine peab kandma 2. kihi kaadreid läbi tunneli, mis tähendab kapseldamist nagu GRE või VXLAN üle IPsec-i, mitte lihtsat poliitikapõhist tunnelit. Kui see on olemas, jagavad kaks saiti tõrkedomeeni. Spanning tree näeb tunnelit ühendusena, leviedastusliiklus kulutab tunneli ribalaiust ja iga seade, mis eeldab väikese latentsusega segmenti, käitub valesti viisil, mida on mõlemast otsast raske omistada.

See eemaldab ka adresseerimise kontrolli, mis hoiab sind ausana. Ühe lapiku prefiksiga ei ole dubleeritud aadress ruteerimisviga, vaid kaks hosti, kes vaikselt varastavad teineteise liiklust, ja kattuvad prefiksid haru ja labori vahel on kodulabori seadistustes tavalised, nii et sillutamine ei lahenda seda konflikti; see jaotab selle.

Turvaargument on see, mis tavaliselt otsustab. Sild laiendab segmenti, millel link-local protokollid töötavad, nii et haru seade saab rääkida labori seadmetega, mis ei pidanud kunagi olema väljastpoolt kättesaadavad. Kui laboril on hüpervisor, salvestuskonsool ja haldusliides samas lapikus võrgus, on see nüüd üks segment koos haruga.

Nimed ilma leviedastuseta

Põhjus, miks inimesed sillutavad, on tavaliselt avastamine: printer, meediaseade või labori host, mis ei ilmu kunagi nimekirja. Ruteeritud vastus on nimeteenus. Avalda labori hostid tsoonis, mida haru resolver saab kätte, ja lase siis kasutajatel ühenduda nime järgi, mitte võrku skaneerida. See on alguses rohkem tööd ja iga tulevase muudatuse juures tunduvalt vähem tööd.

Multicast-avastamine on raskem juhtum ja väärib täpsust. Protokollid nagu mDNS kasutavad link-local multicast'i, mida ruuterid vaikimisi ei edasta, nii et avastamisnimekirjast puuduv labori host võib olla dokumenteeritud aadressil siiski kättesaadav. Kui konkreetne teenus tõesti nõuab multicast'i, planeeri see üks protokoll, reflektoriga või sihitud edastusreegliga, mitte ära silluta kogu LAN-i üldise parandusena.

Ka reflektor ei ole tasuta võit. See toob sisse sama jutuka liikluse, mida sa püüdsid vältida, ühe teenuse kaupa, ja see vajab omanikku, kes märkab, kui seade hakkab reklaamima rohkem kui varem. Vali see iga teenuse jaoks ja kirjuta üles, miks. Pane kirja, milline teenus seda vajas ja mida see reklaamib, sest püsivara uuendus võib selle nimekirja muuta, ilma et kellelegi ütleks.

Tee ruteeritud lahendus testitavaks

Vali üks sihtmärk, näiteks labori veebiliides oma serveri alavõrgus, ja tõesta seda mõlemas suunas. Kontrolli haru hostil aadress ja kuulav teenus kohapeal, seejärel ühendu tunnelist läbi ja korda. Üleval olev tunnel tõestab, et lüüsid on ühel meelel; hosti tulemüüri ega tagasitee kohta ei tõesta see midagi.

Labori tavaline lüüs vajab tagasiteed haru prefiksini, kui lahendus ei tõlgi allikat teadlikult, ja serveri enda tulemüür peab lubama lubatud kaugvahemikku. Kumbagi neist ei sea üles õnnestunud tunnel. strongSwan'i edastusmärkmed kirjeldavad paketi teed, mis peab kummaski servas töötama.

Seejärel katseta ka keelatud sihtkohta. Haru kasutaja, kes vajab ühte rakendust, ei vaja hüpervisori konsooli, ja ainus viis teada, et poliitika on tõeline, on proovida täpselt seda, mida see peaks keelduma. Pane kirja prefiksid, resolverist sõltuvus ja testitulemused, ja tulevase muudatuse kummaski saidis saab üle vaadata minutitega, mitte mälust uuesti ehitada.