Listen, Bind en BindSame in Tinyproxy: welk adres wint

De proxy antwoordt, het verzoek wordt voltooid en toch registreert de bestemming nog steeds het LAN-adres. Niets in het proxylog ziet er verkeerd uit, en de regel die u hebt gewijzigd is precies degene die de documentatie u opdroeg te wijzigen. Op een host met zowel een LAN-adres als een tunneladres bepalen drie richtlijnen welk adres waar verschijnt, en slechts één ervan gaat over de uitgaande kant. Leest u ze in de verkeerde volgorde, dan belandt u zonder reden in de routetabel.

Het symptoom: de bestemming ziet het LAN-adres

Een client verbindt met de proxy op het LAN-adres, en de proxy opent zijn eigen verbinding naar de bestemming. Die tweede verbinding kiest een bronadres volgens de regels van de kernel, en standaard is dat wat de routeopzoeking selecteert. Daarom registreert de bestemming het primaire adres van de host, ook al ging elke byte door de proxy. Qua doorsturen is niets kapot, en daarom heeft het proxylog er niets over te zeggen.

Het spiegelbeeld van die fout is makkelijker te zien: pin de uitgaande bron vast op het tunneladres en LAN-clients bereiken de listener helemaal niet meer. Die versie kondigt zichzelf aan, terwijl de eerste zich achter een werkend verzoek verstopt. Beide komen voort uit het behandelen van één richtlijn alsof die beide vragen beantwoordt.

Drie richtlijnen, drie verschillende adressen

Listen benoemt het lokale adres dat proxyclients accepteert. Bind levert een bronadres voor de verbindingen die de proxy naar buiten maakt, en BindSame zegt dat hij het lokale adres van de zojuist geaccepteerde verbinding opnieuw moet gebruiken. Dat zijn drie aparte vragen, en één regel beantwoordt er slechts één. Ze door elkaar halen is de gebruikelijke reden dat een wijziging niets lijkt te doen.

Lees de geannoteerde configuratie die met de geïnstalleerde versie wordt meegeleverd, want standaardwaarden en geaccepteerde syntaxis verschuiven tussen releases. De voorbeeldconfiguratie van het project documenteert elke richtlijn naast de andere. Vergelijk dat bestand met het bestand op schijf, niet met een gids die voor een andere distributie is geschreven.

Stel de listener en de uitgaande bron afzonderlijk in

Neem een host waarvan het LAN-adres 192.168.50.10 is en het tunneladres 10.90.0.3. Als LAN-clients de proxy moeten bereiken terwijl hun verzoeken via de tunnel naar buiten gaan, zijn dat twee onafhankelijke beslissingen en beide moeten worden opgeschreven. Het fragment hieronder drukt precies dat uit en niets anders.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Dit is geen volledige configuratie, dus behoud de goedgekeurde poort, de authenticatie, de clienttoegangscontroles en de bestemmingsbeperkingen. Beide adressen moeten aan deze host toebehoren binnen de netwerknaamruimte van Tinyproxy, want een Bind-waarde die het proces niet kan bezitten faalt bij het verbinden, niet bij het starten. BindSame yes beschrijft een ander beleid, waarbij het lokale adres van de geaccepteerde verbinding de uitgaande bron wordt. In huidige releases heeft die tak voorrang boven de Bind-lijst, en zo verdwijnt een geconfigureerde bron zonder foutmelding.

Controleer de route die de bron impliceert

Een bronadres kiezen maakt geen pad, dus vraag de kernel wat hij met die bron en die bestemming zou doen. Een opzoeking die de tunnelinterface noemt is het minimale bewijs, en een die de LAN-interface noemt betekent dat de bron niet kan werken zoals geschreven. De opzoeking is contextueel: hij evalueert de beleidsregels en de tabel die in die naamruimte gelden. Het is geen verbinding, en hij zegt niets over wat een NAT verderop aan de dienst presenteert.

ip -4 route get 203.0.113.25 from 10.90.0.3

Gebruik een documentatieadres in het voorbeeld en vervang het door de dienst die u mag testen. Voer de opzoeking uit binnen de naamruimte van de proxy wanneer de proxy in een container draait, want de regels van de host zijn niet de regels die het proces ziet. Ontbreekt de bedoelde tunnelroute, laat de netwerkeigenaar die dan repareren in plaats van bestemmingsspecifieke regels op de proxyhost toe te voegen. Maak geen hostroutes leeg en schakel geen door de server geduwde routes uit om een opzoeking te laten slagen, ook al deed een oudere gids dat, want zulke wijzigingen verplaatsen het hele goedgekeurde VPN-gedrag van de host om één proxypad te repareren.

Bevestig de bron bij de bestemming

Lees de bron waar het verzoek aankomt, niet waar het vertrekt. Het applicatielog van de bestemming, of het edge-apparaat ervoor, registreert het adres dat het werkelijk zag, terwijl de proxy u alleen kan vertellen wat hij van plan was. Doe na de wijziging één nieuw verzoek via de bedoelde listener, want een gecachte verbinding bewijst niets over de nieuwe binding. Vergelijk daarna dat geregistreerde adres met het adres dat u hebt geconfigureerd.

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

curl is alleen de verkeersgenerator; het adres dat verificatie verdient is het adres dat de verre kant heeft gelogd, niet de peer waarmee curl toevallig verbinding maakte. Als de twee het oneens zijn, bepaal dan of het verschil uit de bronkeuze of uit een vertaling verderop komt, want die worden op verschillende plaatsen gerepareerd. Plan adreswijzigingen en herstarts van de proxy samen, want het binden van een adres dat de tunnel niet meer heeft mislukt stil na een herverbinding. Definieer ook het gedrag van DNS en IPv6 apart, want het IPv4-fragment hierboven bewijst daarover niets.