Egy LAN-címmel rendelkező VPN-kliens nincs a LAN-on

A kliens csatlakozik, megkapja a 10.50.0.200-at, és nem éri el a szervert a 10.50.0.20-on, pedig mindkét szám ugyanabban a /24-ben van. A konfiguráció mögötti hit az, hogy a LAN-előtagból származó cím a klienst a LAN részévé teszi. Nem teszi. A kliens pont-pont linken van, a szerver helyinek hiszi a célt, és a hiányzó darab egy szomszédválasz, amelyet senki nem küld.

A mítosz: ugyanaz az előtag ugyanazt a szegmenst jelenti

Egy cím-előtag megmondja a gazdagépnek, mely célokat érheti el közvetlenül, és melyekhez kell router. Azt nem mondja meg, hogyan van a cél fizikailag csatlakoztatva, és azt sem garantálja, hogy a cél képes válaszolni egy linkréteg-beli kérésre. Ezek különböző kérdések, amelyekre különböző táblák válaszolnak a gazdagépen. A maszk az elsőre válaszol, a szomszédtábla a másodikra, és csak az első van a te ellenőrzésed alatt a VPN oldaláról.

Amikor a szerver a 10.50.0.200-ra küld, összehasonlítja a célt a saját maszkjával, on-linknek dönti a címet, és megkérdezi a helyi szegmenstől a hozzá tartozó hardvercímet. Ez a kérés az Ethernet-interfészen megy ki, és a VPN-kliens nincs ott, hogy hallja.

A kliens konfigurációjában semmi nem tudja ezt a saját oldaláról rendbe tenni. A válasz útja attól függ, hogy egy LAN-on lévő eszköz a kliens nevében válaszol-e, vagy hogy a kliensnek olyan címe van-e, amelyet a szerver nem tekint helyinek.

Mit tesz valójában a helyi gazdagép a címmel

A viselkedés könnyen megfigyelhető, és érdemes is megfigyelni, mielőtt bármit változtatsz. Nézd meg a LAN-gazdagép szomszédtábláját, miután megpróbálta elérni a klienst: egy hiányos vagy sikertelen bejegyzés az egész diagnózis egy sorban. Az a sor azt is megmondja, hogy a hiba a szegmenshez helyi, és nem valahol a tunelen belül.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Az útvonalkeresés on-linknek jelenti a célt az Ethernet-interfészen, és pont ez a probléma. Ha a szomszédbejegyzés hiányos marad, amíg a VPN-munkamenet fut, megerősítetted, hogy a hiányzó elem a linkrétegű feloldás, nem az útválasztás vagy a tűzfal-szabályzat.

Futtasd ugyanezt az ellenőrzést egy másik alhálózat gazdagépéről, és hasonlítsd össze. Az a gazdagép, amely routeren keresztül éri el a klienst, egyáltalán nem igényel szomszédbejegyzést, és ez a különbség a tervezési döntés kicsiben.

Hogyan ad a proxy ARP következő ugrást

A proxy ARP arra készteti az átjárót, hogy egy olyan cél nevében válaszoljon a linkréteg-kérésre, amelyet egy másik interfészen ér el. A LAN-gazdagép hardvercímet kap, elküldi a keretet az átjárónak, az átjáró pedig továbbítja a csomagot a VPN-munkamenetbe. A gazdagép szemszögéből a kliens egyszerűen az átjáró mögött látszik. A kliens konfigurációjában semmi nem változik.

A MikroTik RouterOS ARP-dokumentációja leírja ezt a használatot azoknak a betárcsázós klienseknek, amelyek a csatlakoztatott LAN címterét kölcsönzik. A mechanizmus a szomszédfeloldás javítása, és azért működik, mert az átjáró valóban mindkét úton ott van.

Ez nem ugyanaz, mint a klienst a LAN-ba hidat építeni. Az átjárónak továbbra is a megfelelő aktív munkamenetbe kell továbbítania a csomagot, és az útválasztásának és tűzfalszabályzatának továbbra is engedélyeznie kell a szolgáltatást. A proxy ARP azt változtatja meg, ki válaszol a szomszédkérésre, nem azt, ki beszélhet.

Olvasd figyelmesen a platform módneveit. A RouterOS megkülönbözteti a proxy-arp és a local-proxy-arp módot, és a második az ugyanazon az interfészen be- és kilépő forgalmat kezeli. Ezek nem felcserélhető írásmódok, és mindkettőt válogatás nélkül bekapcsolni nem rövidítés.

Amit a proxy ARP nem ad meg

Nem biztosít broadcast- vagy multicast-felderítést. Egy kliens, amelynek broadcast útján kell szolgáltatást találnia, továbbra is elbukik, mert az átjáró unicastot továbbít a munkamenetbe, és nem teszi a klienst a LAN broadcast-tartományának tagjává. A broadcastra támaszkodó felderítési protokollok gyakori forrásai azoknak a jelentéseknek, hogy az egyik dologra működik, a másikra nem, a kölcsönzött című tervekben.

Nem foglalja le a címet. Ha a kölcsönzött szám egy DHCP-poolban vagy statikus hozzárendelésben is szerepel, két eszköz ugyanarra a címre juthat, és a következményes viselkedés az időzítéstől függ. A sikeres bejelentkezés nem foglalás.

És nem szünteti meg a LAN tulajdonosával való egyeztetés szükségességét. Egy proxy ARP-bejegyzés, amely meglepi a címterv tulajdonosát, egy nyugodt hétre váró támogatási eset.

Összehasonlítás külön útválasztott pool-lal

Az alternatíva az, hogy a VPN-kliensek saját előtagot kapnak, és a LAN-gazdagépek oda irányítanak. Ekkor a szerver off-link válaszokat küld az átjárójának, az átjáró az előtagot a VPN-végponthoz irányítja, és a LAN-szegmensen egyáltalán nincs szükség szomszédfeloldásra. Ez kevesebb mozgó alkatrész, mint egy kölcsönzött cím plusz egy proxy-válasz.

Ezt a tervet könnyebb végiggondolni és könnyebb auditálni, mert a kliens tartomány láthatóan elkülönül a LAN tartományától. Egy útvonalba, egy visszaútba és egy hozzáférési szabályba kerül, ugyanazokba, amelyekre a proxy ARP-s tervnek egy kevésbé nyilvánvaló helyen van szüksége.

Válassz a modellek között szándékosan, és ne véletlenül. A proxy ARP egy konkrét kapcsolatot javít meg; az útválasztott pool elkerüli ennek a javításnak a szükségességét. Írd le, melyiket választottad és miért, és a következő embernek nem kell újra felfedeznie egy sikertelen szomszédbejegyzésből.