Waarom ’n macvlan-houer nie ’n VPN-kliënt kan antwoord nie

Stel jou ’n Linux-gasheer voor wat ’n VPN beëindig en ook ’n houer op ’n macvlan-netwerk laat loop. Die LAN is 192.168.60.0/24, die houer het 192.168.60.210, en VPN-kliënte kom van 10.95.0.0/24. Die kliënt bereik die diens, die antwoord kom nooit terug nie, en elke vuurmuurreël op die gasheer lyk korrek. Twee afsonderlike beperkings veroorsaak dié simptoom, en as jy die een regmaak, bly die ander een staan.

Twee beperkings, een simptoom

Die eerste beperking is isolasie: Docker se macvlan-bestuurder laat nie toe dat ’n houer deur die ouer-koppelvlak met sy eie gasheer praat nie. Verkeer tussen die gasheer se netwerkstapel en die houer het geen pad nie, maak nie saak hoe die roetes op die gasheer geskryf is nie.

Die tweede beperking is die terugpad. Die houer se verstekpoort is gewoonlik die LAN-roeteerder, so ’n antwoord aan ’n VPN-kliënt verlaat die netwerk deur daardie roeteerder. As die roeteerder geen roete terug na die VPN-poel het nie, word die antwoord êrens in die middel laat vaar.

Daardie twee foute lyk van die kliënt se kant identies: ’n versoek wat aankom en ’n antwoord wat nooit kom nie. Hulle verg verskillende herstellings, en ’n breë masquerade-reël kan verberg watter een nog stukkend is. Daarom is die eerste toets ’n opname aan die houer se kant eerder as nog ’n vuurmuurverandering. As die versoek nooit daar verskyn nie, is dit die isolasiebeperking wat speel.

Bou die gasheerkant se tussenlaag, eng

’n Tweede macvlan-koppelvlak op die gasheer, aan dieselfde ouer in brugmodus gekoppel, gee die gasheer se stapel sy eie identiteit op daardie LAN-segment. Resenteer ’n adres buite die DHCP-poel en buite die houerreeks daarvoor, en stuur net die houer daardeur.

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

Die eerste opdrag skep die koppelvlak in brugmodus, wat die gedokumenteerde verstek vir hierdie bestuurder is en die modus wat jy vir gasheer-houer-verkeer wil hê. Die tweede ken ’n /32 toe sodat die adres nie met die LAN-voorvoegsel bots nie, en die vierde stuur net die houer se adres deur die tussenlaag.

Moenie die hele LAN deur die nuwe koppelvlak herlei nie. Die gewone gekoppelde roete bly soos dit is, en die gasheerroete is doelbewus eng sodat een houer ’n pad kry sonder dat die res van die segment se gedrag verander. ’n Verstekroete wat na die tussenlaag wys, sou ’n ander ontwerp met ander gevolge wees. Hou dit spesifiek, dan bly die impakarea klein.

Hierdie opdragte verander netwerkinstellings op ’n lewendige gasheer. Op ’n toestel of ’n bestuurde platform, gebruik daardie platform se ondersteunde konfigurasiemeganisme, want ’n interaktiewe root-shell-verandering oorleef dalk nie ’n opgradering nie.

Bepaal hoe die bron bewaar word

Met die tussenlaag in plek kan die houer die gasheer bereik, en die vraag word watter bronadres die antwoord dra. Om die oorspronklike VPN-bron te bewaar is die skoner model: die houer sien die werklike kliëntadres, en die diens se logs en toegangsreëls kan dit gebruik.

Om dit te laat werk, moet die houer se netwerkkonfigurasie verkeer vir 10.95.0.0/24 na 192.168.60.250 stuur as sy poort vir hierdie pad. Dit is ’n ondersteunde roete- of poortinstelling binne die houer se eie konfigurasie, nie ’n truuk aan die gasheerkant nie. Bevestig dit van binne die houer eerder as om aan te neem die instelling het ingewerk. ’n Verstekpoort wat nog na die LAN-roeteerder wys, sal aanhou om antwoorde in dieselfde gat te stuur.

As die goedgekeurde ontwerp eerder die VPN-bronne wegsteek, beperk die vertaling eng: die werklike VPN-poel, die tussenlaag as die uitgaande koppelvlak, en die spesifieke houer en diens.

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

Pas die tussenlaag as die uitgangs-koppelvlak, nie die tonnel nie. ’n Reël wat die tonnel as die uitgaande koppelvlak noem, sal nie ’n pakket pas wat na die houer op pad is nie, en dit is die fout wat hierdie soort opstelling gewoonlik bevat. Hou die reël so eng soos die sin hierbo en hersien dit wanneer die poel verander.

Verifieer van die kliënt, nie die gasheer nie

’n Versoek van die gasheer self, gebind aan die tussenlaag se adres, bewys dat die tussenlaag die houer kan bereik. Dit bewys nie dat die houer verkeer na ’n bewaarde 10.95.0.x-bron kan terugstuur nie, want die bronadres in daardie toets is die tussenlaag se eie.

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

Die eerste opdrag toets die been van gasheer na houer, en die tweede wys wat werklik deur die tussenlaag gaan terwyl ’n regte VPN-kliënt die versoek maak. Kyk na die bronadres op die pad in en of ’n antwoord met dieselfde vloei verskyn.

Forwarding moet op die gasheer geaktiveer wees, en die forward-pad het ’n toelating nodig vir die VPN-poel na die tussenlaag op die dienspoort plus gevestigde antwoorde. ’n Gasheer-INPUT-reël mag nie forward-verkeer magtig nie, wat ’n algemene rede is waarom die pakket laat vaar word nadat die roetering korrek lyk.

Voer die regte toepassing met regte geloofsbriewe uit, en kyk dan of ’n tweede, onverwante diens op dieselfde houer jou steeds weier. As die enigste manier om dit te laat werk was om elke forward-reël oop te maak, is die ontwerp nie klaar nie. Let ook op watter bronadres die diens aangeteken het, want dit is wat sy eie toegangsreëls voortaan sal gebruik.