Elérni egy VPN-kliens szolgáltatását: fordított alagút vagy DNAT

Még egy szolgáltató NAT-ja mögötti laptop is kiszolgálhat egy kollégát, amíg a VPN-szerver találkozási pontként működik. Két mechanizmus vezet oda: a kliens kifelé tárcsáz és megkéri a szervert, hogy tartson fenn egy figyelő portot, vagy a szerver közzétesz egy portot és lefordítja az alagútba. Mindkettő ugyanazt az elérhetőségi problémát oldja meg, és eltérően viselkedik hiba, felügyelet és naplózás esetén. Három feltétel dönti el, melyik illik az Ön beállításához.

Két forma, egy találkozási pont

Az első formában a kliens kifelé nyit egy SSH-munkamenetet, és megkéri a szervert, hogy figyeljen egy kiválasztott porton, miközben minden kapcsolatot ezen a munkameneten keresztül küld vissza. A szerveren semmi nem kerül továbbításra, és nem történik csomagfordítás, ezért az egyetlen követelmény egy SSH-fiók, egy engedélyezett továbbítás és egy tűzfalszabály a portra. A szolgáltatás a kliens loopbackjéhez kötve marad, ami általában a kívánt állapot.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

A második formában a szerver birtokolja a nyilvános portot, és minden kapcsolatot átír a kliens alagútcímére. Ehhez engedélyezett IP-továbbítás, célfordítás belépéskor és forrásfordítás kilépéskor kell, és akkor is működik, amikor nincs SSH-munkamenet. A port a szerverhez tartozik, nem egy munkamenethez, és ez az a tulajdonság, amely a legtöbb valós esetet eldönti.

Egyik forma sem biztonságosabb önmagában. Mindkettő egy szolgáltatási portot tesz elérhetővé mindenkinek, aki eléri a szerver nyilvános címét, és mindkettő továbbra is a szolgáltatás saját hitelesítésétől függ.

Első feltétel: túl kell-e élnie a portnak a munkamenetet

A fordított továbbítás pontosan addig él, amíg az őt létrehozó SSH-munkamenet. Ha a kapcsolat megszakad, a figyelő eltűnik, és a kolléga lassú útvonal helyett elutasított kapcsolatot lát. A parancs systemd-egységgel és újraindítási szabályzattal való felügyelete ezt megoldja, és a ExitOnForwardFailure=yes azonnal láthatóvá teszi a sikertelen kötést, ahelyett hogy továbbítás nélkül futó munkamenetet hagyna hátra.

A lefordított port túléli az újraindításokat, ha a szabályok tartósan tárolódnak, de függ attól, hogy a kliens megtartsa ugyanazt az alagútcímet. Egy dinamikus készlet, amely újracsatlakozás után más címet ad a laptopnak, csendben a semmire irányítja a szabályt. Először foglalja le az alagútcímet, aztán írja meg a szabályt, és kezelje a kettőt egyetlen változtatásként.

Ha a szolgáltatásnak hajnali háromkor kell válaszolnia anélkül, hogy bárki figyelné, a szerver által közzétett portos forma a kevesebb mozgó alkatrészt tartalmazó megoldás, mert az egyetlen folyamat, amelynek talpon kell maradnia, maga az alagút.

Második feltétel: kié a tűzfal és a naplók

A fordított forma két helyen tartja a teljes szabályzatot. A sshd a AllowTcpForwarding révén eldönti, hogy egyáltalán engedélyezettek-e a távoli továbbítások, a GatewayPorts pedig eldönti, hogy a figyelő a loopbackhez vagy minden címhez kötődik-e. Az alapértelmezett no mellett a szerveren kívüli kolléga nem éri el a portot, pedig a továbbítás sikerült, és ez törött alagútnak látszik, holott valójában kötési címről van szó.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

A lefordított formához engedélyezett továbbítás és két szabály kell, és a második szabály az, ahol a legtöbb recept hibázik. A forrásfordítás conntrack-állapotra DNAT korlátozása azt jelenti, hogy csak a cél-szabály által létrehozott kapcsolatok íródnak át, nem pedig minden csomag, amelyet a szerver az alagútba küld.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Ez az átírás a hozzárendelést is tönkreteszi. Utána a kliens minden hívót a szerver alagútcímeként lát, ami minden címenkénti sebességkorlátot egyetlen vödörbe von össze, és elrejti, ki mit küldött. Ha a hozzárendelés fontos, fejezze be a kapcsolatot a szerveren, vagy tartsa ott az engedélyezési döntést, és adjon át identitást egy olyan fejlécben, amelyben a szolgáltatás megbízik. A két javítás közötti választás attól függ, hogy a szolgáltatás egyáltalán olvas-e proxy fejlécet.

Harmadik feltétel: egy port vagy sok, és kié a név

Egy szolgáltatás egy porton az az eset, amikor a fordított továbbítás erőfeszítésben nyer. Egy parancs, egy fiók és egy tűzfalszabály kell hozzá, a tisztítás pedig a munkamenet leállítása. Több szolgáltatás ugyanazon a nyilvános címen a szerver által közzétett forma felé tolja Önt, mert minden fordított továbbításnak saját szerverportra van szüksége, és a halmaz minden szolgáltatással nő.

A nevek tovább bonyolítják. Egy fordított továbbítás állhat olyan TCP-proxy mögött, amely SNI szerint irányít, míg a lefordított port általában egy port szolgáltatásonként. Ha a szolgáltatás maga fejezi be a TLS-t, és szüksége van az eredeti hosztnévre, a proxy megközelítés megőrzi azt, a DNAT megközelítés pedig csak akkor őrzi meg, ha a szolgáltatás elfogadja azt a nevet azon a porton.

Írja le, a három feltétel közül melyik döntötte el a formát. Különben a következő ember, aki második szolgáltatást ad hozzá, ugyanazt az összehasonlítást nyitja újra kevesebb kontextussal.

Döntsön, majd teszteljen kívülről

Tesztelje az útvonalat olyan hálózatból, amelynek nincs útvonala a laptophoz, és figyelje a szerver számlálóit, miközben a kérés fut. A szerverről a saját nyilvános címére irányuló teszt itt semmit nem bizonyít, mert a csomag helyben keletkezik, és soha nem éri el a bejövő fordítási kampót, így a teszt átmehet, miközben a valódi útvonal törött.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

A lapos számlálók azt jelentik, hogy a csomag soha nem ért el a szabályig, ami a szolgáltatóra vagy a hoszt tűzfalára utal. A mozgó számlálók, miközben a szolgáltatás elutasít, a kliens saját tűzfalára vagy arra a címre utalnak, amelyen a szolgáltatás figyel. Az az alagút, amely továbbítja a csomagot, de semmit nem ad vissza, útvonal- vagy visszaútvonal-probléma, és e három eredmény egyikét sem szabad a kliens adapterének szerkesztésével hibakeresni. Jegyezze fel, melyik számláló mozdult el, mielőtt bármit változtat, mert a következő tesztnek szüksége van arra az alapvonalra.

Amikor a forma működik, jegyezze fel a portot, a tulajdonost és a felügyeleti módszert az alagút konfigurációja mellé. Az olyan elérhetőségi javítás, amely csak valaki shell-előzményeiben létezik, egy újraindításra van az ismétlődő incidenstől.