Zašto macvlan kontejner ne može odgovoriti VPN klijentu

Zamislite Linux host koji prekida VPN i istovremeno pokreće kontejner na macvlan mreži. LAN je 192.168.60.0/24, kontejner drži 192.168.60.210, a VPN klijenti dolaze s 10.95.0.0/24. Klijent stigne do servisa, odgovor se nikad ne vrati, a svako firewall pravilo na hostu izgleda ispravno. Dva odvojena ograničenja stvaraju taj simptom, a popravka jednog ostavlja drugo na mjestu.

Dva ograničenja, jedan simptom

Prvo ograničenje je izolacija: Dockerov macvlan drajver ne dopušta kontejneru razgovor s vlastitim hostom preko roditeljskog interfejsa. Promet između steka hosta i kontejnera nema put, kako god rute na hostu bile napisane.

Drugo ograničenje je povratni put. Zadani gateway kontejnera obično je LAN ruter, pa odgovor upućen VPN klijentu izlazi kroz taj ruter. Ako ruter nema rutu natrag do VPN poola, odgovor se negdje u sredini odbacuje.

Ta dva kvara izgledaju identično s klijentove strane: zahtjev koji stigne i odgovor koji nikad ne dođe. Trebaju različite popravke, a široko masquerade pravilo može sakriti koji je još pokvaren. Zato je prvi test snimanje paketa na strani kontejnera, a ne još jedna izmjena firewalla. Ako se zahtjev tamo nikad ne pojavi, na djelu je ograničenje izolacije.

Izgradite šim na strani hosta, usko

Drugi macvlan interfejs na hostu, priključen na isti roditelj u bridge modu, daje steku hosta vlastiti identitet na tom LAN segmentu. Rezervišite mu adresu izvan DHCP poola i izvan raspona kontejnera, a kroz njega usmjeravajte samo kontejner.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Prva naredba stvara interfejs u bridge modu, što je dokumentirani zadani način za ovaj drajver i mod koji želite za promet između hosta i kontejnera. Druga dodjeljuje /32 da se adresa ne sukobi s LAN prefiksom, a četvrta kroz šim šalje samo adresu kontejnera.

Ne preusmjeravajte cijeli LAN kroz novi interfejs. Obična povezana ruta ostaje kakva jest, a ruta hosta namjerno je uska da jedan kontejner dobije put bez promjene ponašanja ostatka segmenta. Zadana ruta prema šimu bila bi drugi dizajn s drugim posljedicama. Držite je konkretnom i polumjer štete ostaje mali.

Ove naredbe mijenjaju mrežne postavke na hostu koji radi. Na uređaju ili upravljanoj platformi koristite podržani mehanizam konfiguracije te platforme, jer interaktivna promjena kroz root-shell možda neće preživjeti nadogradnju.

Odlučite kako se izvor čuva

Sa šimom na mjestu kontejner može doći do hosta, a pitanje postaje koju adresu izvora nosi odgovor. Čuvanje izvornog VPN izvora čišći je model: kontejner vidi pravu adresu klijenta, a servisovi logovi i pravila pristupa mogu je koristiti.

Da bi to radilo, mrežna konfiguracija kontejnera mora za taj put slati promet za 10.95.0.0/24 na 192.168.60.250 kao svoj gateway. To je podržana postavka rute ili gatewaya unutar kontejnerove vlastite konfiguracije, a ne trik na strani hosta. Potvrdite je iz unutrašnjosti kontejnera umjesto da pretpostavite da je postavka primijenjena. Zadani gateway koji još pokazuje na LAN ruter nastavit će slati odgovore u istu rupu.

Ako odobreni dizajn umjesto toga skriva VPN izvore, ograničite prijevod usko: pravi VPN pool, šim kao izlazni interfejs te konkretni kontejner i servis.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Uparite šim kao izlazni interfejs, ne tunel. Pravilo koje tunel navodi kao izlazni interfejs neće se poklopiti s paketom koji ide prema kontejneru, a to je greška koju ovakva postavka obično sadrži. Držite pravilo usko kao rečenicu iznad i pregledajte ga kad se pool promijeni.

Provjerite s klijenta, ne s hosta

Zahtjev sa samog hosta, vezan na adresu šima, dokazuje da šim može doći do kontejnera. On ne dokazuje da kontejner može vratiti promet do sačuvanog izvora 10.95.0.x, jer je adresa izvora u tom testu vlastita adresa šima.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Prva naredba testira dionicu od hosta do kontejnera, a druga pokazuje što stvarno prolazi kroz šim dok pravi VPN klijent šalje zahtjev. Pogledajte adresu izvora na ulazu i pojavljuje li se odgovor s istim tokom.

Na hostu mora biti omogućeno prosljeđivanje, a put prosljeđivanja treba dozvolu za VPN pool prema šimu na servisnom portu plus uspostavljene odgovore. INPUT pravilo na hostu ne odobrava proslijeđeni promet, što je čest razlog što se paket odbaci nakon što rutiranje izgleda ispravno.

Pokrenite pravu aplikaciju s pravim vjerodajnicama, pa provjerite da li vam drugi, nepovezani servis na istom kontejneru još odbija pristup. Ako je jedini način da proradi bilo otvaranje svih pravila prosljeđivanja, dizajn nije dovršen. Zabilježite i koju je adresu izvora servis zapisao, jer će je njegova vlastita pravila pristupa od sada koristiti.