Dva VPN skoky na jednom Pi: ktorá trasa nesie ktorého partnera

Dve adresy tunela na jednej malej doske vyzerajú ako chyba a reflex je jednu vymazať. Ten reflex rozbíja to, čo mal upratať. Hostiteľ s dvoma skokmi drží jednu adresu na každé pripojenie a každú adresu vyberá iná trasa. Otázka, ktorú stojí za to si položiť, je, ktorá trasa vyberá ktorého nositeľa pre ktoré cieľové miesto, nie koľko adries existuje.

Tri cieľové miesta, ktoré potrebujú rôznych nositeľov

Reťaz dvoch skokov sú tri triedy cieľových miest poskladané na sebe a každú nesie iné pripojenie. Vonkajší partner musí byť dosiahnutý cez fyzické spojenie. Vnútorný partner musí byť dosiahnutý cez vonkajší tunel. Cieľové miesto pokrytej aplikácie musí byť dosiahnuté cez vnútorný tunel, ktorého vlastný transport nesie ten vonkajší.

Vyplňte riadky skutočnými adresami čitateľa, skôr než sa dotknete trasy, pretože tabuľka je užitočná len vtedy, keď je konkrétna. Fungujúca reťaz spĺňa všetky štyri riadky súčasne a polofunkčná zvyčajne spĺňa jeden z nich s nesprávnym nositeľom. Práve čítanie nesprávneho riadku ako závady mení problém smerovania na celé popoludnie úprav.

Adresy majú roly, nie počet

Linux dovoľuje niekoľko adries na jednom rozhraní a niekoľko tunelov na jednom hostiteľovi, takže počet nič nehovorí o správnosti. Záleží na tom, ktorá adresa patrí ktorému pripojeniu a či trasa pre daného partnera vyberá pripojenie, ktoré ste mysleli. Tri pohľady na to odpovedajú z troch smerov a stojí za to ich čítať vždy v rovnakom poradí.

Inventár adries ukazuje, čo existuje a ktoré pripojenie to vlastní. Tabuľka trás odpovedá na otázku nositeľa pre bežnú premávku k cieľovým miestam. Pohľad pravidiel na ňu odpovedá znova pre premávku vybranú zdrojom alebo značkou, čo je obvyklé usporiadanie, keď dvaja klienti zdieľajú jedného hostiteľa.

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

Vymazanie adresy preto, že zoznam vyzerá dlhý, môže odstrániť časť cesty, a vymazanie trasy preto, že vyzerá nadbytočná, robí to isté tichšie. Ani jedno nehlási chybu; partner jednoducho prestane odpovedať na ceste, ktorú ste zamýšľali, zatiaľ čo zostáva dosiahnuteľný inou. Aplikácia, ktorá hlási výstupnú adresu vnútorného partnera, nepreukazuje, že premávka prešla vonkajším tunelom, pretože priamy prístup dáva rovnaké pozorovanie. Práve táto medzera medzi pozorovaním a dôkazom je dôvod, prečo sa nositeľ kontroluje na vrstve smerovania.

Poradie aktivácie poráža pevné čakanie

Ak vnútorný klient závisí od adresy alebo trasy, ktorú dodáva vonkajší klient, aktivácia musí čakať na tento zdroj, nie na oneskorenie. Čakanie funguje do dňa, keď je vonkajší tunel pomalý, a potom zlyháva občas spôsobom, ktorý nikto nedokáže zopakovať. Poradie založené na závislostiach odstraňuje hádanie a nestojí nič okrem jedného opisu závislosti. Ani názvy rozhraní nie sú mechanizmom poradia.

Jadro prideľuje názvy ako tun0 a tun1 v poradí vytvorenia a toto poradie sa môže medzi reštartmi alebo opätovnými pripojeniami zmeniť. Zviažte konfiguráciu s identitou, ktorú poskytuje nástroj, alebo s názvom, ktorý vedome priradíte. Názov, ktorý si vyberiete, je zmluva; názov, ktorý vyberie jadro, je náhoda.

Držte transport každého klienta mimo aplikačnej trasy toho druhého a buďte presní v tom, čo možnosti smerovania OpenVPN 2.6 skutočne sľubujú. Dokumentovaný mechanizmus predvoleného presmerovania udržiava klienta schopného dosiahnuť svojho vzdialeného partnera cez bránu, ktorá už existovala, čo prerušuje jednu konkrétnu rekurzívnu slučku. Nerobí z jedného klienta nositeľa druhého, takže zvyšok reťaze zostáva váš návrh. Kde reťaz potrebuje pravidlo namiesto trasy, napíšte výslovné pravidlo zdroja alebo značky a otestujte ho premávkou, ktorej má zodpovedať.

Čo sa stane, keď zomrie vonkajší skok

Skôr než sa reťaz bude považovať za dokončenú, rozhodnite, čo sa stane, keď vonkajší skok zmizne. Transport vnútorného klienta s ním umiera a ďalší krok je otázka pravidiel, nie techniky: zlyhať, skúsiť znova alebo sa pripojiť priamo cez fyzické spojenie. Práve tretí výsledok stojí za zamyslenie. Potichu mení návrh s dvoma skokmi na návrh s jedným skokom v okamihu, keď používateľ verí, že pokrytie je stále nedotknuté.

Ak sú dva skoky povinné, vnútorný klient nesmie byť schopný vytvoriť priamu cestu, keď vonkajší zmizne, a spôsob, ako to zistiť, je prerušiť vonkajší skok a sledovať, čo robí vnútorný. Schválená záloha je legitímna odpoveď, ale musí byť napísaná, otestovaná a oznámená. Záloha, ktorú nikto nedokumentoval, je pri revízii incidentu nerozoznateľná od úniku.

DNS a druhá rodina adries patria k rovnakému rozhodnutiu. Lokálne generovaná požiadavka sa riadi vlastnými pravidlami hostiteľa, nie pravidlami preposlaného klienta, takže resolver, ktorý funguje pre preposlanú premávku, nemusí byť ten, ktorý používa sám hostiteľ.

Prijmite každú vrstvu v poradí, v akom ste ju stavali

Testujte v poradí, v akom bola reťaz postavená: najprv samotný vonkajší tunel, potom transport vnútorného klienta cez vonkajší tunel, potom aplikáciu cez vnútorný tunel. Každé prijatie musí byť nové spojenie, nie stránka, ktorá už bola otvorená. Potom každú vrstvu zvlášť prerušte a obnovte a sledujte, čo robí tá nasledujúca.

Výsledok zálohy je tu najcennejšie pozorovanie a to, ktoré stránka s verejnou IP nikdy neukáže. Uložte cesty partnerov, adresy, ktoré používajú, a tento výsledok vedľa konfigurácie, pretože šťastná cesta nie je tá časť, na ktorú sa neskôr pýtame.