Enkursigita aŭ pontita VPN: elektu laŭ tio, kion la kliento devas atingi

Du biletoj alvenas samtage: unu uzanto bezonas internan retan aplikaĵon, kaj unu inĝeniero bezonas, ke laborbenka instrumento kondutu kvazaŭ ĝi starus en la sama Ethernet-segmento. Al ambaŭ oni respondas metu ilin sur la VPN, kaj ĝuste tie komenciĝas la problemo. Enkursigita tunelo kaj pontita tunelo etendas malsamajn rilatojn, kaj nur unu el ili kongruas kun ĉiu peto. Elekti la topologion estas alira decido, ne kriptografia agordo.

Du petoj, kiuj aspektas same ĉe la bileta fenestro

La postulo de la dungito estas servo, atingebla per IP, el aparato, kiun vi ne regas. La postulo de la inĝeniero estas je liga nivelo: la instrumento atendas vidi Ethernet-kadrojn kaj dissendan malkovron, kaj eble DHCP el la segmento, en kiu ĝi kredas sin.

Tiuj estas malsamaj demandoj, kaj respondi ambaŭ per ponto senkiale vastigas la aliron de la dungito al la tuta oficeja LAN.

Skribu la postulon kiel frazon antaŭ ol elekti: kiuj celoj, kiuj protokoloj kaj kiuj kunuloj devas ŝajni lokaj. Se la respondo estas gastiganto kaj pordo, enkursigado kovras ĝin. Se la respondo estas rilato je kadra nivelo kun aparatoj, kiuj parolas nur per dissendo, ponto eble estas la sola opcio. Io ajn intere meritas testan segmenton anstataŭ la produktadan LAN.

Itinero estas pli mallarĝa ol LAN-membreco

Enkursigita kliento ricevas adreson en tunela subreto kaj itinerojn por la prefiksoj, kiujn vi elektas. Ĝi povas atingi la aplikaĵan servilon kaj nenion alian, se tion diras la politiko. La kluzo fariĝas la plenum-punkto, kondiĉe ke ĉiu rilata vojo trapasas ĝin.

Ne konfuzu itinero kun permeso. Diri al kliento, kiel atingi subreton, ne malhelpas ĝin provi alian celon.

Apliku alirkontrolon tie, kie ĝi povas efektive plenumi la fluon, kaj konservu la proprajn permesojn de la aplikaĵo. Larĝa plusenda regulo aŭ forgesita dua interfaco povas doni pli, ol la diagramo sugestas. Legu la validajn regulojn, ne la intencitajn. Poste testu celon, kiu devus malsukcesi, ĉar politiko, kiun neniu provis malobservi, estas hipotezo.

Ponto ŝanĝas la akceptan demandon

Pontado kunigas fizikan interfacon kaj TAP-aparaton en softvaran ŝaltilon, do remotaj aparatoj aliĝas al la sama dissenda domajno. Tio estas reala kapablo kaj reala risko: la remota aparato ne plu estas enkursigita gasto, ĝi estas partoprenanto.

Decidu, kiuj aparatoj rajtas aliĝi, kiuj kadraj tipoj devas trapasi kaj kie nedezirata interagado blokiĝas. Adresado kaj DHCP-aŭtoritato fariĝas parto de la komuna reto, kaj du DHCP-serviloj en unu segmento produktas ĝuste la ĥaoson, kiun vi atendas.

Por la instrumento, dediĉita testa segmento kutime pli taŭgas ol la oficeja LAN. Tenu administran aliron ekster la eksperimento, kaj difinu, kiel la provizora partoprenanto foriĝas, kiam la laboro finiĝas.

Filtrado ekzistas en ambaŭ topologioj

Ponto ne estas esence nefiltrebla, kaj itinero ne estas esence sekura. Linux-pontfiltrado havas proprajn hokojn kaj propran regulsintakson, kaj regulo verkita por enkursigita IP-plusendado ne aŭtomate aplikiĝas al pontitaj kadroj.

Kontrolu, kion la platformo efektive subtenas, antaŭ ol promesi limon:

bridge link show
nft list ruleset

TUN kaj TAP priskribas la trafikon de la interfaco, ne la ĉifron. Ŝanĝi interfacojn riparas neniom el tio: kunula aŭtentikigo, ŝtelita ŝlosilo kaj malaktuala kriptografia politiko ĉiuj postvivas la ŝanĝon. Ambaŭ finoj ankoraŭ bezonas agordojn, kiuj kongruas kaj ankoraŭ estas subtenataj.

Pruvu la limon per tri provoj

Akcepto estas tri observoj, ne trarigardo de diagramo. La postulata operacio devas funkcii, nerilata celo devas malsukcesi, kaj la propraj administraj servoj de la kluzo devas resti neatingeblaj.

Lanĉu la permesitan kaj la malpermesitan vojon el la sama kliento, kaj registru ambaŭ:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Por ponto, aldonu la lig-nivelajn kontrolojn: ĉu la permesita malkovra trafiko trapasas, ĉu adresado venas de la intencita aŭtoritato, kaj ĉu la provizora partoprenanto malaperis post forigo. Kiam ordinara enkursigita IP jam plenumas la postulon, aliĝi al la oficeja Ethernet-segmento bezonas apartan pravigon, kaj ĝi skribiĝu antaŭ la ŝanĝo.