Két átjáró, egy VPN: miért választja az OpenVPN a rossz kimenő kapcsolatot

Két kimenő kapcsolat, egy alagút, és a forgalom azon megy ki, amelyiket nem választotta. A privát alhálózatok elérhetők, a napló sikeres kapcsolatot jelez, és éppen a mért kapcsolat az, amely hordozza. Az OpenVPN kimenetében semmi sem említ átjárót, mert a kliens soha nem választott egyet sem. Egy socketet nyitott egy távoli címre, és a kernelre bízta, hogyan érje el azt a címet.

Az alagút címe nem a végpont

Minden munkamenetben két különböző útvonal létezik. A külső útvonal a titkosított forgalmat a szerver nyilvános címére viszi. A belső útvonal mindent visz, amit a szerver az alagútba tol, és az egyik útvonal-szabályai nincsenek hatással a másikra.

A profil remote bejegyzése a külső célállomást nevezi meg, tehát azt a címet kell rögzíteni. Ez az az érték is, amely megváltozik, amikor egy gazdagépnév másként oldódik fel, vagy a profil több remote-ot sorol fel.

Keresse meg a címet, amelyet a kliens valóban tárcsázott

Az élő socketet olvassa, ne a konfigurációs fájlt. A socket-tábla mutatja azt a partnert, amelyhez a folyamat valóban csatlakozott, és a kivételnek ehhez az értékhez kell illeszkednie. A profil a munkamenet kezdete után szerkeszthető, és a socket az egyetlen bizonyíték arra, mit tárcsázott:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

A naplósor a kapcsolat idején megnevezi a partner címét és portját. Ha ez eltér a profiltól, valami a kliens előtt átírja a célállomást, mielőtt a kapcsolat elindul.

Ellenőrizze a címcsaládot is. A kettős verem profil IPv6-on kapcsolódhat, miközben a kivétele csak IPv4-et fed le, és akkor a forgalom más szabályt követ, mint amelyet írt. Ugyanez vonatkozik arra a proxyra, amely a végpont nevében válaszol. Mindkét eset olyan alagutat eredményez, amely működik, miközben az útvonala semmit sem tesz.

Rögzítse a végpontot, és olvassa el a házirend sorrendjét

A gazdagép-útvonal konkrétabb minden alapértelmezett útvonalnál. Ezért a partner címére vonatkozó /32 nyer az azt tartalmazó táblában. A szokásos forma kifejezetten megnevezi az átjárót és az eszközt:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Az az útvonal csak akkor segít, ha a keresés eléri azt a táblát. A házirend-szabályok sorrendben értékelődnek ki, és az első egyezés dönt, ezért egy szabály, amely mindent egy második táblába küld, megkerüli a gazdagép-útvonalát a main táblában. Olvassa el a szabályokat, mielőtt feltételezné, hogy az útvonal mérvadó:

ip rule show
ip route get 203.0.113.40

Kérdezze meg a második parancsot ugyanazzal a forrás-címmel vagy jelöléssel, amelyet a kliens használ, amikor a házirend ezektől függ. Azt az útvonalat jelenti, amelyet a kernel választana, ami a keresésre vonatkozó bizonyíték, és nem bizonyíték arra, hogy az élő socket ezt az utat használja.

Amikor a végpont elmozdul

Egy gazdagépnév, amely több címre oldódik fel, érvényteleníti az állandó /32-t, amint a válasz megváltozik. A több remote-sorral rendelkező profilnak ugyanez a problémája, mert a kliens bármelyikre leszállhat. Frissítse az útvonalat a kliens saját életciklus-horgaiból, ahelyett hogy kézzel adná hozzá. Egy up szkript, amely beolvassa a tárgyalt partnert, és telepíti a gazdagép-útvonalat, összhangban tartja a kivételt a valósággal, és egy megfelelő down szkript eltávolítja.

A frissítést ugyanott rögzítse, ahol a gazdagép többi útvonal-konfigurációja van. Az az útvonal, amely csak a következő újraindításig létezik, teszt, nem javítás.

Tartsa külön a belső házirendet

A külső útvonal áthelyezése nem ad hozzáférést új privát alhálózathoz, és nem változtatja meg, mely célállomásokat tol a szerver az alagútba. Az alsó réteg útvonala választja a vezetéket; a betolt útvonalak választják meg, mi lép be az alagútba. E két döntés különválasztása teszi kiszámíthatóvá a felosztást.

Ha a cél csak az, hogy a titkosított forgalom távol maradjon egy mért kapcsolattól, hagyja békén az alapértelmezett útvonalat, és adja hozzá az egyetlen gazdagép-kivételt. A gép szintű alapértelmezett útvonal lecserélése egyetlen VPN-kapcsolat áthelyezéséhez minden más alkalmazást elront a gazdagépen.

Két független megfigyeléssel erősítse meg az eredményt: a socket helyi címével és eszközével, valamint azzal az útvonallal, amelyre a privát célállomás feloldódik. Amikor mindkettő megfelel a szándékának, a felosztás valódi. Az OpenVPN 2.6 kézikönyv lefedi a remote és helyi kötés beállításait, amelyek eldöntik, melyik címet tárcsázza a kliens.