Docker-poortpublikasie en VPN-bronne: twee ooreenstemmings wat jy misloop

Die reël sê laat die VPN-bedieneradres na die gepubliseerde diens toe, en dit laat die verbinding steeds val. Daardie uitkoms is algemeen, en dit is nie ’n Docker-fout nie. Twee afsonderlike ooreenstemmings is verkeerd: die bron wat jy geskryf het, is dalk nie die bron wat die gasheer ontvang nie, en die poort wat jy geskryf het, is dalk nie die poort wat die filter sien nie. Om albei reg te maak, vereis dat jy na die pakketpad kyk eerder as na die diensdiagram.

Die mite: laat die VPN-bediener toe en jy is klaar

’n Geroteerde VPN kan die kliënttonneladres tot by die Docker-gasheer behou. ’n Aansluiting wat bronsvertaling doen, kan daardie adres met sy eie vervang. Albei ontwerpe is geldig, en hulle lewer verskillende bronne vir dieselfde gebruikersaksie.

Dus beskryf die frase die VPN-bediener-IP ’n aanname, nie ’n waarneming nie. Totdat jy weet watter van die twee ontwerpe voor jou is, bly die reël ’n raaiskoot.

Bron: kliëntpoel of vertaalde aansluiting

Kontroleer vier dinge in volgorde. Eerste, die kliëntadrespoel, byvoorbeeld 10.90.0.0/24. Tweede, of die aansluiting daardie poel vertaal voordat dit die gasheer bereik. Derde, die bron wat die gasheer werklik vir een nuwe verbinding sien. Vierde, of toepassingverifikasie individuele gebruikers onderskei, want ’n gedeelde vertaalde adres kan dit nie.

As die poel behou word, mis ’n reël wat net die aansluiting se publieke adres pas, elke kliënt. As die aansluiting doelbewus vertaal, laat die toelaat van die vertaalde adres elke gebruiker daarachter in, wat aanvaarbaar kan wees vir ’n diens met sy eie aanmelding en onaanvaarbaar vir enigiets anders.

Poort: DNAT verander die nommer wat jy pas

Vir gewone Linux-brugpublikasie met Docker iptables word ’n gasheertoewysing van 8443 na houerpoort 443 vertaal voordat die aanstuurfilter loop. Die pakket kom by die filter aan met bestemmingspoort 443. ’n Reël wat 8443 op daardie punt pas, vuur nooit nie, selfs al is 8443 wat die kliënt getik het.

Die gepubliseerde poort bestaan steeds in verbindingsnasporing, en daarom kan die oorspronklike bestemming daar gepas word wanneer jy dit regtig nodig het.

Besluit watter nommer die bedoeling uitdruk. Pas die houerpoort ná DNAT wanneer die reël die diens binne die houer beskerm. Pas die oorspronklike bestemming met die conntrack-opsie wanneer die reël moet beskryf wat die kliënt aangevra het, en aanvaar die ekstra passingkoste en sorg vir reëlvolgorde wat daarmee saamkom.

Ketting: DOCKER-USER, nie INPUT nie

Docker se iptables-gids plaas gebruikersaanstuurbeleid in die DOCKER-USER-ketting, wat voor Docker se eie aanstuurregels geëvalueer word. ’n Reël wat uit ’n gasheerdiens na die INPUT-ketting gekopieer is, filter verkeer wat aan die gasheer gerig is, nie verkeer wat na ’n houer aangestuur word nie. Daardie fout lewer ’n reël wat reg lyk en geen effek op die houerpad het nie.

Hou die bronreeks, die effektiewe bestemmingspoort, die protokol en die inkomende koppelvlak saam in dieselfde reël. ’n Slegs-bron-aanvaarding vir elke aangestuurde bestemming is wyer as om een gepubliseerde diens toe te laat.

Verifieer met nuwe verbindings

Toets albei rigtings met nuwe verbindings: een toegelate VPN-kliënt en een bron wat geweier moet bly. Bestaande verbindingstoestand kan ’n sessie laat voortleef nadat die beleid verander het, so ’n ou verbinding bewys niks oor die nuwe reël nie. Kontroleer daarna die antwoordpad, want die houer moet steeds terugroeteer na die bron wat dit sien.

Die Docker iptables-gids dokumenteer die kettingorde en die poortvertalingsgedrag agter hierdie kontroles. Lees dit voordat jy ’n resep kopieer, en bevestig watter backend die geïnstalleerde Docker gebruik, want die nftables-backend integreer beleid anders.