Az OpenVPN-ügyfél lefagy, amikor a kiszolgálója ugyanazon a gazdagépen fut

Volt egy laboratóriumi gépem, amely egy távoli helyről fogadott alagutat, és közben egy szállító hálózatába is tárcsázott. A kimenő profil hetekig működött. Miután hozzáadtam a bejövő kiszolgálót, a kimenő csatlakozott, majd másodperceken belül abbahagyta a forgalom továbbítását, vagy megtagadta az indulást egy cím-már-használatban hibával. A konfigurációs fájlok nem változtak; a gazdagép egyszerűen kapott egy második OpenVPN-folyamatot, amelynek saját véleménye volt a portokról és az útvonalakról.

A hiba nem véletlenszerű, és nem hitelesítési probléma. Két démon egy gépen ugyanazért a helyi socketért és ugyanazért az útválasztási tábláért verseng, és általában az nyer, amelyik utoljára indul vagy kapcsolódik újra. Ha tudja, melyik a két ütközés közül, az meghatározza, hol nézzen először.

Olvassa visszafelé a tünetet

Kezdje azzal, mikor hal meg az alagút. Az induláskori bind-hiba a figyelő oldalra mutat: valami már birtokolja azt a portot, és az OpenVPN inkább nem indul el, mint hogy megossza. Az az alagút, amely feljön, majd elhallgat, az útválasztásra mutat, mert a másik példány által telepített útvonal eltérítheti a külső kapcsolat csomagjait az útvonalukról.

Mindkét eset ugyanazt a felhasználói panaszt eredményezi, ezért az újrapróbálkozási hurkok és a watchdog-szkriptek semmit sem javítanak. Visszakapcsolják az ügyfelet ugyanabba az ütközésbe. Az első hasznos kérdés, hogy a folyamat még fut-e, amikor a forgalom megáll.

Egy socket és egy eszköz példányonként

A figyelő kiszolgáló hozzáköti a portját; a kimenő ügyfélnek szintén szüksége van helyi portra a beágyazott forgalmához. Amikor mindkettő ugyanazon a gazdagépen él, az ügyfél alapértelmezett viselkedése ütközhet a kiszolgáló portjával. Az ügyfél helyi portja rögzíthető, és a hozzákötés kihagyható ott, ahol a partnernek nincs szüksége fix forrásportra:

lport 1195
nobind
dev tun1

Ezek a számok példák, nem követelmények. Az a fontos, hogy az ügyfél felhagyjon a kiszolgáló portjáért való versengéssel, és minden példány külön alagúteszközt kapjon. Két démon, amely megosztja a tun0 eszközt, felülírja egymás eszközállapotát akkor is, ha a portjaik eltérnek, tehát az alagútonkénti egy eszköz nem választható.

nobind az ügyféloldalhoz tartozik. A kiszolgálónak továbbra is kötnie kell és figyelnie, ezért ne másolja a sort a kiszolgáló konfigurációjába, és ne kapcsolja ki a hozzákötést olyan ügyfélen, amelynek partnere fix forrásportra szűr.

Válasszon egy tulajdonost az alapértelmezett útvonalhoz

Csak egy kapcsolat telepíthet alapértelmezett útvonalat. Ha mindkét profil minden forgalmat átirányít, a második kapcsolat csendben lecseréli az elsőt, és az első megszakadtnak tűnik. Vagy tartsa felosztva a kimenő alagutat, és csak a szállító előtagjait tolja, vagy adjon neki külön útválasztási táblát.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

A fenti címek és a táblaszám helyőrzők. A szabály hozzáadása után azonnal erősítse meg, hogy a VPN-kiszolgáló saját címe még mindig a normál táblán keresztül oldódik fel; az a tábla, amely elkapja a külső szállítást, eltöri az alagutat, amelyet védenie kellett volna, és az ezt követő újracsatlakozási hurok megbízhatatlan szolgáltatónak látszik.

Olyan beállításhoz, amelynek túl kell élnie az újracsatlakozásokat és újraindításokat, a hálózati névtér a szilárdabb határ. A második ügyfél a saját névterében fut a saját interfészeivel és útvonalaival, és csak azok a szolgáltatások vannak kitéve, amelyeknek át kell lépniük. A gazdagép egy alapértelmezett útvonalat tart, és egy névtér-újracsatlakozás nem írhatja felül.

A táblával ellenőrizze, ne az állapotsorral

Az az ügyfél, amely azt jelenti, hogy csatlakozott, csak a vezérlőcsatornáját bizonyítja. Rögzítse az útválasztási állapotot minden kapcsolat előtt és után, majd kérdezze meg a kernelt, melyik eszközt használná egy valódi cél:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Ha a szállító címéhez kiválasztott eszköz megváltozik, amikor a második alagút elindul, akkor útvonal-ütközése van. Ha mindkét folyamat ugyanazon a helyi porton jelenik meg, akkor socket-ütközése van. Az első javítása a második nélkül csak a következő újracsatlakozásra tolja a hibát.

Írja be a portokat, eszközöket, táblákat és az útvonal tulajdonosát a gazdagép runbookjába. Különben a következő ember, aki harmadik alagutat ad hozzá, újra felfedezi ugyanazt az ütközést, és az egyetlen látható bizonyíték egy kapcsolat lesz, amely addig működik, amíg valaki más démonja újra nem indul.