Elérhetik egymást a kliensek két OpenVPN-kiszolgálón?

Egy második OpenVPN kiszolgáló felállítása második helyet ad a kliensek csatlakozására, és semmi többet. Nem teszi ezeket a klienseket az első kiszolgáló hálózatára, és a client-to-client nevű beállítás csak egyetlen kiszolgálófolyamaton belül változtatja a továbbítást. A két csoport akkor válik egy hálózattá, amikor szándékosan irányít közöttük, minden irányhoz felelőssel. Az alábbiak mindegyike felhasználói térben futó TUN módot feltételez, kikapcsolt belső továbbítással, így a döntést a kernel hozza.

A mítosz: egy fióklista, egy hálózat

A hitelesítés és az elérhetőség összemosódik, mert mindkettő a kiszolgáló konfigurációjában él. Az a felhasználó, aki bármelyik átjáróba be tud jelentkezni, kívülről úgy tűnik, mint egy kétszárnyú ajtós rendszer felhasználója. Belül mindegyik kiszolgáló a saját csoportjából oszt címeket, és csak az általa lezárt kliensekhez telepít útvonalakat. Így az A átjárón lévő kliens, amely a B átjárón lévő kliensnek küld csomagot, olyan célt kér, amelyről a saját kiszolgálója soha nem hallott. A csomag az A alapértelmezett útvonalára megy, elhagyja az alagutat, és olyan tűzfalhoz érkezik, amelyet soha nem kértek meg, hogy engedje át.

Egy második kiszolgáló hozzáadása tehát nem ad redundanciát, felderítést vagy közös broadcast-tartományt. Hozzáad egy irányított hálózatot, amelyhez terv kell, és a terv a címzéssel kezdődik.

Adjon minden átjárónak saját csoportot és tranzitcímet

Két tartomány, amely nem fedhet át semmi mással, plusz egy kis tranzitkapcsolat a gazdagépek között – ez a teljes címterv. Tartsa a tranzitot az Ön által ellenőrzött privát szegmensen, és írja le a számokat, mielőtt bármelyik kiszolgáló bérletet adna.

Ellenálljon a kísértésnek, hogy mindkét kiszolgáló ugyanazt a csoportot kapja, hogy a profilok azonosak maradjanak. A kernel útvonala nem tudja megmondani, hogy a két gazdagép közül melyik birtokol éppen egy tetszőleges címet egy megosztott tartományon belül, így az útválasztási tábla az egyik átjáróra mutatna, a kliens pedig a másikhoz lehet csatlakozva. Az interfésznevek helyi konvenciók, nem megosztott állapot. Mindkét gazdagép itt tun0-nek nevezi az alagút-eszközt és transit0-nek a tranzitkapcsolatot, ami rendben van, mert egyetlen csomag sem hordozza ezeket a neveket.

Telepítse az útvonalat mindkét oldalon

Mindegyik átjárónak kell egy útvonal a másik csoportjához a tranzitcímen keresztül, és a továbbításnak be kell lennie ahhoz, hogy bármelyik ugrásként működjön. Először erősítse meg a jelenlegi táblát, majd adja hozzá a bejegyzést, és tegye tartóssá a gazdagép hálózatkezelőjén keresztül, ne egy újracsatlakozási horoggal.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Tükrözze ezt a másik gazdagépen felcserélt csoportokkal. Ugyanazon útvonal ismételt hozzáadása egy nem kapcsolódó szkriptből az, ahogy egy gazdagép több példányhoz és rejtélyes változáshoz jut, amikor legközelebb valaki olvassa a táblát. Ha a tranzitkapcsolat maga alagút, az útvonal annak topológiájára mutat, és az ugrásnak túl kell élnie az újracsatlakozását. Egy harminc másodpercig eltűnő tranzitcím magával viszi a csoportok közötti utat, ami olyan tervezési tulajdonság, amelyet érdemes kijelenteni, nem felfedezni.

Tolja ki a kliens útvonalát tulajdon hamisítása nélkül

A klienseknek útvonal kell a távoli csoporthoz, különben a saját operációs rendszerük az alapértelmezett átjárójukra küldi a csomagot, és az alagút soha nem látja. A kiszolgáló konfigurációja a természetes hely ennek kiszolgálására.

push "route 10.64.20.0 255.255.255.0"

Tegye a tükörsort a másik kiszolgáló konfigurációjába, majd csatlakoztassa újra a tesztklienst, és olvassa el a tábláját. Az olyan kliensnek, amely figyelmen kívül hagyja a kitolt útvonalakat, saját jóváhagyott konfigurációra van szüksége, és az az útvonal, amely soha nem érkezik meg, nem hozzáférés-vezérlés. Ne adjon a kliensnek iroute-ot a másik átjáró teljes csoportjára. Az az utasítás egy csatlakozott kliens mögötti alhálózatra való, és a hiányzó átjárók közötti útvonal elfedésére használva olyan kiszolgálót hoz létre, amely azt hiszi, hogy olyan címeket birtokol, amelyeket nem ér el.

Bizonyítson egy kérést, és utasítson el egy másikat

Válasszon valódi műveletet, például HTTPS-t egy 10.64.10.21-en lévő klienstől a 10.64.20.37-en lévő szolgáltatás felé, és pontosan ezt engedje mindkét gazdagépen. Mindegyik tűzfal a bejövő oldalán fogadja a kérést, a visszatérő oldalán a követett választ; a cél saját szolgáltatáspolitikájának még el kell fogadnia.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Kölcsönös útvonalak esetén a forrás NAT szükségtelen, és itt aktívan káros: a forrás fordításával elrejti, melyik kliens küldte a kérést, és aláássa a forrásalapú szabályzatot a cél oldalán. Ellenőrizze, hogy az internetes kimenet meglévő masquerade-szabálya nem fogja-e meg ezt az utat is. Aztán tesztelje az elutasítást. A B csoportban helyben maradó szolgáltatásnak elérhetetlennek kell maradnia az A csoportból, és az azonos átjárón lévő klienspárokat is tesztelni kell, mivel az imént módosított továbbítási szabályzat rájuk is vonatkozik.

Még egy korrekció a mentális modellben: a tranzitkapcsolat visszafejtett belső csomagokat szállít, tehát bizalmi határ, nem magángarancia. Ha olyan hálózaton halad át, amelyet nem ellenőriz, védje azt az ugrást jóváhagyott titkosított alagúttal, és annak valódi topológiáján irányítson. A végpontok közötti TLS továbbra is maga hitelesíti az alkalmazást, ezért a belső szolgáltatásnak továbbra is ezt kell használnia.