Statikus OpenVPN-ügyfélcímek az OPNsense mögött

A neveknek nem mozduló címekre van szükségük, és az OpenVPN poolfájlja csak ragadóssá tesz egy címet. Veszítse el azt a fájlt, vagy adjon ki újra egy tanúsítványt más köznévvel, és a visszatérő ügyfél a pool más helyére kerül, miközben a DNS-rekordja továbbra is a régi címre mutat. A tartós válasz egy ügyfélspecifikus felülbírálás, amely a címhez szögezi, plusz egy szélesebb tunnelhálózat, hogy a rögzített címek a dinamikus tartományon kívül legyenek. A szélesítés mögötti aritmetika az, ahol a zavar nagy része lakik.

Az OPNsense ezeket a felülbírálásokat a kiszolgáló ügyfélspecifikus beállításaiban tartja, a tanúsítvány köznevével kulcsolva, ami a köznevet a címterv részévé teszi.

A ragadós bérlet nem statikus cím

A poolfájl cím–ügyfél leképezéseket ír, és visszaadja őket, amikor egy ismert ügyfél újra csatlakozik. Ez kényelem, nem szerződés: a fájl újragenerálható, a leképezés eltűnik, amikor az ügyfél identitása megváltozik, és két poolt megosztó kiszolgáló nem fog egyetérteni benne. Az ügyfélspecifikus felülbírálás másképp működik, mert a cím a konfigurációból jön, nem az előzményekből. Túléli az újraindítást és a készülék újratelepítését is, feltéve, hogy a felülbírálás a konfiguráció többi részével együtt biztonsági mentésbe kerül.

A dinamikus alternatíva, a VPN DNS-be kötése ügyfélcsatlakozási szkripttel és dinamikus frissítésekkel, működik, és olyan feloldót igényel, amely elfogadja a frissítéseket, plusz minden csatlakozáskor egy szkriptet. Készüléken a gyártó által szállított csomagokra van korlátozva, és általában itt áll meg ez a terv.

A /30-as aritmetika, amelyet senki sem szeret

Az alapértelmezett net30 topológiában minden ügyfél a saját /30-át kapja: az első használható cím a kiszolgáló oldalára kerül, a második az ügyfélhez. A felülbírálásoknak ezért a kiszolgáló dinamikus tunnelhálózatán kívül kell lenniük, ami azt jelenti, hogy először ki kell szélesíteni azt a hálózatot. Egy 10.8.0.0/24-en álló kiszolgáló átmehet 10.8.0.0/23-ra, meghagyva a régi tartomány felét a dinamikus ügyfeleknek és a másik felét a felülbírálásoknak. Adja hozzá az eredeti /24-et további helyi IPv4-hálózatként, hogy a forgalom mindkét fél felé a tunnelbe menjen.

Minden felülbírálási címnek /30-os határra kell esnie, tehát az utolsó oktett négy többszöröse. A 10.8.1.0-n lévő /30 a 10.8.1.2-t adja az ügyfélnek, és ezt a címet hordozza a DNS-rekord. Ha helyette a 10.8.1.3-t választja, olyan ügyfelet kap, amely csatlakozik, de nem tud forgalmat átvinni, mert a cím olyan alhálózathoz tartozik, amelyet a topológia soha nem osztott ki neki.

A tervet könnyebb tartani, ha a felülbírálásokat a szélesített tartomány tetejétől lefelé osztják ki, így a dinamikus pool a szabad térbe terjeszkedik, nem pedig rögzített szigetek körül.

Helyi hálózatok és a zóna, amelyet az ügyfelek kérdeznek

Az ügyfél-ügyfél forgalomnak saját engedélyre van szüksége. A kiszolgáló helyi IPv4-hálózatainak listájának tartalmaznia kell a tartomány mindkét felét, a dinamikust és a statikust; enélkül a kiszolgáló elfogad egy csomagot az egyik ügyféltől, és nincs szabálya, amely átengedné a másikhoz. A tünet DNS-hibának tűnik, mert a név feloldódik, és a kapcsolat mégis megszakad. Ellenőrizze ugyanakkor az ügyfél-ügyfél beállítást is, mert egy helyi hálózati bejegyzés önmagában nem teszi lehetővé a továbbítást a partnerek között.

Tegye közzé a rekordokat abban a zónában, amelyet a távoli ügyfelek ténylegesen kérdeznek. Egy olyan zónában lévő rekord, amelyet csak a LAN-feloldó szolgál ki, láthatatlan annak az ügyfélnek, amelynek tolt feloldója máshova mutat, és a rossz zónába tett további rekordok soha nem javítják meg. Erősítse meg a tolt DNS-beállítást és a keresési tartományt mielőtt bármit hozzáadna.

Mit ellenőrizzünk egy új kapcsolatnál

Csatlakoztassa újra az ügyfelet, és erősítse meg, hogy a kiosztott cím megfelel a felülbírálásának, mielőtt bármi mást tesztelne. Ezután oldja fel a nevet egy második ügyfélről, és csatlakozzon a szolgáltatáshoz név szerint, ami együtt próbálja a DNS-rekordot, az útvonalat és a tűzfalat. Erősítse meg a válaszútvonalat a kiszolgáló oldalán, mert egy név, amely feloldódik, miközben a szolgáltatás elérhetetlen marad, útvonal- vagy házirendprobléma, nem névprobléma. Tartsa a felülbírálási táblázatot a tanúsítványlista mellett, hogy mindkettőt együtt nézzék át.

Egy más köznévvel újra kiadott tanúsítvány többé nem illik a felülbírálásához, és visszaküldi az ügyfelet a dinamikus poolba. Számítson erre minden identitásváltozás után.