OpenVPN: a helyi cím és az alagút címének különbsége – két különböző socket

A kliens nem indul el, és arra panaszkodik, hogy nem tud helyi címet kötni, és a kézenfekvő javítás annak tűnik, hogy arra az alagútcímre irányítsuk, amelyet várni fog. Ez nem működhet, és az okot érdemes megérteni: mielőtt az alagút létezik, nincs belső cím, és annak a socketnek, amely kapcsolatba lép a szerverrel, előbb léteznie kell. Két különböző cím van a játékban, és közülük csak az egyik választható helyben.

A kötési hiba egy helyi címet nevez meg

Amikor az OpenVPN azt jelzi, hogy nem tud helyi címet kötni, a szállítási socketről beszél: arról az UDP- vagy TCP-végpontról, amely a titkosított kapcsolatot a peerhez viszi.

Egy kifejezett local direktíva arra kéri a daemont, hogy azt a socketet egy adott helyi címhez kösse. A címnek abban a hálózati névtérben kell léteznie, ahol a folyamat fut, és abban a pillanatban hozzárendelhetőnek kell lennie, amikor a kliens elindul.

A routeren vagy a felhő szélén lefordított nyilvános cím nem helyi cím, amelyet a daemon köthet, még akkor sem, ha a szerver ezt a címet látja. Ez a különbség magyarázza, hogy egy profil otthon működik, felhőpéldányon pedig elbukik. Azt is magyarázza, miért nem segít a nyilvános cím hozzáadása egy loopback-interfészhez, hiszen akkor a szállítás olyan címről indulna, amelyre a hálózat nem tud válaszolni. A profil szerkesztése előtt olvasd el az interfészek listáját.

Mit választ valójában a local és a remote

remote a kapcsolatba lépni kívánt peert nevezi meg. local ugyanazon socket közeli végét köti. nobind az operációs rendszerre bízza mind a helyi cím, mind a port kiválasztását, ezért az otthoni routerek mögötti kliensek általában mindkét direktíva nélkül működnek.

Egyik direktívának sincs köze az alagúton belüli címhez.

Konténerben vagy hálózati névtérben ugyanez a szabály érvényes szűkebb határokkal: a gazdagép címei belül nincsenek jelen, ezért a gazdagép konfigurációjából másolt local sor teljesen más okból bukik el, mint egy hibás cím.

ip -brief address show
ip route get 203.0.113.10

A belső cím a szervertől jön

Az alagúton belüli címet a vezérlőcsatorna létrejötte után tárgyalják meg vagy osztják ki. Dinamikus poolnál a szerver dönt erről csatlakozáskor, kliensspecifikus konfigurációnál pedig identitásonként rögzített lehet.

A local belső címmel való beírása nem kéri a szervert, hogy ossza ki azt a címet. A legjobb esetben a kötés elbukik; a legrosszabb esetben a kliens talál egy azonos értékű, nem kapcsolódó gazdagép-címet, és elkezdi használni a szállításhoz.

A beolvasandó interfészek is mások. A ifconfig paraméterei és a pool konfigurációja a belsőt írják le, míg a remote, local, proto és nobind a külsőt. A két lista szétválasztása szinte minden zavarba ejtő példát megmagyaráz, amit fórumon találsz. Az OpenVPN 2.6 kézikönyv ezért dokumentálja őket külön szakaszokban.

A csapda: egy teljes alagút, amely elfogja a saját szállítását

Miután az alagút feláll és viszi az alapértelmezett útvonalat, az őt fenntartó csomagokat nem szabad beleirányítani. Ez útvonalválasztási, nem címzési probléma, és a daemon úgy oldja meg, hogy konkrétabb útvonalat telepít a szerver saját címéhez az eredeti átjárón keresztül.

Ha a szállítást egy adott helyi címhez rögzíted, majd később megváltoztatod az útvonalat, amelyet ez a cím használ, a külső kapcsolat eltévedhet, miközben a belső konfigurált marad. Az alagút továbbra is csatlakozottnak jelentkezik, mert a belső rendben van. Csak a szállítás tört el, és ezért olvashatók a naplók ellentmondásként.

A tünetek ekkor olyan alagútra hasonlítanak, amely csatlakozik és lefagy, vagy olyanra, amely hasznos hiba nélkül újracsatlakozik egy hurokban. Ellenőrizd a peer címéhez vezető útvonalat, mielőtt bármit ellenőriznél az alagúton belül, és erősítsd meg, hogy a kötött helyi cím még mindig a várt interfészhez tartozik.

Egy szokás, amely megelőzi a zavart

Olvasd el a profil minden címét, és szerkesztés előtt döntsd el, melyik réteghez tartozik.

Ha a szállítás távoli végét nevezi meg, vagy annak közeli végét köti, akkor külső cím, és az indítás előtt léteznie kell. Ha azt írja le, ami az alagúton belül történik, akkor a szervertől vagy a topológiától származik, és semmilyen helyi direktíva nem helyettesítheti.

Írd be a két listát a profil melletti telepítési jegyzetekbe. A következő hibaelhárítási munkamenet akkor a réteggel kezdődik, nem találgatással.