Врска само преку IPv6, услуга на IPv4: нека SOCKS проксито го премости
SOCKS прокси прима една врска и отвора друга, така што клиент само со IPv6 стигнува до услуга на IPv4. Тоа е препраќање, а не нативен пристап до IPv4.
Не ви треба адреса од семејството на дестинацијата за да стигнете до неа, се додека нешто на патот е подготвено да препраќа. Апликацијата се поврзува со проксито, а проксито отвора втора врска до дестинацијата. Тоа се два сокета со независни семејства на адреси, и ништо во ниту еден од двата протокола не бара тие да се совпаѓаат. Тоа е препраќање на ниво на апликација, а не нативна патека IPv4, и токму таа разлика одлучува што ќе работи, а што не. Мешањето на двете е причината зошто лаптоп се опишува како да има IPv4 поврзаност кога се што има е прокси.
Два сокета, две семејства на адреси
SOCKS5 барањето ја именува дестинацијата во една од три форми: буквална v4 адреса, буквална v6 адреса или име што проксито треба да го реши. Барањето опишува каде проксито треба да се поврзе, а не како изгледа врската клиент-кон-прокси.
Читајте ги овие типови адреси како три независни избори во една порака. Прокси достапно преку IPv6 може да отвори сокет за дестинација IPv4 кога има работен IPv4 излез и неговата политика го дозволува барањето. Спецификацијата на SOCKS5 ги дефинира без никакво повикување на транспортот на клиентот.
Контролиран пример со SSH
Земете SSH домаќин што ви е дозволено да го користите, кој одговара на IPv6 и самиот може да стигне до HTTPS услуга што постои само на v4. Динамичното препраќање на OpenSSH поставува локален SOCKS слушател на вашата машина додека сесијата за најава оди преку v6.
ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]Домаќинот и сметката погоре се примери, а loopback врзувањето го држи слушателот на овој компјутер. Не заменувајте го со врзување на сите адреси за да може канцеларија да дели неавтентифицирано прокси. ExitOnForwardFailure=yes постои за да може неуспешното препраќање да ја заврши сесијата наместо да остави тивка команда да работи во позадина.
Додека сесијата работи, барањето изгледа вака:
curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/Loopback врската не е интернет патека IPv4. Она што ја напушта вашата машина е сесијата за најава преку v6, а далечната страна е таа што го отвора сокетот за дестинацијата. Формата socks5h исто така го делегира решавањето на имиња на таа страна, што е важно кога клиентот нема своја IPv4 патека до решавач.
Што всушност гледа дестинацијата
Дестинацијата ја гледа излезната адреса на препраќачот. Таму не се појавува ниту една адреса што му припаѓа на вашиот лаптоп. Списокот на дозволени извори на таа услуга мора да го именува препраќачот. Неговите дневници исто така ќе го припишат сообраќајот на препраќачот. Запишете го тоа во записот за промени пред ревизијата, зашто списокот на дозволени изграден околу адресите на клиентите паѓа при првото барање.
Препраќачот е и местото каде што се видливи двете половини од разговорот, што е корисна особина при дијагноза и товар ако препраќачот се дели без политика.
Ова не е DNS64 или NAT64
DNS64 одговара со синтетизирани записи што ги заменуваат дестинациите v4, а NAT64 ги препишува пакетите по конфигурирана патека. Ниту едно не опишува што се случува овде, каде што еден транспортен разговор завршува и друг почнува и никаква синтетизирана адреса не го објаснува резултатот. Затоа успешното барање не кажува ништо за тоа кои услуги за превод ги води вашиот давател, а проксито може да извршува обичен NAT на својот излез.
Двата механизми можат да постојат во истата мрежа, затоа опишете го тој што навистина сте го провериле, наместо тој што звучи најблиску.
Знајте го опсегот пред да го ветите
Динамичното препраќање на OpenSSH пренесува TCP врски, а не произволен IP сообраќај, затоа UDP, ICMP и секој протокол што го игнорира проксито бараат друг поддржан дизајн. Зачувајте ја проверката на клучот на SSH домаќинот, ограничувањата за препраќање на серверот и валидацијата на HTTPS сертификатот, зашто проксито е дополнителен доверлив учесник, а не причина да се ослабат проверките на идентитетот. Ако целта е да се пренесе надворешниот транспорт на VPN преку проксито, проверете дали двата краја го поддржуваат тој транспорт наместо да претпоставите дека секој SOCKS слушател може да го препрати.
Ништо од ова не го прави клиентот двостеков и ништо од тоа не е потребно. Тоа прави една апликација да стигне до една услуга преку еден препраќач, што е помало тврдење и многу полесно за проверка.