Slegs-IPv6-verbinding, IPv4-diens: laat ’n SOCKS-volmagt dit oorbrug

Jy het nie ’n adres in die bestemmingsfamilie nodig om dit te bereik nie, solank iets op die pad bereid is om deur te gee. Die toepassing maak aan die volmagt vas, en die volmagt maak ’n tweede verbinding na die bestemming oop. Dit is twee sokkels met onafhanklike adresfamilies, en niks in enige van die twee protokolle vereis dat hulle ooreenstem nie. Dit is deurgewing op toepassingsvlak eerder as ’n inheemse IPv4-pad, en dié onderskeid bepaal wat sal werk en wat nie. Om die twee te verwar, is hoe ’n skootrekenaar beskryf word asof dit IPv4-konnektiwiteit het terwyl al wat dit het ’n volmagt is.

Twee sokkels, twee adresfamilies

’n SOCKS5-versoek noem die bestemming in een van drie vorms: ’n letterlike v4-adres, ’n letterlike v6-adres, of ’n naam vir die volmagt om op te los. Die versoek beskryf waar die volmagt moet koppel, nie hoe die kliënt-tot-volmagt-verbinding lyk nie.

Lees dié adrestipes as drie onafhanklike keuses binne een boodskap. ’n Volmagt wat oor IPv6 bereikbaar is, kan ’n IPv4-bestemmingsokket oopmaak wanneer dit werkende IPv4-uitgang het en sy beleid die versoek toelaat. Die SOCKS5-spesifikasie definieer hulle sonder enige verwysing na die kliënt se transport.

’n Beheerde SSH-voorbeeld

Neem ’n SSH-gasheer wat jy gemagtig is om te gebruik, wat op IPv6 antwoord en self ’n HTTPS-diens kan bereik wat net op v4 bestaan. OpenSSH se dinamiese deurgewing plaas ’n plaaslike SOCKS-luisteraar op jou masjien terwyl die aanmeldsessie oor v6 loop.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Die gasheer en rekening hierbo is voorbeelde, en die loopback-binding hou die luisteraar op hierdie rekenaar. Moenie dit met ’n wildekaart-binding vervang sodat ’n kantoor ’n ongeverifieerde volmagt kan deel nie. ExitOnForwardFailure=yes bestaan sodat ’n mislukte deurgewing die sessie beëindig eerder as om ’n stil opdrag in die agtergrond te laat loop.

Met die sessie aan die gang, lyk die versoek so:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Die loopback-verbinding is nie ’n IPv4-internetpad nie. Wat jou masjien verlaat, is die aanmeldsessie oor v6, en die oorkant is wat die bestemmingsokket oopmaak. Die socks5h-vorm delegeer ook naamoplossing na daardie kant, wat saak maak wanneer die kliënt geen eie IPv4-oplosserpad het nie.

Wat die bestemming werklik sien

Die bestemming sien die deurgewing se uitgangsadres. Geen adres wat aan jou skootrekenaar behoort, verskyn daar nie. ’n Bron-toelatingslys op daardie diens moet die deurgewing noem. Die diens se logboeke sal die verkeer ook aan die deurgewing toeskryf. Skryf dit voor die oudit in die veranderingsrekord, want ’n toelatingslys wat om kliëntadresse gebou is, misluk by die eerste versoek.

Die deurgewing is ook die plek waar die twee helftes van die gesprek sigbaar is, wat ’n nuttige eienskap tydens diagnose en ’n las is as die deurgewing sonder beleid gedeel word.

Dit is nie DNS64 of NAT64 nie

DNS64 antwoord met gesintetiseerde rekords wat v4-bestemmings verteenwoordig, en NAT64 herskryf pakkette langs ’n gekonfigureerde pad. Nie een beskryf wat hier gebeur nie, waar een transportgesprek eindig en ’n ander begin en geen gesintetiseerde adres die resultaat verklaar nie. ’n Suksesvolle versoek sê dus niks oor watter vertalingsdienste jou verskaffer bedryf nie, en die volmagt kan gewone NAT op sy eie uitgang uitvoer.

Enige van die twee meganismes kan in dieselfde netwerk bestaan, so beskryf dié wat jy werklik geverifieer het eerder as dié wat die naaste klink.

Weet die omvang voordat jy dit belowe

OpenSSH se dinamiese deurgewing dra TCP-verbindings, nie willekeurige IP-verkeer nie, so UDP, ICMP en enige protokol wat die volmagt ignoreer, het ’n ander ondersteunde ontwerp nodig. Behou SSH-gasheersleutelverifikasie, die bediener se deurgewingbeperkings en HTTPS-sertifikaatvalidering, want die volmagt is ’n bykomende vertroude deelnemer eerder as ’n rede om identiteitskontroles te verswak. As die doel is om ’n VPN se buitenste transport deur die volmagt te dra, verifieer dat beide kante daardie transport ondersteun eerder as om te aanvaar enige SOCKS-luisteraar kan dit deurgee.

Niks hiervan maak die kliënt dubbelstapel nie, en niks daarvan hoef nie. Dit laat een toepassing een diens deur een deurgewing bereik, wat ’n kleiner bewering is en baie makliker om te verifieer.