probleme ciudate de NAT cu pfSense la VM vagabond

Acesta m-a derutat:

Am un firewall pfSense (să-l numim pfs) și în spatele lui mai multe servere. I NAT mai multe servicii de la IP-ul meu public la diferite servere de pe LAN fără probleme.

Pe unul dintre servere (să-l numim s1) Conduc a vagabond (cu libvirt) VM (să-l numim v1) cu public rețeaua configurată, care primește IP 192.168.1.159 prin intermediul pfss server DHCP.

Acum configurez un NAT simplu pfs a accesa s1SSH lui, să zicem <wan>:6622 -> s1:22 și accesați-l pe mydomain.com:6622. Nici o problema.

pot accesa si eu v1:22 (sau echivalentul 192.168.1.159:22) cu un utilizator ssh valid din interiorul LAN fara problema.

Acum adaug un simplu NAT pfs, Spune <wan>:6722 -> v1:22. Acum încerc să accesez mydomain.com:6722 nu muncă?!

Obiectivul este de a adăuga chiar și „un alt strat”: rularea containerelor cu porturi publice, de ex. --public 9980:80 pe v1 și accesați-le ca de ex. v1:9980 iar din mydomain.com:9980 cu NAT-ul corespunzător pornit pfs ca <wan>:9980 -> v1:9980. Din LAN și acest lucru funcționează conform așteptărilor (adică pot accesa v1:9980 de la LAN), ci un NAT prin pfs nu este.

Am setări similare care lucrează în aceeași rețea pe mașini diferite fără probleme. Mai am chiar altul (non-vagabond, dar și libvirt) VM pornit s1 la care pot ssh peste NAT prin IP-ul meu public perfect. Dar cumva cele de mai sus nu funcționează cu vagabond mașină și sunt într-adevăr pierdut ce ar putea cauza această problemă. (FWIW am net.ipv4.înainte activat pe v1).

EDITAȚI | ×:

M-am apropiat cu un pas: dacă distrug prima NIC existentă vagabond VM folosind virt-managerși setați al doilea VM la rtl8139 în loc de virtio (și apoi repornesc), pierd vagabond ssh capacitatea, dar apoi NAT funcționează. Deci întrebarea devine: cum se configurează prin vagabond furnizare astfel încât să avem o configurație similară, presupun că asta înseamnă că rețeaua publică trebuie să fie pe interfața implicită, atunci?

Soluţie:

Cauza este că vagabond necesită (și, prin urmare, configurează) interfața locală (rețeaua privată) ca principală, fără o metodă standard de a o înlocui. (Unele informații sunt Aici, cu exceptia vagabond oamenii recunosc că sunt ei înșiși confuzi de subiect...)

O variantă (mai robustă) a conceptului pentru a modifica rutele implicite a adus soluția. Eu folosesc un ansible provider, unde execut următoarele (pe invitat, prin intermediul manualului de aprovizionare):

  - nume: eliminați ruta implicită greșită pe eth0 (din nou)
    coajă: |
      eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route del default via %s dev % s; ",$3,$8 }')

(interesant trebuie să fie executat de două ori (sau după un timp?), posibil pentru că rețeaua nu a apărut complet când a început scriptul de furnizare?)

Aceasta elimină ruta implicită activată eth0 (cel retea publica ar fi configurat automat numai pe et1 de vagabond) și face ca conexiunile externe să funcționeze conform așteptărilor. Acest lucru se presupune (speculând aici) din cauza faptului că răspunsurile la cererile NAT primite sunt direcționate către firewall prin ruta implicită pe eth0 implicit (care până la vagabond implicit are prioritate), ceea ce confundă FW-ul NAT deoarece a intrat pe VM-uri et1. Deci înlăturare eth0 ca răspuns implicit la solicitările externe pe aceeași interfață pe care au venit.