A távoli felhasználók nem érik el a második telephelyet a VPN-központon keresztül

Egy távoli felhasználó csatlakozik a központhoz, eléri a fájlszervert a központ saját LAN-ján, és minden egészségesnek tűnik. Aztán megnyit egy megosztást a 10.20.0.50 címen a központi irodában, ahová a központ egy külön telephelyek közötti alagúton ér el, és az időtúllépésbe fut. Mindkét alagút fent van, és mindkét számláló nő, tehát egyik alagút sem hibás. A központon átjutni három útválasztási döntés három eszközön, és az alagút csak azokat a prefixeket szállítja, amelyekre épült. Ez a sorrend, amit ellenőrzök, és a parancs, amely megmutatja, hogy igaz-e minden lépés.

Az átvezetés három keresést igényel, nem egy alagutat

Minden eszköz a saját leghosszabb-prefix egyezését végzi, és elfelejti. A laptopnak a 10.20.0.50-et az alagútba kell küldenie, nem a helyi routerére. A központnak át kell vennie egy csomagot, amely a távoli hozzáférés interfészén érkezett, és át kell adnia a telephelyek közötti interfésznek. A központi irodának választ kell küldenie a felhasználó címére az alagúton keresztül. Ha bármelyik elbukik a három közül, az a böngészőben ugyanúgy látszik: csend.

Ezért bizonyít olyan keveset az egyes alagutak külön tesztelése. A központ LAN-címének pingelése az első döntést gyakorolja, a központ pingelése a központi irodából a harmadikat. A sikertelen csomag forrása a felhasználói pool, célja a második telephely, ezért először írja fel ezeket a prefixeket. Itt a pool 10.80.0.0/24, a központ LAN-ja 10.10.0.0/24, a központi iroda pedig 10.20.0.0/24.

Tolja ki a távoli prefixet a távoli ügyfélnek

Egy OpenVPN távoli hozzáférési szerveren az ügyfél csatlakozáskor tanulja az útvonalakat. Push nélkül a megosztott alagutat használó ügyfél a 10.20.0.50-et a saját átjárójának küldi, és a csomag soha nem kerül be az alagútba.

push "route 10.20.0.0 255.255.255.0"

A pusholt útvonal az ügyfél csatlakozásakor lép életbe, így az online maradó felhasználó semmit nem lát, amíg újra nem csatlakozik. Ellenőrizze az ügyfélen: ip route get 10.20.0.50 Linuxon, route print Windowson. A kimenetnek meg kell neveznie az alagút interfészét.

A push nem segít a központnak. Ez egy üzenet az ügyfélnek, nem útvonal a szerveren és nem továbbítási engedély, így a tökéletes push-sorral rendelkező központ egy ugrással később mégis elejti a folyamot. Ez a szokásos ok, amiért az emberek arra jutnak, hogy a push elbukott.

Adjon a központnak valódi kimenő útvonalat

A központnak saját következő ugrásra van szüksége a központi iroda prefixéhez. Egy útválasztott alagúton ez egy közönséges útvonal a telephelyek közötti interfészen, és egyetlen parancs megmutatja a választott útvonalat és a választott forrást is:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Ha a telephelyek közötti szakasz maga OpenVPN, az útvonal abban a konfigurációban élhet, a partner alagútcímével átjáróként: route 10.20.0.0 255.255.255.0 172.30.0.2. Az átjáró nem opcionális. Ha kihagyja, a következő ugrás egy implementációs alapértékre esik, amely eltér az egy partneres ügyfél és a több partneres központ között.

A házirend-alapú IPsec más: a központ magja a csomagot a szokásos LAN-átjárójának küldi, és a házirend elkapja kifelé menet, így az alagút-útvonal vagy semmit nem tesz, vagy a házirend mellett vezeti el a forgalmat. Figyelje a forrást a fenti parancsban, mert a 10.10.0.1 a pool címe helyett azt jelenti, hogy a mag olyan címet választott, amelyet a túloldal el fog utasítani. iroute sem a válasz; megmondja a szervernek, melyik ügyfél birtokol egy alhálózatot a saját alagútja mögött, nem azt, hogy hová küldje a harmadik telephely forgalmát.

Terjessze ki a túloldalt a felhasználói poolra

A központi iroda már lefedi a központ LAN-ját, 10.10.0.0/24. A felhasználói pool egy második prefix, és a szelektorokban is szerepelnie kell, különben egyetlen házirend sem fedi le a 10.80.0.25-re címzett választ. Minden partner ugyanazt a prefixkészlet-párt nevezi meg a saját oldaláról:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Az egyik eszköz local_ts-e a másik remote_ts-e. Másolja a központ blokkját a központi irodára, és a pár megfordul, így a child SA soha nem jön fel.

A régebbi ipsec.conf szintaxis vesszővel elválasztott leftsubnet használ. A futó biztonsági asszociáció megtartja a tárgyalt szelektorokat, ezért a szerkesztés után építse újra az alagutat. A 10:00-kor módosított szelektor, amelyet egy 09:40-kor feljött SA ellen tesztelnek, továbbra is elbukik, miközben a konfigurációs fájl végig helyesnek látszik.

Aztán ellenőrizze az utolsó ugrást. ip route get 10.80.0.25 a távoli végponton az alagútba kell mutatnia. Ha a szolgáltatás LAN-routert használ alapértelmezett átjáróként, annak a routernek is kell a visszaútvonal, különben a válasz ott meghal. A tcpdump -ni eth1 host 10.80.0.25 futtatása azon a szegmensen megmutatja, elhagyta-e a válasz egyáltalán a végpontot.

Engedélyezze a folyamot a központon

A továbbításnak engedélyezettnek és az útnak engedettnek kell lennie. Szűkítse a szabályokat a két prefixre, ahelyett hogy mindent elfogadna az interfészek között.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

A fordított útvonal szűrése a mellette lévő csendes hiba: ha a két szár különböző interfészeken van, rp_filter=1 eldobhatja a választ, miközben az elfogadási szabály számlálója soha nem mozdul. Hasonlítsa össze a iptables -vnL FORWARD egy kísérlet előtt és után. Egy soha nem növekvő szabályt nem ér el a forgalom, ezért nézzen egy réteggel lejjebb, ahelyett hogy átírná.

Ha csak egy csoportnak van szüksége átvezetésre, tegye az útvonalat ügyfelenkénti fájlba a client-config-dir alá, ahelyett hogy kiszélesítené a globális pusht. A központon a forrás-NAT szintén megszünteti a túloldali visszaútvonal szükségét, de elrejti a felhasználó címét, így a túloldali naplók és a címalapú szabályok többé nem különböztetik meg a felhasználókat.

Ellenőrizze az ügyfélről, majd vonja vissza fordított sorrendben

Teszteljen TCP-portot, ne csak ICMP-t, mert a ping átmehet, miközben a szolgáltatás blokkolt marad. nc -vz 10.20.0.50 445 és traceroute -n 10.20.0.50 az ügyfélről megmutatja, hogy a második ugrás a központ alagútcíme-e. A központon a tcpdump -ni tun0 host 10.20.0.50 és ugyanaz a szűrő a telephelyek közötti interfészen: kérés mindkettőn, válasz egyiken sem, ami a problémát a túloldalra mozgatja.

Aztán teszteljen valamit, aminek blokkolva kell maradnia. Ha egy olyan gazdagép is válaszol, amelyet a pool soha nem érhetne el, többet nyitott meg az átvezetésnél, és szűkítenie kellene a szabályokat. Az a központ, amely mindent minden ágnak továbbít, átmegy az első teszten és elbukik a másodikon.

Vezessen visszaállítási listát, mert négy objektum változott, és hármat könnyű elfelejteni: a pusholt útvonal, a központ útvonala, a szelektorok és a tűzfal szabályai. Fordított sorrendben vonja vissza őket, építse újra az SA-t, és hagyja, hogy egy felhasználó újracsatlakozzon. A részleges visszaállítás olyan útvonalat hagy, amely már nem illeszkedő alagútra mutat, ami nehezebben olvasható, mint az eredeti csend. A OpenVPN 2.6 kézikönyv dokumentálja a push, route és iroute parancsot az Ön verziójához.