Routovaný alebo mostový VPN: vyberte podľa toho, kam sa klient musí dostať

V ten istý deň prídu dva tikety: jeden používateľ potrebuje internú webovú aplikáciu a jeden inženier potrebuje, aby sa stolový prístroj správal, akoby sedel v tom istom segmente Ethernet. Na oba sa odpovedá dajte ich na VPN, a práve tam sa problémy začínajú. Routovaný tunel a mostový tunel vytvárajú odlišné vzťahy a každej požiadavke vyhovuje len jeden z nich. Voľba topológie je rozhodnutie o prístupe, nie kryptografické nastavenie.

Dve požiadavky, ktoré pri pulte vyzerajú rovnako

Požiadavkou zamestnanca je služba dostupná cez IP zo zariadenia, ktoré nekontrolujete. Požiadavka inženiera je na úrovni spoja: prístroj očakáva, že uvidí rámce Ethernet a broadcastové objavovanie, a možno aj DHCP zo segmentu, v ktorom si myslí, že je.

To sú rôzne otázky a odpoveď mostom na obe bez dôvodu rozširuje prístup zamestnanca na celú kancelársku LAN.

Napíšte požiadavku ako vetu, kým začnete vyberať: ktoré ciele, ktoré protokoly a ktorí partneri majú vyzerať lokálne. Ak je odpoveďou hostiteľ a port, routovanie to pokryje. Ak je odpoveďou vzťah na úrovni rámca so zariadeniami, ktoré hovoria len broadcastom, most môže byť jedinou možnosťou. Všetko medzi tým si zaslúži testovací segment namiesto produkčnej LAN.

Trasa je užšia ako členstvo v LAN

Routovaný klient dostane adresu v tunelovej podsieti a trasy pre prefixy, ktoré zvolíte. Môže dosiahnuť aplikačný server a nič iné, ak to hovorí politika. Brána sa stane miestom presadenia, za predpokladu, že cez ňu prechádza každá relevantná cesta.

Nezamieňajte trasu s oprávnením. Povedať klientovi, ako dosiahnuť podsieť, mu nebráni skúsiť iný cieľ.

Uplatnite riadenie prístupu tam, kde skutočne môže presadiť tok, a ponechajte vlastné oprávnenia aplikácie na mieste. Široké pravidlo preposielania alebo zabudnuté druhé rozhranie môžu udeliť viac, než naznačuje diagram. Čítajte platné pravidlá, nie zamýšľané. Potom otestujte cieľ, ktorý má zlyhať, pretože politika, ktorú sa nikto nepokúsil porušiť, je hypotéza.

Most mení otázku prijatia

Mostenie spája fyzické rozhranie a zariadenie TAP do softvérového prepínača, takže vzdialené zariadenia sa pripájajú k tej istej broadcastovej doméne. Je to skutočná schopnosť a skutočné riziko: vzdialené zariadenie už nie je routovaný hosť, je to účastník.

Rozhodnite, ktoré zariadenia sa smú pripojiť, ktoré typy rámcov musia prejsť a kde sa blokuje nežiaduca interakcia. Adresovanie a autorita DHCP sa stávajú súčasťou zdieľanej siete a dva servery DHCP v jednom segmente vytvoria presne ten zmätok, ktorý očakávate.

Pre prístroj zvyčajne lepšie poslúži vyhradený testovací segment než kancelárska LAN. Udržte správu mimo experimentu a definujte, ako sa dočasný účastník po skončení práce odstráni.

Filtrovanie existuje v oboch topológiách

Most nie je sám o sebe nefiltrovateľný a trasa nie je sama o sebe bezpečná. Filtrovanie mostov v Linuxe má svoje háky a vlastnú syntax pravidiel a pravidlo napísané pre routované IP preposielanie sa na mostové rámce automaticky nevzťahuje.

Overte, čo platforma skutočne podporuje, kým sľúbite hranicu:

bridge link show
nft list ruleset

TUN a TAP opisujú prevádzku rozhrania, nie šifru. Prepnutie rozhraní nič z toho neopraví: autentizácia partnerov, ukradnutý kľúč aj zastaraná kryptografická politika zmenu prežijú. Obe strany stále potrebujú nastavenia, ktoré si zodpovedajú a sú stále podporované.

Dokážte hranicu tromi pokusmi

Prijatie sú tri pozorovania, nie prehliadka diagramu. Požadovaná operácia musí fungovať, nesúvisiaci cieľ musí zlyhať a vlastné správne služby brány musia zostať mimo dosahu.

Spustite povolenú aj odmietnutú cestu z toho istého klienta a obe zaznamenajte:

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

Pri moste pridajte kontroly na úrovni spoja: či prechádza povolená prevádzka objavovania, či adresovanie pochádza od zamýšľanej autority a či dočasný účastník po odstránení zmizol. Keď obyčajná routovaná IP požiadavku už spĺňa, pripojenie ku kancelárskemu segmentu Ethernet potrebuje samostatné odôvodnenie a to sa má napísať pred zmenou.