Listen, Bind un BindSame Tinyproxy: kura adrese uzvar
Listen izvēlas adresi, kas pieņem klientus, Bind izvēlas izejošo savienojumu avotu. Neviena neuzstāda maršrutu, tāpēc ceļu pārbaudiet atsevišķi.
Starpniekserveris atbild, pieprasījums pabeidzas, un tomēr galamērķis joprojām reģistrē LAN adresi. Starpniekservera žurnālā nekas neizskatās nepareizi, un rinda, ko mainījāt, ir tieši tā, ko dokumentācija lika mainīt. Resursdatorā, kam ir gan LAN adrese, gan tuneļa adrese, trīs direktīvas nosaka, kura adrese kur parādās, un tikai viena no tām attiecas uz izejošo pusi. Lasot tās nepareizā secībā, jūs bez iemesla nonākat maršrutēšanas tabulā.
Simptoms: galamērķis redz LAN adresi
Klients pieslēdzas starpniekserverim LAN adresē, un starpniekserveris atver savu savienojumu uz galamērķi. Šis otrais savienojums izvēlas avota adresi pēc kodola noteikumiem, un pēc noklusējuma tā ir tā, ko izvēlas maršruta meklēšana. Tāpēc galamērķis reģistrē resursdatora primāro adresi, lai gan katrs baits gāja caur starpniekserveri. Pārsūtīšanas ziņā nekas nav salauzts, un tāpēc žurnālam par to nav ko teikt.
Šīs kļūdas spoguļattēlu pamanīt ir vieglāk: piespraudiet izejošo avotu pie tuneļa adreses, un LAN klienti vairs nemaz nesasniegs klausītāju. Tā versija pati sevi paziņo, bet pirmā slēpjas aiz strādājoša pieprasījuma. Abas rodas no tā, ka viena direktīva tiek uzskatīta par atbildi uz abiem jautājumiem.
Trīs direktīvas, trīs dažādas adreses
Listen nosauc vietējo adresi, kas pieņem starpniekservera klientus. Bind nodrošina avota adresi savienojumiem, ko starpniekserveris veido uz āru, un BindSame liek tam atkārtoti izmantot tikko pieņemtā savienojuma vietējo adresi. Tie ir trīs atsevišķi jautājumi, un viena rinda atbild tikai uz vienu. To sajaukšana ir ierastais iemesls, kāpēc izmaiņas šķiet nekas nedarošas.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
Lasiet komentēto konfigurāciju, kas piegādāta kopā ar instalēto versiju, jo noklusējuma vērtības un pieņemtā sintakse mainās starp laidieniem. Projekta paraugkonfigurācija dokumentē katru direktīvu blakus pārējām. Salīdziniet šo failu ar to, kas ir diskā, nevis ar rokasgrāmatu, kas rakstīta citai distribūcijai.
Iestatiet klausītāju un izejošo avotu atsevišķi
Ņemiet resursdatoru, kura LAN adrese ir 192.168.50.10 un tuneļa adrese ir 10.90.0.3. Ja LAN klientiem jāsasniedz starpniekserveris, bet to pieprasījumiem jāiziet caur tuneli, tie ir divi neatkarīgi lēmumi, un abi ir jāpieraksta. Zemāk esošais fragments izsaka tieši to un neko citu.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noŠī nav pilnīga konfigurācija, tāpēc saglabājiet apstiprināto portu, autentifikāciju, klientu piekļuves kontroli un galamērķa ierobežojumus. Abām adresēm jāpieder šim resursdatoram Tinyproxy tīkla vārdu telpā, jo Bind vērtība, ko process nevar piederēt, neizdodas savienojoties, nevis startējot. BindSame yes apraksta citu politiku, kur pieņemtā savienojuma vietējā adrese kļūst par izejošo avotu. Pašreizējos laidienos šai atzaram ir priekšroka pār Bind sarakstu, un tā konfigurētais avots pazūd bez kļūdas.
Pārbaudiet maršrutu, ko avots paredz
Avota adreses izvēle neveido ceļu, tāpēc pajautājiet kodolam, ko tas darītu ar šo avotu un šo galamērķi. Meklēšana, kas nosauc tuneļa saskarni, ir minimālais pierādījums, un tā, kas nosauc LAN saskarni, nozīmē, ka avots nevar darboties tā, kā rakstīts. Meklēšana ir kontekstuāla: tā izvērtē politikas noteikumus un tabulu, kas ir spēkā šajā vārdu telpā. Tā nav savienojums, un tā neko nepasaka par to, ko lejup pa straumi esošais NAT parādīs pakalpojumam.
ip -4 route get 203.0.113.25 from 10.90.0.3Piemērā izmantojiet dokumentācijas adresi un aizstājiet to ar pakalpojumu, kuru jums ir atļauts testēt. Veiciet meklēšanu starpniekservera vārdu telpā, ja starpniekserveris darbojas konteinerā, jo resursdatora noteikumi nav tie noteikumi, ko redz process. Ja paredzētais tuneļa maršruts neeksistē, lai tīkla īpašnieks to izlabo, nevis pievienojiet resursdatoram galamērķim raksturīgus noteikumus. Neattīriet resursdatora maršrutus un neizslēdziet servera virzītos maršrutus, lai meklēšana izdotos, pat ja vecāka rokasgrāmata tā darīja, jo šādas izmaiņas pārvieto visu apstiprināto resursdatora VPN uzvedību, lai salabotu vienu starpniekservera ceļu.
Apstipriniet avotu galamērķī
Lasiet avotu tur, kur pieprasījums ierodas, nevis tur, no kurienes tas iziet. Galamērķa lietojumprogrammas žurnāls vai tā priekšā esošā malas ierīce reģistrē adresi, ko tā patiešām redzēja, bet starpniekserveris var pastāstīt tikai savu nodomu. Pēc izmaiņām veiciet vienu jaunu pieprasījumu caur paredzēto klausītāju, jo kešatmiņā esošais savienojums neko nepierāda par jauno piesaisti. Pēc tam salīdziniet reģistrēto adresi ar iestatīto.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl ir tikai datplūsmas ģenerators; adrese, ko ir vērts pārbaudīt, ir tā, ko reģistrējusi tālā puse, nevis partneris, ar kuru curl nejauši savienojās. Ja abas nesakrīt, nosakiet, vai atšķirība rodas no avota izvēles vai no tālākas pārveides, jo tās labo dažādās vietās. Plānojiet adrešu izmaiņas un starpniekservera restartus kopā, jo tādas adreses piesaiste, kas tunelim vairs nav, pēc atkārtotas pievienošanās klusi neizdodas. Atsevišķi definējiet arī DNS un IPv6 uzvedību, jo iepriekš minētais IPv4 fragments neko nepierāda par nevienu no tiem.