pfSense VPN-kiszolgálóként és -kliensként: két út, egy router

Egy eszköz egyszerre két irányba nézhet: a barangoló felhasználók befelé kapcsolódnak, és ugyanaz a doboz kifelé kapcsolódik egy kilépőszolgáltatóhoz, hogy a kiválasztott forgalom más hálózaton keresztül távozzon. Mindkét szolgáltatás bekapcsolása percekig tart; az együttélésükhöz tervezés kell, mert a második szerep átírja azt az útvonaltáblát, amelyre az első támaszkodik. Három feltétel dönti el, hogy a felállás működik-e, nevezetesen hogy a bejövő szolgáltatás megtartja-e a saját visszaútját, hogy a kimenő alagút még eléri-e a partnerét, és hogy a továbbítani kívánt forgalom kiválasztódik-e a kilépésre. Ha egyet elront, két alagutat kap, amelyek mindkettő kapcsolódást jelent, miközben semmi hasznos nem megy át közöttük. Az alábbi ellenőrzések minden feltételt abban a sorrendben állítanak fel, ahogy a hibák általában megjelenni szoktak.

Nevezze meg a két szerepet, mielőtt bármelyik beállításhoz nyúl

Írjon le négy tényt minden példányhoz: a távoli partnerét, a hitelesítési anyagát, a kiosztott címkészletet és a mögötte lévő hálózatokat. A két példány külön objektum az eszközön, és a jegyzeteiben is külön kell maradniuk. Szinte minden későbbi zavaró tünet az értékeik összekeveréséből származik, és az, hogy két példány egy jegyzetkészletet oszt meg, az az út, amelyen a rossz készlet a rossz mezőbe kerül.

A bejövő szolgáltatásnak olyan alagúthálózat kell, amely nem fedi át a kimenő alagút címeit és egyetlen olyan magánhálózatot sem, amelyet az eszköz routol. Az átfedés az egyetlen hiba, amely egyszerre okoz tüneteket mindkét szerepben, és papíron sokkal olcsóbb elkapni. Hasonlítsa össze mindkét készletet és minden routolt magánhálózatot egy helyen, mielőtt bármelyik szolgáltatást beállítaná.

A közös hardver nem jelent közös hitelesítő adatokat, és a távoli hozzáférés készletéből származó ügyféltanúsítvány nem lehet használható a kilépőszolgáltatóval szemben. A külön anyag a visszavonást is helyi döntéssé teszi a teljes flottát érintő esemény helyett.

Tartsa a kiszolgáló válaszait a WAN-útvonalon

Az eszköz által maga előállított válaszok a gondatlan alapértelmezett útvonal első áldozatai. Amikor egy barangoló felhasználó beágyazott csomagja megérkezik, a válasz helyben keletkezett forgalom, és azon a felületen kell távoznia, amelyen az a felhasználó bejött. Ha a kimenő kliens olyan alapértelmezett útvonalat telepített, amely elkapja, a válasz a rossz alagútba kerül, és a munkamenet megakad, miközben a szolgáltatás még mindig egészségesnek látszik.

Nincs egyetlen jelölőnégyzet, amely ezt eldöntené, mert a döntés arról szól, milyen forgalmat foghat el a kimenő kliens. Vagy nem húz be semmilyen útvonalat, és csak azt irányítja, amit kiválaszt, vagy behúzza az útvonalakat, és hozzáadja azokat a kivételeket, amelyek az eszköz saját szolgáltatásait működésben tartják. Írja le a választást a példány mellé, különben a következő ember a másikat feltételezi.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Az útvonaltáblát a leghosszabb egyezés szerint olvassa, nem aszerint a sorrend szerint, ahogy bármit beállított. A kérdés az, melyik bejegyzés nyer a kilépő partner címére, és melyik a bejövő szolgáltatás válaszára, és ez a két válasz eltérhet.

Ne hagyja, hogy a kimenő alagút megegye a saját végpontját

A kimenő kliensnek el kell érnie partnere nyilvános címét ahhoz, hogy egyáltalán felépítse az alagutat. Ha ez a cím maga is az alagútba van routolva, a kliens a saját farkát kergeti: az átvitel soha nem jön fel, vagy feljön, majd elesik abban a pillanatban, amikor az útvonal telepítődik. A napló hitelesítési időtúllépésnek látszik, nem routolási hibának, ezért az útvonal érdemel első ellenőrzést.

Ellenőrizze az útvonalat a hitelesítő adatok előtt, és újra, miután az alagút felállt, mert egy bejegyzés induláskor helyes és egy perccel később hibás lehet. A partner címének a szokásos WAN-útvonalra kell mutatnia, soha nem az alagúteszközre. Amint az átvitel stabil, az érdekes kérdés a továbbított forgalomra tevődik át, ami a következő döntés.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Válassza ki, mely felhasználók kapják a kilépést

A forrásszabályzat ahhoz a belépéshez tartozik, ahol a forgalom az eszközre érkezik, tehát a távoli hozzáférés készletét vagy azon belül szűkebb identitásokat válasszon. Őrizze meg azokat a magáncélokat és kezelési kivételeket, amelyeket soha nem szabad a kilépésre küldeni, és ezeket a szabályokat a széles elé tegye. A kilépési útvonalnak aztán saját fordításra vagy routolt visszatérési elrendezésre van szüksége, ami a legtöbb tervezésnél a kilépési felületen a készletet lefedő kimenő NAT-ot jelent. A fordítás nem választ kilépést; csak azt írja át, ami már elment, ezért egy NAT-szabály egy nem érintett WAN-on semmit sem változtat a kiválasztáson.

Erősítse meg, hogy a távoli oldal engedi az ebből a tervezésből továbbított forgalmat, mert egyes szolgáltatók engedik, mások nem. A különbség olyan alagútként látszik, amely kapcsolódik és semmit nem szállít, amit könnyű helyi hibaként olvasni. Tesztelje a három folyamot külön, mert egymástól függetlenül hibáznak, és háromból kettő félig felépített tervezés.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Az első parancs a barangoló felhasználó külső kapcsolata, és akkor működik, amikor a kliens jelenti, hogy az inicializálási sorozat befejeződött. A második, arról a csatlakoztatott laptopról futtatva, a kilépőszolgáltató címét jelenti a WAN-címe helyett. A harmadik az eszközön fut, a készlet egyik címéhez kötve, és a továbbított forgalom forrásszabályzatát teszteli anélkül, hogy egyáltalán bevonna távoli felhasználót. Ha helyette a WAN felől válaszol, a szabályzat nem illett, és semmilyen NAT-szerkesztés nem javít egy kiválasztási problémát.

Döntse el, mi történik, ha a kilépés meghibásodik

Írja le a hiba viselkedését, mielőtt megtörténik: amikor a kimenő alagút leesik, a felhasználók visszaesnek a szokásos WAN-ra, vagy blokkolva vannak, amíg a kilépés vissza nem tér? Mindkét válasz védhető, és az eszköz nem választ Ön helyett. Egy eltávolított útvonal vagy egy halott átjáróra mutató szabályzat nem eredményez automatikusan teljes blokkolást. Ha blokkolást szeretne, a szabályzatnak ezt kifejezetten ki kell mondania, és a kilépés elvételével kell tesztelni, nem pedig elmélkedni róla. Ha visszaesést szeretne, hirdesse meg a felhasználóknak, mert a csendben a szokásos utat választó forgalom éppen az a forgalom, amelyet valaki lefedettnek hitt.

Kapcsolja ki az ügyfélpéldányt, nézze meg, mit ér még el egy csatlakozott felhasználó, majd indítsa újra. Az az időtúllépésbe futó kérés az Ön által kért teljes blokkolás eredménye; az, amelyik a WAN-címmel válaszol, az a visszaesés, amelyet nem dokumentált. Ismételje meg az ellenőrzést IPv6-ra és DNS-re, mert az IPv4-re írt szabályzat semmit nem mond az AAAA-forgalomról, és a bármelyik alagút által áttolt feloldó onnan válaszol, ahonnan a lekérdezés valójában kilép.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

A Netgate routolt OpenVPN-receptje megmutatja, hogyan illeszkedik össze a forrásszabályzat, a felület-hozzárendelés és a kimenő fordítás, és a telephelyek közötti hatóköre az a rész, amelyet nem szabad egészében másolni. Amit viszont nem mond el, az az, hogy a fenti három feltétel közül melyiket törte már meg a saját tervezése.