Valaki olyan szolgáltatást kér, amelyet csak VPN-felhasználók érhetnek el, és a kézenfekvő megvalósítás a kilépőcímek listájának engedélyezése. A lista valami valósat tesz: korlátozza, ki csatlakozhat. Nem bizonyítja, hogy alagutat használtak, mert a cím ahhoz tartozik, aki a kilépést üzemelteti, és az az üzemeltető bárki forgalmát továbbíthatja. E két állítás közötti rés maga a teljes tervezési probléma.

A szerver kapcsolatonként egy címet lát

Egy kapcsolat forrás címmel és célporttal érkezik, és a hálózati réteg ennyit jelent. Amikor egy kliens alagutat használ, a figyelőjéhez érkező csomagok a kilépésből vagy az előtte lévő fordításból jönnek. A kliens saját címe, általában privát, soha nem jelenik meg. Ezért a kliens helyi hálózati tartományára írt tűzfalszabály semmit sem tesz.

Minden, ami e forráscím után következik, alkalmazásadat, és az alkalmazás csak annyira bízhat benne, amennyire hitelesíti.

Tesztelje, hogyan néz ki a kilépése

Nézze meg az útvonalat mindkét végéről, mielőtt szabályt ír. A kliens kilépéséről alkotott képe és a szerver kapcsolatról alkotott képe az a két tény, amely számít.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Az első parancs a nyilvános címet jelenti, amelyen a kliens megjelenik, és ez az az érték, amelyet minden engedélyezési listának tartalmaznia kell. A második a szerveren létesített kapcsolatokat mutatja partnereik címeivel, és a szabály valójában ezekkel fog egyezni. Ha a kettő nem egyezik a mentális modelljével, javítsa a modellt, mielőtt szerkeszti a szabályzatot. Egy felhőadatbázis tűzfala, egy alkalmazás engedélyezési listája és egy terheléselosztó egyaránt más fordítási réteget láthat.

A két kilépési halmaz közül csak az egyik listázható

Az egyik eset a kérés pillanatában ellenőrizhető, a másik nem, ami nagyon különböző garanciákat eredményez.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

A közzétett Tor-kilépési lista letölthető és összehasonlítható, a lista korától és az egyes kilépések saját szabályzatától függően, így az ismert kilépések elleni elutasítási szabály kikényszeríthető és felülvizsgálható. A kereskedelmi VPN-ekhez nincs egyenértékű nyilvántartás. A címek cserélődnek, sok szolgáltató semmit nem tesz közzé, és egy alagút bérelt felhőcímen futhat, amely soha nem tartozott VPN-hez. Az Ön által összeállított lista a megfigyelt címek pillanatképe, és a tárhelytartományokra való kiterjesztése kapcsolódó terheléseket ad hozzá bizonyíték nélkül.

Használja a címeket szabályzati bemenetként, ne bizonyítékként

Döntse el, mire való a szabály. A hálózati korlátozás maradjon szűk, rögzítse a megfigyelt címet a dátumával és okával, és adjon a jogszerű felhasználóknak helyreállítási utat, amikor a kilépésük megváltozik. A hozzáférés-vezérléshez hitelesített fiók vagy aláírt token kell, mert csak ezek kötik a kérést identitáshoz. A kockázatpontozás egyetlen megbízhatatlan jelként használhatja a címet, elfogadva téves riasztásait és vakfoltjait. A szabályt termékdöntésként megírni őszinte; alagút létezésének ellenőrzéseként megírni nem az.

A tükörkérés, a felhasználó valódi címének visszanyerése VPN mögül, ugyanezen okból hiúsul meg: egy kapcsolat egy címet hordoz, és a munkamenetek közötti változás több magyarázattal is összeegyeztethető. Kezelje a korábbi értéket történetként, nem igazságként.

Kapcsolódó cikkek