Redsocks слуша на loopback, но VPN сообраќајот никогаш не пристигнува
Слушател врзан само на loopback никогаш не гледа сообраќај пренасочен од tun0. Прочитајте ја целта на пренасочувањето и врзувањето на socket, поправете го врзувањето, потоа тестирајте од вистински клиент.
Тунел се крева, клиентот може да пингува гејтвеј, но секое веб барање по патеката на проксито умира. Процесот redsocks работи и неговиот порт слуша, така што услугата изгледа здрава од самиот гејтвеј. Она што паѓа е чекорот на испорака: пакет пренасочен од тунелот не слетува на socket-от што сте го стартувале. Адресата на врзување и целта на пренасочувањето мора да се совпаѓаат, а обично се проверува само едно од двете.
Каде всушност слетува пренасочениот пакет
Транспарентното прокси на гејтвеј користи REDIRECT во nat табелата кај PREROUTING за да ја препише дестинацијата на влезната врска на локален порт. Препишаната дестинација е локална адреса како што ја гледа интерфејсот на кој пристигнал пакетот, а не loopback адресата на процес стартуван на друго место. Слушател врзан само на 127.0.0.1 прифаќа врски што веќе биле локални на домаќинот, и тоа е токму случајот што продолжува да работи додека сообраќајот низ тунелот паѓа. Сопствениот loopback на клиентот е трета адреса и никогаш не е цел на правилото на гејтвејот.
Затоа пред да ги допрете акредитивните податоци од горниот тек, утврдете два факти: на која локална адреса препишува правилото и на која адреса е врзан socket-от на проксито.
Читајте ги слушателот и правилото за пренасочување заедно
Испечатете ја табелата на socket-и и nat правилата во еден премин, бидејќи правило што покажува на порт што никој не го поседува изгледа исто како правило што покажува на погрешна адреса. sudo ss -ltnp | grep redsocks ја покажува адресата на врзување и процесот што ја поседува. sudo iptables -t nat -S PREROUTING ја покажува целта на REDIRECT, а sudo iptables -t nat -L PREROUTING -v -n покажува дали нешто се совпаднало со неа.
Скок на кориснички синџир наречен REDSOCKS не постигнува ништо ако тој синџир не постои и не ги носи предвидените исклучоци и дејството REDIRECT. Прочитајте го синџирот во кој скока со sudo iptables -t nat -S REDSOCKS наместо да претпоставувате дека името ја врши работата.
Потоа споредете ги двете вредности. Ако правилото пренасочува на адреса на гејтвеј на порта 12345 и слушателот известува 127.0.0.1:12345, несовпаѓањето го објаснува дефектот без никаква дополнителна дијагностика.
Врзете тесно, потоа ограничете што може да го достигне
Примерната конфигурација од горниот тек стандардно го става слушателот на loopback од добра причина: транспарентното прокси прифаќа врски во име на секој што може да го достигне. Менувањето на врзувањето на 0.0.0.0 ја поправа испораката и истовремено го отвора портот на секој интерфејс, што е безбедносна промена, а не неутрална поправка. Преферирајте врзување на конкретната локална адреса што ја цели пренасочувањето и држете го портот затворен на недоверливи интерфејси. Ако поширокото врзување е неизбежно, додадете правило на огнениот ѕид на домаќинот што дозволува само опсегот на изворот на тунелот и сопствениот локален сообраќај на гејтвејот.
Отворањето на портот на јавниот интерфејс никогаш не е потребно за пренасочен VPN сообраќај, бидејќи врската завршува локално по препишувањето. Не го изложувајте проксито на интернет за да проработи локално пренасочување.
Докажете го со нова врска од клиент
Тестирајте од вистински VPN клиент со свежа TCP врска, а не од школка на гејтвејот. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com на клиентот ја изминува пренасочената патека од почеток до крај.
Потоа потврдете дека директната врска до слушателот од недоверлива мрежа сѐ уште се одбива и дека сопствената горна врска на проксито не се фаќа повторно со истото правило. Рекурзивното фаќање се појавува како прокси што се поврзува со себе и никогаш не завршува барање. Додајте ја дестинацијата на проксито во множеството исклучоци или означете ги неговите излезни пакети за да ги прескокне синџирот.
На крајот, запомнете што не покрива оваа патека. Обичното TCP пренасочување на redsocks не ги претвора UDP, QUIC или DNS во SOCKS сообраќај, а приватните дестинации обично бараат експлицитни исклучоци. Успешен локален тест докажува само патеката низ loopback што никогаш не била проблем.