Sok VPN-kiszolgálóhoz elég egyetlen fizikai adapter, de ez sem univerzális megoldás. A titkosított kapcsolat ezen az adapteren érkezik, a VPN-folyamat visszafejti, majd a belső forgalom egy virtuális interfészen távozik, mielőtt elérne egy helyi szolgáltatást vagy egy irányított LAN-t. Az, hogy ez működik-e, három feltételtől függ: hol található a cél, van-e a LAN-nak visszaútja az ügyfélkészlethez, és ad-e az egyetlen közös fizikai kapcsolat olyan elkülönítést, amilyet állítasz. Válaszolj erre a háromra, és az adapterek száma ebből következik.

A három feltétel, amely ezt eldönti

Az első feltétel a cél. A VPN-gép saját szolgáltatását csak az alagút interfészen keresztül éri el, míg a LAN-on lévő gép továbbítást és visszautat igényel. A második feltétel ez a visszaút, mert a LAN-eszköznek tudnia kell, hogyan érje el az ügyfélkészletet, akár útvonallal, akár a kiszolgálón végzett címfordítással.

A harmadik feltétel az elkülönítés. Egy adapter azt jelenti, hogy minden csomag, titkosított vagy sem, ugyanazon a kapcsolaton és általában ugyanazon házirendláncon osztozik, így a külön hardvertől függő elkülönítési állítást egyetlen interfész nem teljesíti. Ez az útvonalról szóló tény, nem arról, hogyan van beállítva az operációs rendszer. Az alagút forgalmát továbbra is szűrheted, de olyan határt nem állíthatsz, amely nem létezik.

Egyik sem a ház portjainak számáról szól. Az útvonalválasztásról, a címek tulajdonjogáról és arról szólnak, mennyire függ a terv a fizikai elkülönítéstől.

Két adapter továbbra is jogos választás, ha fizikai zónák, külön uplinkek, átviteli teljesítmény vagy sávon kívüli helyreállítási útvonal indokolja. Ezek konkrét követelmények, és érdemes kimondani őket, mielőtt bárki hardvert rendel.

Amikor a szolgáltatás a VPN-gépen fut

A legegyszerűbb esetben nincs szükség továbbításra. A démon az alagút interfészen fogadja az ügyfél csomagjait, és átadja őket egy helyi socketnek, a válasz pedig ugyanazon az interfészen jön vissza. A gép szempontjából az ügyfélkészlet címe valódi helyi cím.

Két dolognak mégis helyesnek kell lennie: a szolgáltatásnak olyan címen kell figyelnie, amelyet az alagút el tud érni, és a gép tűzfalának el kell fogadnia az alagút interfészen érkező forgalmat. Mindkettő látszik az alábbi parancsokban.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Ha egy szolgáltatást csak a nyilvános címre kötsz, vagy véletlenül szűröd az alagút interfészt, olyan kapcsolat jön létre, amely eléri a gépet, majd meghal. Ez VPN-hibának látszik, és általában socket- vagy tűzfal-döntés.

Amikor a cél a LAN-on van

Itt szerzi meg az egyadapteres terv a nehézkes hírnevét. A kiszolgálónak a LAN felé kell továbbítania az ügyfél csomagjait, a LAN-eszköznek pedig vissza kell küldenie a válaszokat az ügyfélkészletbe. Vagy útvonalként viszed ezt a készletet a LAN-on, vagy a kiszolgálón fordítod a forrás címet, hogy a válaszok magához a kiszolgálóhoz térjenek vissza.

Mindkét válasz jogos, és másként hibázik. A visszautas útvonal az eredeti ügyfélcímet láthatóvá teszi a cél számára, ami jó a naplóknak és rossz azoknak a tűzfalszabályoknak, amelyek LAN-címeket feltételeznek. A címfordítás egyszerűen tartja a LAN-t, és elrejti az ügyfél kilétét a cél elől.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Az aszimmetrikus útvonal a klasszikus tünet: az ügyfél kérése megérkezik, a válasz egy másik útválasztón távozik, és a kapcsolat mindkét végén hibaüzenet nélkül fut ki az időből. Rögzíts forgalmat mindkét oldalon, mielőtt bármit megállapítasz az alagútról.

Miért nem hoz létre egy alias második zónát

Egy második cím hozzáadása ugyanahhoz az adapterhez, vagy egy dummy interfész létrehozása egy második port utánzására nagyon keveset változtat. A csomagok továbbra is ugyanazon a fizikai kapcsolaton, ugyanazon a switch-porton és általában ugyanazon a tűzfalláncon mennek ki, így nem keletkezik közöttük új határ. Ez konfigurációs kényelem, nem szegmentálás. Ha zónahatárként kezeled, az elkülönítési állítás csak papíron marad meg.

Egy külön zónához valódi elkülönülés kell az útvonalon, és ezt a követelményt egy második adapter teljesíti. Ha egy szabály attól függ, hogy a VPN felé menő forgalom soha nem osztja meg a broadcast tartományt a LAN felé menő forgalommal, egyetlen kábel nem tudja ezt a tulajdonságot nyújtani, akárhogyan is van címezve a gép.

Ahol egy termék egy adott módhoz többinterfészes topológiát dokumentál, ott kövesd a termék dokumentációját, ne találj ki kerülőutat. A gyártók kiadásról kiadásra változtatják a támogatott topológiákat is, ami szintén ok arra, hogy a jelenlegi útmutatót olvasd, ne egy régi varázsló képernyőképét.

Ellenőrizd az elrendezést az engedélyezett forgalomhoz

Sorolj fel minden forgalmi osztályt, amelyet a kiszolgálónak vinnie kell: ügyféltől a gépig, ügyféltől a LAN-ig, géptől a LAN-ig, valamint a titkosított külső kapcsolat. Mindegyiknek van forrása, célja és interfésze, és az elrendezésnek mind a négyet egyszerre kell teljesítenie. Az a terv, amely hármat kezel, általában az, amely jegyeket termel.

Ezután a valós interfészeket és a valós rögzítést erősítsd meg, ne a tervezési dokumentum ábráját. Az alábbi parancsok mindkét nézetet kiírják.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Ha a külső rögzítés a titkosított forgalmat mutatja, a belső rögzítés pedig a visszafejtett forgalmat az alagút interfészen, miközben a fizikai adapter mindkettőt viszi, akkor egy hálókártya végzi a munkát. Ha a belső rögzítés üres, a probléma az alagútban vagy a továbbítási szabályokban van, nem az adapterek számában. A topológiát abból a két rögzítésből és az útválasztási táblából döntsd el, és a következő változásnak lesz mihez mérnie magát.

Kapcsolódó cikkek