înregistrare Logare
Puncte:0
gstlouis avatar Server

ajungerea la adresa URL a gazdei virtuale a proxy inversat public Apache de la localhost în spatele unui NAT folosind iptables

drapel bo
gstlouis

Am o problemă cu un oaspete care folosește virsh în spatele unui server care rulează cu firewall iptables. Acest oaspete găzduiește site-uri web, unul este cel mai important cu proxy invers.

Totul merge bine. Am instalat apoi colabora online 1: https://www.collaboraoffice.com/code/. Super tare pentru a deschide documente și au un conecteaza pentru cea mai mare parte

Am testat acest plugin de pe un server la distanță care rulează și Mattermost, care ajunge la această casetă locală din spatele iptable-urilor mele și funcționează perfect. Cu toate acestea, când testez acest plugin de pe serverul local invitat, în spatele iptables, deci NAT, practic, nu se poate găsi. Am expirat.

Deci, oaspetele meu din spatele iptables, cu regulile corecte configurate pentru a trece traficul, deține mattermost ȘI CollaboraOnline, dar dacă direc URL-ul public de la mattermost pentru a prelua CollaboraOnline, ambele localhost nu se pot găsi reciproc. Nu pot face localhost:9980 sau 127.0.0.1:9980 (care este locul în care se află CollaboraOnline) în plugin, nu-i place portul din adresă...

Dacă fac bucle https://CollaboraOnline.domain.ca Văd că expiră.

Dacă editez fișierul /etc/hosts pe serverul localhost la 127.0.0.1 CollaboraOnline.domain.ca, apoi curl funcționează, mattermost-plugin găsește CollaboraOnline, dar tot nu va funcționa, deoarece ajung cu o eroare de verificare a tipului SSL ca aceasta.

AH02032: Numele de gazdă furnizat prin SNI și numele de gazdă furnizat prin HTTP nu au o configurație SSL compatibilă cum să ocolească

Așa că acum am rămas fără idei strălucitoare. Am o altă casetă publică care nu este în spatele virsh cu iptables, dacă fac curl la unul dintre gazdele sale, totul este în regulă. Acest lucru mă face doar să cred că iptables ar putea avea nevoie de o regulă pentru ca oaspetele meu care rulează mattermost și CollaboraOnline să poată să se întoarcă înapoi la sine atunci când solicită o adresă URL publică pe care o servește singur?!?

Are cineva idee despre asta?

VM-ul meu invitat este 192.168.122.126, iar serverul meu părinte care găzduiește invitații Vrish și iptables este 192.168.122.1

Iată regulile iptables (s-au eliminat unele dezordine precum chestii fail2ban)

iptables -L
Lanț FORWARD (politica ACCEPT)
target prot opt ​​sursă destinație         
ACCEPT pe toate -- oriunde 192.168.122.126 stare NOU, RELATED, INSTALAT
ACCEPT pe toate -- oriunde 192.168.122.0/24 ctstate RELATED,STABLISHED
ACCEPTĂ toate -- 192.168.122.0/24 oriunde            
ACCEPT pe toate -- oriunde oriunde            
REJECT all -- oriunde oriunde respinge-cu icmp-port-inaccesibil
REJECT all -- oriunde oriunde respinge-cu icmp-port-inaccesibil

iptables -L -t nat 
PRERUUTARE în lanț (politica ACCEPTĂ)
target prot opt ​​sursă destinație         
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:9980 la:192.168.122.126:9980
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:12000 la:192.168.122.126:12000
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:11000 la:192.168.122.126:11000
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:submission la:192.168.122.126:587
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:imap2 la:192.168.122.126:143
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:smtp la:192.168.122.126:25
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:webmin la:192.168.122.126:10000
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:4443 la:192.168.122.126:4443
DNAT udp -- oriunde 148.59.149.79 udp dpt:10000 la:192.168.122.126:10000
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:http la:192.168.122.126:80
DNAT tcp -- oriunde 148.59.149.79 tcp dpt:https la:192.168.122.126:443
34
0 + 0
Martin avatar
drapel kz
Martin
Dacă te-am înțeles corect, sistemul tău gazdă deține regulile iptables și redirecționează corect traficul de intrare către mașina ta virtuală. Ați executat comenzile curl în interiorul VM sau pe sistemul gazdă?
0
Răspunde
gstlouis avatar
drapel bo
gstlouis
@Martin Am făcut curl din VM-ul invitat, și nu serverul care deține iptables și găzduiește oaspeții mei. Deci, oaspetele meu este 192.168.122.126 și serverul meu/iptables/vrish este 192.168.122.1
0
Răspunde
Martin avatar
drapel kz
Martin
Ah, bine, VM și gazda sunt în aceeași subrețea... poți posta regulile tale iptables, te rog?
0
Răspunde
gstlouis avatar
drapel bo
gstlouis
@Martin a actualizat postarea originală
0
Răspunde
Martin avatar
drapel kz
Martin
iar VM-ul nu are reguli de firewall? pentru că dacă nat-ul are loc pe server, nu văd niciun motiv pentru care un curl din interiorul VM la localhost ar trebui să eșueze...
0
Răspunde
gstlouis avatar
drapel bo
gstlouis
@Martin VM are iptables pentru scopuri fail2ban. Lanțul FORWARD nu conține nimic, iar lanțurile de masă sunt goale. cu excepția cazului în care trebuie să-i spun lui iptables pe VM ceva despre repunerea în buclă a solicitării publice URL înapoi la sine, iptables nu deține nimic personalizat din configurația sa originală, cu excepția lanțurilor fail2ban suplimentare. Pot posta daca crezi ca este relevant.
0
Răspunde
Martin avatar
drapel kz
Martin
Să [continuăm această discuție în chat](https://chat.stackexchange.com/rooms/136222/discussion-between-martin-and-gstlouis).
0
Răspunde
gstlouis avatar
drapel bo
gstlouis
Trebuia deja să plece. Poate mâine? @martin
0
Răspunde
Martin avatar
drapel kz
Martin
sigur, cred că lanțurile INPUT / OUTPUT sunt relevante - poate fail2ban te-a blocat...
0
Răspunde
gstlouis avatar
drapel bo
gstlouis
@Martin Am oprit ambele f2b și încă nu funcționează. Sunt conectat la chat, dar este posibil să nu răspund rapid
0
Răspunde
Puncte:1
Martin avatar Server
drapel kz
Martin

Vinovatul aici a fost o regulă NAT defectuoasă/incompletă. În timpul unei conexiuni TCP, fiecare punct final are IP-uri sursă/destinație fixe, iar dacă pe acest port este primit un pachet IP cu un IP sursă/destinație diferit, pachetul este eliminat. Acest lucru este valabil pentru ambele puncte finale: client ( curl ) și server.

Pentru a înțelege problema, voi urmări fluxul de pachete, pornind de la client:

  • curl din interiorul VM trimite un pachet la adresa IP publică. IP sursă: 192.168.122.126, IP destinație: 148.59.149.79
  • Nucleul mașinii virtuale își verifică tabelul de rutare și trimite pachetul IP către gateway-ul implicit, care este 192.168.122.1
  • nucleul gazdei primește pachetul și îl trece prin lanțurile iptables (amintiți-vă care lanț este traversat primul - PREROUTING merge înainte de POSTROUTING )
  • în cadrul lanțului PREROUTING, IP-ul de destinație este înlocuit cu 192.168.122.126
  • aici, lanțul POSTROUTING va fi traversat.
  • din cauza IP-ului de destinație, pachetul se întoarce la VM
  • la soclul serverului, sosește pachetul IP. IP-ul de destinație ȘI sursa sunt 192.168.122.126. Nicio problemă până acum.
  • Socket-ul serverului trimite răspunsul - de data aceasta, deoarece IP-ul de destinație este propria sa interfață, regulile NAT ale gazdei NU se vor aplica.
  • Socket-ul clientului primește răspunsul de la 192.168.122.126 - care nu este IP-ul, la care socket-ul clientului și-a trimis cererea de conectare, prin urmare pachetul este abandonat.

Soluția este schimbarea adresei IP sursei într-un fel, în care răspunsul de la socket-ul serverului VM trebuie să treacă regulile NAT gazdă:

iptables -t nat -I POSTROUTING 1 -s 192.168.122.126 -d 192.168.122.126 -j SNAT --to-source 192.168.122.1

Rețineți că ținta SNAT este aplicabilă numai în cadrul lanțului POSTROUTING - prin urmare, DNAT-ul din lanțul PREROUTING a fost deja aplicat.

Cu această regulă, socket-ul serverului din interiorul VM primește o cerere de conexiune de intrare de la 192.168.122.1 - trimite răspunsul, iar răspunsul va primi regulile SNAT / DNAT aplicate invers, de îndată ce ajunge la gazdă: sursă la 192.168. 122.126, iar destinația la 148.59.149.79.

Acest răspuns corespunde cererii inițiale de conectare și încercarea de conectare reușește.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.