Készen áll a WireGuard a termelésre? A válasz nem a protokollban van

Az emberek azt kérdezik, készen áll-e a WireGuard a termelésre, ami kriptográfiai kérdésnek hangzik, és valójában a környezetedről szóló kérdés. A protokollt évek óta vizsgálják; az üzembe helyezésnek még mindig meg kell válaszolnia, hogy a hálózataid hordozzák-e a szállítását, ki vesz fel és von ki eszközöket, és ki javítja a csomagot mindkét végén. Ezek a válaszok különböznek egy rackben álló két szerver és ezer laptop esetében. A protokoll mindkét esetben ugyanaz; a műveletek nem.

A kérdés a kérdés mögött

Amit az emberek általában tudni akarnak, az az, hogy elköteleződhetnek-e egy olyan tervezés mellett, amely fél év múlva nem hozza őket kínos helyzetbe. Ez egy négyrészes üzembe helyezési kérdés, és minden rész a többitől függetlenül meghiúsulhat. Három jó megválaszolása nem pótolja a negyediket.

Egy régi figyelmeztetés egy kiadás előtti pillanatképről arról a pillanatképről szóló tény, nem állandó címke minden későbbi csomagon. Ugyanígy egyetlen blogbejegyzés sem nyilváníthatja késznek a te konkrét kernel-, kliens-, hálózat- és személyzetkombinációdat. A munka az, hogy a kombinációt kimondottá tedd és ellenőrizd.

Kezeld a felkészültséget kapuk halmazaként, amelyeken vagy átmész, vagy nyitottként rögzítesz. Ez a vitát felelősökkel ellátott ellenőrzőlistává alakítja. Az is láthatóvá teszi a nyitott tételeket annak, aki jóváhagyja, ahelyett hogy egy kísérleti jelentésbe temetné.

Első kapu: az útvonalnak UDP-t kell szállítania

A WireGuard UDP-n szállítja a forgalmát, és dokumentálja, hogy nem nyújt TCP-módot vagy forgalom-álcázást. Az a tervezés, amely arra épül, hogy közönséges webes forgalomnak látsszon, vagy a port módosítására TCP-viselkedésért, olyan feltevésre épül, amelyet a szoftver nem támogat.

Tehát az első kapu egy felmérés, nem egyetlen gépen végzett teszt. Sorold fel azokat a hozzáférési környezeteket, amelyekben a felhasználóid valóban dolgoznak, majd ellenőrizd a jóváhagyott UDP-útvonalat mindegyikben, és döntsd el, mi történik, ha nem elérhető.

Az irodából működő kapcsolat semmit sem bizonyít egy szállodai hálózatról, egy campus tűzfalról vagy egy mobilszolgáltatóról, amely másképp kezeli az UDP-t. Ezek a környezetek az okai annak, hogy a távoli hozzáférés üzembe helyezései sikeres kísérlet után elbuknak. A kísérlet nem volt hibás; szűk volt. Kiszélesítése maga a kapu.

Írd le a tartalék útvonalat is. Ha a válasz az, hogy nincs tartalék, az olyan döntés, amelyet érdemes előre kimondani, ahelyett hogy egy üzleti úton derülne ki.

Második kapu: valakinek birtokolnia kell a kulcsokat

A WireGuard partnerei kulcsokkal hitelesítik magukat, résztvevőnként egy párral. Ezt könnyű leírni és üzemeltetésileg igényes, mert a protokollban semmi nem vesz fel eszközt, nem követi, kinél melyik kulcs van, és nem vonja meg a hozzáférést, ha egy laptop elveszik. A protokoll feltételezi, hogy a kulcsok már helyesek, a helyesség pedig valakinek a munkája.

Nevezd meg azt, aki eszközt vesz fel, a rekordot, amely egy nyilvános kulcsot személyhez és eszközhöz rendel, és az eltávolítás eljárását. Ha az eltávolítás attól függ, hogy emlékszel-e, hova telepítettek konfigurációsfájl-másolatokat, az eljárás nincs kész.

Válassz egy eszközt a kísérlet során, és vond ki a használatból elejétől végéig. Ez a gyakorlat hasznosabb információt ad, mint egy újabb kapcsolódási teszt, mert feltárja a nyilvántartásaid hiányosságait.

Harmadik kapu: a csomagnak karbantartó kell

A WireGuard érkezhet kernelbeli implementációként, disztribúciós csomagként vagy felhasználói térben futó kliensként, és mindegyiknek saját frissítési útvonala van. Az üzemeltetési kérdés az, melyiket futtatod, honnan jött és ki alkalmaz egy biztonsági értesítést.

WireGuardot használunk nem leltár. Nem azonosítja a javítandó csomagot, az átjárón lévő verziót vagy azt a személyt, aki vissza tudja vonni a rossz frissítést.

Negyedik kapu: a munkaterhelést fogadd el, ne a kézfogást

Az elfogadási kritériumoknak azt kell leírniuk, mit tesznek a felhasználók. Egy belső alkalmazás elérése, a privát nevének feloldása, az elutasítás egy nem engedélyezett célon és a meghatározott viselkedés követése, amikor az alagút áll — mind megfigyelhető, és egy sikeres kézfogás egyik sem ezek közül.

Futtasd ezeket az ellenőrzéseket hálózatváltáson, eszköz-újraindításon és az átjáró karbantartási ablakán keresztül, mert ezekben az átmenetekben törik el az üzembe helyezés.

Tartsd a bizonyítékokat a kritériumok mellett, beleértve azt a helyi állapotot, amely létrehozta őket:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

A zöld teszt egy csendes hálózaton egyetlen laptoppal kezdeti megfigyelés. Nem állítás a megbízhatóságról, és annak kezelése, mintha az lenne, az az út, amelyen egy működő tervezésből megbízható tervezés lesz.