Két VPN-ugrás egy Pi-n: melyik útvonal melyik partnert viszi

Két alagútcím egy kicsi lapon hibának tűnik, és a reflex az, hogy töröljünk egyet. Ez a reflex elrontja azt, amit rendbe kellett volna tennie. A két ugrást hordozó gazdagép csatlakozásonként egy címet tart, és minden címet más útvonal választ ki. Az a kérdés, amelyet érdemes feltenni, hogy melyik útvonal melyik hordozót választja melyik célállomáshoz, nem az, hogy hány cím létezik.

Három célállomás, amelyek különböző hordozókat igényelnek

A két ugrásból álló lánc három egymásra rakott célosztály, és mindegyiket más csatlakozás hordozza. A külső partnert a fizikai kapcsolaton keresztül kell elérni. A belső partnert a külső alagúton keresztül kell elérni. A lefedett alkalmazás célállomását a belső alagúton keresztül kell elérni, amelynek saját átvitelét a külső hordozza.

Töltse ki a sorokat az olvasó valódi címeivel, mielőtt bármelyik útvonalhoz nyúl, mert a táblázat csak akkor hasznos, ha konkrét. Egy működő lánc mind a négy sort egyszerre teljesíti, egy félig működő pedig általában egyet közülük a rossz hordozóval. Éppen a rossz sor hibaként olvasása az, ami egy útválasztási problémát egy egész délutáni szerkesztéssé változtat.

A címeknek szerepük van, nem számuk

A Linux több címet engedélyez egy interfészen és több alagutat egy gazdagépen, ezért egy szám semmit sem mond a helyességről. Az számít, hogy melyik cím melyik csatlakozáshoz tartozik, és hogy egy adott partner útvonala a szándékolt csatlakozást választja-e. Három nézet válaszol erre három irányból, és érdemes minden alkalommal ugyanabban a sorrendben olvasni őket.

A címleltár megmutatja, mi létezik, és melyik csatlakozás birtokolja. Az útvonaltábla megválaszolja a hordozó kérdését a szokásos célforgalom esetében. A házirend-nézet újra megválaszolja a forrás vagy jelölés szerint kiválasztott forgalom esetében, ami a szokásos elrendezés, amikor két ügyfél osztozik egy gazdagépen.

ip -4 addr show
ip -4 route show table all
ip rule show

Egy cím törlése, mert a lista hosszúnak tűnik, eltávolíthatja az útvonal egy részét, és egy útvonal törlése, mert feleslegesnek tűnik, ugyanezt teszi halkabban. Egyik sem ad hibát; a partner egyszerűen abbahagyja a válaszadást azon az útvonalon, amelyet szándékolt, miközben egy másikon elérhető marad. Egy alkalmazás, amely a belső partner kilépési címét jelenti, nem bizonyítja, hogy a forgalom átkelt a külső alagúton, mert a közvetlen hozzáférés ugyanazt a megfigyelést adja. Éppen ez a rés a megfigyelés és a bizonyíték között az oka annak, hogy a hordozót az útválasztási rétegen ellenőrzik.

Az aktiválási sorrend legyőzi a rögzített várakozást

Ha a belső ügyfél olyan címre vagy útvonalra támaszkodik, amelyet a külső ügyfél biztosít, az aktiválásnak arra az erőforrásra kell várnia, nem késleltetésre. A várakozás addig működik, amíg el nem jön a nap, amikor a külső alagút lassú, és akkor időszakosan olyan módon hibázik, amelyet senki sem tud reprodukálni. A függőségeken alapuló sorrend megszünteti a találgatást, és semmibe sem kerül azon kívül, hogy egyszer leírjuk a függőséget. Az interfésznevek sem sorrendezési mechanizmusok.

A kernel olyan neveket oszt ki, mint tun0 és tun1, létrehozási sorrendben, és ez a sorrend újraindítások vagy újracsatlakozások között változhat. Kösse a konfigurációt az eszköz által biztosított identitáshoz, vagy egy szándékosan kiosztott névhez. A név, amelyet Ön választ, szerződés; a név, amelyet a kernel választ, véletlen.

Tartsa minden ügyfél átvitelét a másik alkalmazás-útvonalán kívül, és legyen pontos abban, mit ígérnek valójában az OpenVPN 2.6 útválasztási beállításai. A dokumentált alapértelmezett átirányítási mechanizmus lehetővé teszi az ügyfél számára, hogy saját távoli partnerét a már létező átjárón keresztül érje el, ami egy konkrét rekurziós hurkot vág át. Nem teszi az egyik ügyfelet a másik hordozójává, ezért a lánc többi része továbbra is az Ön terve. Ahol a láncnak útvonal helyett házirendre van szüksége, írjon explicit forrás- vagy jelölési szabályt, és tesztelje azzal a forgalommal, amelyhez illeszkednie kell.

Mi történik, amikor a külső ugrás meghal

Mielőtt a lánc teljesnek számítana, döntse el, mi történik, amikor a külső ugrás eltűnik. A belső ügyfél átvitele vele együtt meghal, és a következő lépés házirend-kérdés, nem technikai: meghibásodás, újrapróbálás vagy közvetlen újracsatlakozás a fizikai kapcsolaton keresztül. Éppen a harmadik kimenetel az, amelyen érdemes elgondolkodni. Csendben kétugrásos tervből egyugrásos tervvé változtatja a dolgot abban a pillanatban, amikor a felhasználó úgy hiszi, a lefedettség még érintetlen.

Ha két ugrás kötelező, a belső ügyfélnek nem szabad közvetlen utat létesítenie, amikor a külső eltűnt, és ennek megállapítására a külső ugrást kell elrontani, és figyelni, mit tesz a belső. A jóváhagyott tartalék legitim válasz, de le kell írni, tesztelni kell és közölni kell. Egy tartalék, amelyet senki sem dokumentált, egy incidens áttekintésekor megkülönböztethetetlen egy szivárgástól.

A DNS és a másik címcsalád ugyanahhoz a döntéshez tartozik. A helyben generált lekérdezés a gazdagép saját házirendjét követi, nem egy továbbított ügyfélét, ezért előfordulhat, hogy a továbbított forgalomhoz működő feloldó nem az, amelyet maga a gazdagép használ.

Fogadja el az egyes rétegeket abban a sorrendben, ahogy építette őket

Teszteljen abban a sorrendben, ahogy a lánc épült: először a külső alagút egyedül, aztán a belső ügyfél átvitele a külső alagúton keresztül, aztán az alkalmazás a belső alagúton keresztül. Minden elfogadásnak friss kapcsolatnak kell lennie, nem egy már nyitott oldalnak. Aztán törje meg és állítsa helyre külön-külön az egyes rétegeket, és figyelje, mit tesz a következő.

A tartalék eredménye itt a legértékesebb megfigyelés, és az, amelyet egy nyilvános IP-oldal soha nem mutat. Mentse el a partnerek útvonalait, az általuk használt címeket és ezt az eredményt a konfiguráció mellé, mert a boldog út nem az a rész, amelyet később megkérdőjeleznek.