Routolt vagy hidalt VPN: aszerint válasszon, mit kell elérnie a kliensnek
A routolt hozzáférés kiválasztott szolgáltatásokat szállít; a hidalt hozzáférés egy szegmenshez csatlakozik. Döntsön aszerint, mit kell elérnie a kliensnek, majd ellenőrizze a felépített határt.
Ugyanazon a napon két jegy érkezik: az egyik felhasználónak belső webalkalmazás kell, a másik mérnöknek pedig az kell, hogy egy padműszer úgy viselkedjen, mintha ugyanazon az Ethernet-szegmensen ülne. Mindkettőre az a válasz, hogy tegyék fel a VPN-re, és itt kezdődik a baj. A routolt alagút és a hidalt alagút különböző viszonyokat feszít ki, és minden kéréshez csak az egyikük illik. A topológia kiválasztása hozzáférési döntés, nem kriptográfiai beállítás.
Két kérés, amely a jegyablaknál egyformának látszik
A munkavállaló igénye egy szolgáltatás, IP-n elérhető, olyan eszközről, amelyet Ön nem irányít. A mérnök igénye kapcsolati szintű: az eszköz Ethernet-kereteket és sugárzásos felderítést vár, és esetleg DHCP-t abból a szegmensből, amelyben hiszi magát.
Ezek különböző kérdések, és mindkettőre híddal válaszolni ok nélkül kiterjeszti a munkavállaló hozzáférését az egész irodai LAN-ra.
Választás előtt írja le az igényt egy mondatban: mely célok, mely protokollok és mely partnerek tűnjenek helyinek. Ha a válasz egy hoszt és egy port, a routolás lefedi. Ha a válasz keretszintű viszony olyan eszközökkel, amelyek csak sugárzással beszélnek, a híd lehet az egyetlen lehetőség. A kettő közötti bármi teszt szegmenst érdemel a termelési LAN helyett.
Egy útvonal szűkebb, mint a LAN-tagság
A routolt kliens címet kap egy alagút-alhálózaton, és útvonalakat a kiválasztott előtagokhoz. Elérheti az alkalmazásszervert és semmi mást, ha ezt mondja a házirend. Az átjáró lesz a kényszerítési pont, feltéve, hogy minden releváns útvonal keresztülhalad rajta.
Ne keverje össze az útvonalat az engedéllyel. Ha megmondja egy kliensnek, hogyan érje el az alhálózatot, attól még megpróbálhat másik célt.
Ott alkalmazzon hozzáférés-vezérlést, ahol valóban érvényesíteni tudja a forgalmat, és tartsa meg az alkalmazás saját jogosultságait. Egy széles továbbítási szabály vagy egy elfelejtett második interfész többet adhat, mint amit az ábra sugall. A tényleges szabályokat olvassa, ne a szándékoltakat. Aztán teszteljen egy célt, amelynek kudarcot kell vallania, mert a szabályzat, amelyet senki nem próbált megsérteni, hipotézis.
A híd megváltoztatja a beengedés kérdését
A hidalás egy fizikai interfészt és egy TAP-eszközt szoftveres kapcsolóvá egyesít, így a távoli eszközök ugyanahhoz a sugárzási tartományhoz csatlakoznak. Ez valódi képesség és valódi kockázat: a távoli eszköz már nem routolt vendég, hanem résztvevő.
Döntse el, mely eszközök csatlakozhatnak, milyen kerettípusoknak kell átjutniuk, és hol blokkolják a nem kívánt interakciót. A címzés és a DHCP-jogosultság a megosztott hálózat részévé válik, és két DHCP-szerver egy szegmensen pontosan azt a zűrzavart kelti, amelyre számít.
Az eszköz számára általában jobban illik egy dedikált teszt szegmens, mint az irodai LAN. Tartsa a felügyeleti hozzáférést a kísérleten kívül, és határozza meg, hogyan távolítják el az ideiglenes résztvevőt a munka végén.
A szűrés mindkét topológiában létezik
A híd nem eleve szűrhetetlen, és az útvonal nem eleve biztonságos. A Linux hídszűrésének saját horgai és saját szabályszintaxisa vannak, és a routolt IP-továbbításhoz írt szabály nem vonatkozik automatikusan a hidalt keretekre.
Ellenőrizze, mit támogat valójában a platform, mielőtt határt ígér:
bridge link show
nft list ruleset
A TUN és a TAP az interfész forgalmát írja le, nem a titkosítást. Az interfészek cseréje ebből semmit nem javít: a partnerek hitelesítése, egy ellopott kulcs és egy elavult kriptográfiai házirend mind túléli a változtatást. Mindkét végnek továbbra is egymáshoz illő és még támogatott beállításokra van szüksége.
Bizonyítsa a határt három kísérlettel
Az elfogadás három megfigyelés, nem ábraáttekintés. A szükséges műveletnek működnie kell, egy nem kapcsolódó célnak meg kell hiúsulnia, és az átjáró saját felügyeleti szolgáltatásainak elérhetetlennek kell maradniuk.
Futtassa az engedélyezett és a megtagadott útvonalat ugyanarról a kliensről, és jegyezze fel mindkettőt:
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
Híd esetén adja hozzá a kapcsolati szintű ellenőrzéseket: átjut-e az engedélyezett felderítési forgalom, a kijelölt hatóságtól jön-e a címzés, és eltűnt-e az ideiglenes résztvevő az eltávolítás után. Ha a sima routolt IP már kielégíti az igényt, az irodai Ethernet-szegmenshez csatlakozás külön indoklást igényel, és azt a változtatás előtt le kell írni.