Listen, Bind și BindSame în Tinyproxy: care adresă câștigă

Proxy-ul răspunde, cererea se încheie și, totuși, destinația înregistrează în continuare adresa din LAN. Nimic din jurnalul proxy-ului nu pare greșit, iar linia pe care ați modificat-o este exact cea pe care documentația v-a spus să o modificați. Pe un host care are atât o adresă din LAN, cât și o adresă de tunel, trei directive decid ce adresă apare unde, și doar una dintre ele privește partea de ieșire. Citite în ordinea greșită, vă duc în tabelul de rutare fără motiv.

Simptomul: destinația vede adresa din LAN

Un client se conectează la proxy pe adresa din LAN, iar proxy-ul își deschide propria conexiune către destinație. Acea a doua conexiune alege o adresă sursă după regulile nucleului și, implicit, este cea selectată de căutarea rutei. De aceea destinația înregistrează adresa primară a hostului, deși fiecare octet a trecut prin proxy. Din punctul de vedere al transmiterii nu s-a stricat nimic, și de aceea jurnalul proxy-ului nu are ce spune.

Imaginea inversă a acestei defecte este mai ușor de observat: fixați sursa de ieșire pe adresa tunelului și clienții din LAN nu mai ajung deloc la ascultător. Acea versiune se anunță singură, în timp ce prima se ascunde în spatele unei cereri care funcționează. Ambele provin din a trata o singură directivă ca și cum ar răspunde la ambele întrebări.

Trei directive, trei adrese diferite

Listen numește adresa locală care acceptă clienții proxy-ului. Bind furnizează o adresă sursă pentru conexiunile pe care proxy-ul le deschide spre exterior, iar BindSame îi spune să reutilizeze adresa locală a conexiunii tocmai acceptate. Sunt trei întrebări separate, iar o singură linie răspunde doar la una. Confundarea lor este motivul obișnuit pentru care o modificare pare să nu facă nimic.

Citiți configurația comentată care însoțește versiunea instalată, pentru că valorile implicite și sintaxa acceptată se schimbă între versiuni. Configurația exemplu a proiectului documentează fiecare directivă alături de celelalte. Comparați acel fișier cu cel de pe disc, nu cu un ghid scris pentru altă distribuție.

Setați ascultătorul și sursa de ieșire independent

Luați un host a cărui adresă din LAN este 192.168.50.10 și a cărui adresă de tunel este 10.90.0.3. Dacă clienții din LAN trebuie să ajungă la proxy în timp ce cererile lor ies prin tunel, sunt două decizii independente și ambele trebuie scrise. Fragmentul de mai jos exprimă exact asta și nimic altceva.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Aceasta nu este o configurație completă, așa că păstrați portul aprobat, autentificarea, controalele de acces ale clienților și restricțiile de destinație. Ambele adrese trebuie să aparțină acestui host în spațiul de nume de rețea al Tinyproxy, pentru că o valoare Bind pe care procesul nu o poate deține eșuează la conectare, nu la pornire. BindSame yes descrie altă politică, în care adresa locală a conexiunii acceptate devine sursa de ieșire. În versiunile actuale acea ramură are prioritate față de lista Bind, și așa dispare o sursă configurată fără eroare.

Verificați ruta pe care o presupune sursa

Alegerea unei adrese sursă nu creează o cale, așa că întrebați nucleul ce ar face cu acea sursă și acea destinație. O căutare care numește interfața tunelului este dovada minimă, iar una care numește interfața LAN înseamnă că sursa nu poate funcționa așa cum este scrisă. Căutarea este contextuală: evaluează regulile de politică și tabelul în vigoare pentru acel spațiu de nume. Nu este o conexiune și nu spune nimic despre ce va prezenta un NAT mai departe serviciului.

ip -4 route get 203.0.113.25 from 10.90.0.3

Folosiți o adresă de documentație în exemplu și înlocuiți-o cu serviciul pe care sunteți autorizat să îl testați. Rulați căutarea în spațiul de nume al proxy-ului când proxy-ul rulează într-un container, pentru că regulile hostului nu sunt regulile pe care le vede procesul. Când lipsește ruta de tunel dorită, lăsați proprietarul rețelei să o repare în loc să adăugați reguli specifice destinației pe hostul proxy-ului. Nu goliți rutele hostului și nu dezactivați rutele împinse de server pentru ca o căutare să reușească, chiar dacă un ghid mai vechi făcea asta, pentru că astfel de modificări mută întregul comportament VPN aprobat al hostului pentru a repara o singură cale a proxy-ului.

Confirmați sursa la destinație

Citiți sursa acolo unde sosește cererea, nu de unde pleacă. Jurnalul aplicației de la destinație, sau echipamentul de margine din fața ei, înregistrează adresa pe care a văzut-o efectiv, în timp ce proxy-ul vă poate spune doar ce intenționa. Faceți o cerere nouă prin ascultătorul dorit după modificare, pentru că o conexiune din cache nu dovedește nimic despre noua legare. Apoi comparați adresa înregistrată cu cea pe care ați configurat-o.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl este doar generatorul de trafic; adresa care merită verificată este cea pe care latura îndepărtată a înregistrat-o, nu partenerul la care curl s-a conectat din întâmplare. Dacă cele două nu coincid, stabiliți dacă diferența vine din alegerea sursei sau dintr-o traducere mai departe, pentru că acestea se repară în locuri diferite. Planificați împreună modificările de adrese și repornirile proxy-ului, pentru că legarea unei adrese pe care tunelul nu o mai deține eșuează în tăcere după o reconectare. Definiți separat și comportamentul DNS și IPv6, pentru că fragmentul IPv4 de mai sus nu dovedește nimic despre niciunul dintre ele.