Szabályalapú útválasztás kontra SOCKS: melyik réteg proxizza valójában a forgalmat

Hozzáadott egy szabályalapú útvonalat, amely egy VPN-kliens forgalmát olyan hosztra küldi, ahol SOCKS-hallgató fut az 1080-as porton. A csomagok megérkeznek, a hallgató semmit nem naplóz, és a kapcsolat lóg. Az útvonallal nincs semmi baj: a következő ugrás kiválasztja, hova megy egy csomag, a SOCKS pedig olyan beszélgetés, amelyet a kliensnek kell kezdeményeznie. Hasonlítsa össze a három architektúrát, amelyekre az emberek általában gondolnak, amikor forgalmat küldenek proxyn keresztül, és kiderül, melyik darab hiányzik a beállításából.

Az útválasztás, a DNAT és a SOCKS különböző dolgokat változtat meg

A szabályalapú útvonal átír egy L3-as döntést. Két sor elég ahhoz, hogy egy kliens forgalmát a kiválasztott következő ugrásra küldje:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Ezután a kernel átadja a csomagot a 10.50.0.2 címnek, miközben az eredeti cél még mindig az IP-fejlécben van. Ha a 10.50.0.2 egy router, továbbítja a csomagot. Ha egy hoszt SOCKS-démonnal az 1080-on, a csomag nincs olyan címre címezve, amely elfogadhatná, és a DNAT az 1080-as portra sem segít, mert az átalakított csomag továbbra is az eredeti alkalmazásterhelést hordozza SOCKS-köszöntés helyett.

SOCKS5 egy verzióbájttal, metóduslistával, hitelesítési cserével és a célt megnevező kéréssel kezdődik. Ezek alkalmazásadatok. Sem útválasztási bejegyzés, sem netfilter-cél nem állítja elő őket, és ez az összehasonlítás egy sorban: az útválasztás utat választ, a SOCKS megkéri a szervert, hogy hozzon létre egy második kapcsolatot.

Első eset: az alkalmazás maga is tud SOCKS-t beszélni

Ha a programnak van proxybeállítása, ez a legrövidebb út, és nem igényel kernelmódosítást. Irányítsa a hallgatóra, adjon meg hitelesítő adatokat, ha a szerver kéri, és döntse el, hogy a nevek helyben oldódnak-e fel vagy a proxyhoz kerülnek. A curl esetében ezek különböző kapcsolók, és a különbség akkor számít, amikor a cél csak a proxy oldaláról oldódik fel:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Azokat az alkalmazásokat, amelyek figyelmen kívül hagyják a proxy környezeti változóit, vagy nyers socketeket nyitnak, így nem lehet megsegíteni. A böngészők és a legtöbb HTTP-eszköz rendben van; egy játék-kliens, egy levéldémon vagy egy tetszőleges gyártói bináris általában nem. A határ alkalmazásonként és protokollonként húzódik, ezért ez a lehetőség kiváló tesztelésre és gyenge válasz a teljes VPN-re.

Második eset: egy adapter, amely IP-folyamokat alakít proxy-munkamenetekké

Azoknál a programoknál, amelyek nem tudnak SOCKS-t beszélni, az átalakításnak olyan valamiben kell történnie, ami lezárja az IP-forgalmat, és a nevükben proxy-munkameneteket nyit. Ez a komponens egy alagút-interfésszel rendelkezik, elfogadja a szabályalapú útválasztás által kiválasztott folyamokat, elvégzi mindegyiknél a SOCKS-kézfogást, és újraépíti a válaszokat. Az útvonal ráirányítja a forgalmat; az adapter az, ami létrehozza a munkamenetet.

Olvassa el a dokumentációját, mielőtt egy egész alhálózatot rábíz. Sok adapter jól viszi a TCP-t, és az UDP-t csak SOCKS5 UDP-asszociáción keresztül kezeli, és egyik sem alakítja az ICMP-t proxy-forgalommá, így egy sikeres ping semmit nem mond a proxy útvonaláról. A DNS a másik csapda: ha az adapter helyben oldja fel a neveket, a csak belső rekordok rossz válaszra oldódnak fel, vagy semmire.

A hurkok megelőzése az az üzemeltetési részlet, amely harap. Az adapter saját kapcsolatait a SOCKS-szerverhez nem szabad visszairányítani az adapterbe, ezért a forgalmának kivétel kell a szabályban, vagy külön forrás-cím. Ha ezt elrontja, a proxy-munkamenet megpróbálja önmagát proxizni.

Harmadik eset: a hoszt valójában útválasztott átjáró

Néha a működő beállítás egyáltalán nem tartalmaz SOCKS-t. A távoli hoszt továbbítja a csomagokat, vagy NAT-ot végez rajtuk, a forrásalapú szabály pedig egyszerűen kiválasztja kijáratként. Ez a kialakítás legitim, és megmagyarázza, miért működik egy másolt konfiguráció az egyik hálózaton és miért vall kudarcot a másikon: a szabály azonos, a hiányzó darab a túloldali továbbító szolgáltatás.

A három eset gyorsan elválik. Ellenőrizze, mi hallgat valójában, majd nézze meg az első bájtokat, amelyek a hosztra érkeznek:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Egy valódi SOCKS-kliens első hasznos bájtja 0x05, a köszöntésben szereplő verzió. Ha a rögzítés helyette eredeti alkalmazásadatokat mutat, egyetlen SOCKS-démon sem fog válaszolni, mert a tárgyalás soha nem kezdődött el. Ha semmi nem hallgat az 1080-on, a hoszt egy átjáró, és a kérdés az lesz, hogy továbbít-e, és hogy létezik-e visszaút.

Válassza ki a réteget négy kérdéssel

Van a programnak proxybeállítása? Használja, és álljon meg ott. Tartalmaz a forgalom olyan UDP-t vagy ICMP-t, amelynek túl kell élnie? Csak útválasztott vagy NAT-átjáró visz ICMP-t, az UDP pedig olyan SOCKS5-asszociációt igényel, amelyet mindkét fél támogat. Minden folyamatot le kell fedni a gépen, beleértve azokat is, amelyeket nem tud beállítani? Akkor olyan adapter kell, amely birtokolja az interfészt és lezárja a folyamokat. Át tudja vállalni a hozzá tartozó útválasztást, DNS-t és hurokmegelőzési kivételeket? Ha nem, az egyszerű átjáró kevesebbe kerül üzemeltetéskor.

Egy megkülönböztetést érdemes tisztán tartani. A VPN-kliens saját socks-proxy beállítása azt írja le, hogyan éri el a külső alagútkapcsolat a szerverét, és semmit nem mond a belső kliensfolyamok átalakításáról. A kettőt ugyanabban a jegyben folyton összekeverik. Döntse el, milyen kapcsolatra van szüksége, mielőtt hozzányúl egy útvonalhoz.