wget și redirecționarea porturilor (Administrarea sistemului, Iptables, Wget, Centos6.5)

Tony B a intrebat.

Am o problemă ciudată. Pot rula această comandă foarte bine de pe diverse servere:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9091/weijhkdsvn/v9_odbc//CRONTAB.2014020

Unde „GW-BOX” este poarta de acces la rețeaua mea, USER123 și PASSWORD reprezintă utilizatorul și parola pentru weijhkkdsvn, iar 9091 indică un server Linux intern. Problema este că această comandă se reține și/sau este respinsă.

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9093/weijhkdsvn/v9_odbc//CRONTAB.20140206

Portul 9093 indică un alt server intern. Rețineți că singura diferență este portul.

Așa că am încercat apoi să fac un wget direct de pe server, pentru a mă asigura că http este configurat corect:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9091-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

În acest caz, 9091-Server este serverul intern la care se referă portul 9091. Funcționează bine. apoi am încercat aceeași comandă, dar mimând portul 9093:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9093-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

unde 9093-Server se referă la serverul intern către care indică 9093.

Deci, exemplele de mai sus dovedesc că 9093-Server are http configurat corect pentru a permite wget, din câte văd eu. Acest lucru sugerează că poate problema este cu GW-BOX, așa că am testat porturile cu telnet, iar portul 9091 a funcționat bine.

[wmsodbc]> telnet GW-BOX 9091
Trying GW-BOX...
Connected to GW-BOX.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[wmsodbc]> 

Dar portul 9093 nu a funcționat:

[wmsodbc]> telnet GW-BOX 9093
Trying GW-BOX...
telnet: connect to address GW-BOX: Connection refused
[wmsodbc]>

Așa că am verificat iptables pe GW-BOX:

[[email protected] ~]# iptables-save | grep "909[13]"
-A INPUT -p tcp -m tcp --dport 9091 -j LOG 
-A INPUT -p tcp -m tcp --dport 9093 -j LOG 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9091 -j DNAT --to-destination 9091-ServerIp:80 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9093 -j DNAT --to-destination 9093-ServerIp:80 
-A POSTROUTING -d 9091-ServerIp/32 -p tcp -m tcp --dport 9091 -j SNAT --to-source GW-BOX-INTERNAL-IP
-A POSTROUTING -d 9093-ServerIp/32 -p tcp -m tcp --dport 9093 -j SNAT --to-source GW-BOX-INTERNAL-IP 
[[email protected] ~]# 

Deci, ce altceva pot verifica pentru a vedea de ce portul 9091 acceptă cereri wget/telnet, dar 9093 nu?

Comentarii

  • Funcționează serviciul dumneavoastră? –  > Por Michael Hampton.
  • Ce serviciu? Rețineți că un port funcționează, iar celălalt nu, ceea ce sugerează că lucrurile funcționează. Rețineți, de asemenea, că wget folosind 9093-Server:80 funcționează, ceea ce înseamnă că serviciul rulează pe 9093-Server. Singurul lucru care eșuează este trecerea de la un al treilea server la GW-BOX la 9093 la 9093-Server. –  > Por Tony B.
  • în codul de mai sus, folosiți nume inventate și altele asemenea, poate verificați toate configurațiile dvs. diferite și verificați dacă nu este o simplă greșeală de ortografie? –  > Por Sverre.
3 răspunsuri
George Spiceland

O metodă de a verifica unde este problema, este de a schimba porturile față de servere. ServerA are în prezent portul 9091 și funcționează corect, ServerB are portul 9093 și nu reușește. Pentru a determina dacă problema este în GW-Box sau în serverul în sine, întoarceți configurația iptables în GW-box pentru SNAT. Orientați 9091 către ServerB, iar 9093 către ServerA. Dacă 9091 continuă să funcționeze, știți că problema este undeva în regula pe care o aveți pentru portul 9093, deoarece atât serverul A, cât și B funcționează pe 9091, acest lucru ar putea indica, de asemenea, o problemă de regulă de firewall și pe serverul B. Dacă 9091 eșuează, dar 9093 funcționează, puteți presupune în mod sigur că GW-Box-ul dumneavoastră funcționează corect și că Serverul B nu permite cumva accesul porturilor din gama superioară prin WGET, deoarece ați confirmat anterior că WGET este accesibil direct.

Comentarii

  • Ok, dacă am inversat 9091 cu 9093 a arătat ceva. Acum 9091 nu funcționează de la un computer la distanță. Deci asta ar însemna că ceva nu este în regulă cu 9093-Server, ceea ce nu are sens, deoarece wget 9093-Server:80 funcționează bine de pe GW-BOX. Am crezut că iptables trimitea porturile 9091 și 9093 către portul 80 de pe serverul lor corespunzător ( a se vedea mai sus ). Nu face acest lucru? Îl trimite la un port total diferit? –  > Por Tony B.
  • BTW, pentru 9091-Server ( cel care funcționează ) și 9093-Server ( cel care NU funcționează ), iptables nu este activ și NU ascultăm pentru porturile 9091 sau 9093 conform netstat. Acest lucru înseamnă că, din perspectiva iptables și netstat, atât mașina care funcționează, cât și cea care nu funcționează sunt configurate foarte asemănător. –  > Por Tony B.
  • Există altceva care ar putea afecta portul în cauză în rețea? Dacă serverul nu răspunde pe ~celor~ porturi de la distanță care sunt redirecționate, sunteți sigur că regula din GW nu are nimic neobișnuit în ea în legătură cu numele de gazdă sau IP-ul serverului 9093? Toate etapele de depanare sugerează că există ceva în serverul 9093 care cauzează problema. Este posibil ca în configurația serverului de partajare a fișierelor http să existe vreun control al accesului? Sau are vreun IP de ascultare specific care ar putea fi cauza problemei? –  > Por George Spiceland.
  • Chestia este că funcționează bine cu portul 80, deci nu ar sugera asta că configurația pentru serverul de partajare a fișierelor http este configurată corect, pentru a permite accesul? Adică, tot ce face caseta GW este să direcționeze portul extern către portul 80 de pe serverul „rău”. De asemenea, subliniați că poate regula de pe GW face ceva neobișnuit. Nu văd cum, dar presupun că orice este posibil. Voi verifica din nou aceste reguli. –  > Por Tony B.
  • Tocmai m-am gândit la un alt simptom care ar putea avea legătură cu comentariile tale, George: dacă folosesc această cutie GW ca GW pentru alte mașini, atunci acele alte mașini nu pot accesa internetul. Dar această cutie GW poate accesa cu siguranță internetul. Cu alte cuvinte, ping la www.apple.com în interiorul rețelei nu ar funcționa, dar ping la www.apple.com ar funcționa de la această cutie GW. Credeți că acest lucru ar putea explica problema mea? Nu văd cum, deoarece pot rula wget către o altă mașină din interiorul rețelei, dar este un simptom care merită menționat. –  > Por Tony B.
Sverre

În primul rând, testul pe care l-ați făcut direct pe wget la servere, de unde au fost făcute aceste teste? de la gazda originală, sau de la GW-box sau de la o gazdă „terță”?.

De asemenea, pe GW-box ați verificat dacă alte servicii folosesc portul 9093? (pe gw-box rulați ceva de genul:

netstat -lnptu | grep 9093

Comentarii

  • For the 9093-Server:80 și 9091-Server:80 wget pe care le-am făcut mai sus, le-am rulat direct pe GW-BOX, dovedind astfel că lucrurile sunt configurate corect pe 9091-Server și 9093-Server pentru a permite wget. –  > Por Tony B.
  • Pentru testele telnet, le-am rulat în totalitate în afara rețelei, prin intermediul internetului. Pentru testele GW-BOX:9093, , și pentru GW-BOX:9091 le-am rulat în afara rețelei, de la GW-BOX, de la 9091-Server și de la 9093-Server. Testele 9091-Server funcționează din afara rețelei și de pe 9093-Server. Nu funcționează de pe 9091-Server sau de pe GW-BOX. Testul 9093-Server nu funcționează pentru nicio cutie. –  > Por Tony B.
  • În ceea ce privește testul netstat pe GW-BOX, ceea ce este ciudat este că nu obțin nimic nici pentru 9091, nici pentru 9093, dar, așa cum am discutat, 9091 funcționează. Acesta a fost unul dintre primele lucruri pe care le-am verificat. Bănuiesc că portul nu trebuie să fie ascultat ( din perspectiva netstat ) din cauza iptables. Acestea fiind spuse, am rulat „nmap -sT -O localhost -p 9091,9093”, iar ambele porturi sunt menționate. Am un alt port ( 31006, cu totul alt scop ) care funcționează bine și arată exact ca 9093 în nmap și netstat. –  > Por Tony B.
  • v-ați gândit să încercați un alt port, poate încercați 9094 în loc de 9093 – -.  > Por Sverre.
  • George a sugerat mai sus inversarea porturilor, ceea ce am făcut și eu, fără succes. Mulțumesc. –  > Por Tony B.
Tony B

Ok, mi-am dat seama de problemă. GW-BOX este menit să fie o cutie gateway, evident. Dar, așa cum am spus într-un alt fir de discuție aici, nu am putut accesa internetul PRIN această cutie. Se pare că odată ce am rezolvat această imposibilitate de a accesa internetul PRIN această GW-BOX, am putut folosi wget foarte bine. În cazul meu, conform firului de discuție pe care tocmai l-am menționat, a trebuit să schimb iptables-ul de la

iptables-save | grep eth
-A POSTROUTING -o eth1 -j SNAT --to-source 68.AAA.BBB.155

la

iptables-save | grep eth
-A POSTROUTING -o eth2 -j SNAT --to-source 68.AAA.BBB.155

și acum lucrurile funcționează. De asemenea, am configurat porturi total noi, dar nu cred că asta a fost cauza principală.

Mulțumesc. Sper că acest lucru ajută pe altcineva.