Docker-poortpublikasie teenoor die VPN: waarheen die antwoord gaan

’n Gepubliseerde houer antwoord vanaf sy eie adres voordat omgekeerde NAT plaasvind. Twee ontwerpe kan daardie antwoord op die openbare pad hou, met verskillende koste.

Die gasheer bly SSH antwoord nadat ’n vol-tonnel-VPN opkom, terwyl ’n Docker-gepubliseerde diens op dieselfde masjien stil word. Niks is verkeerd met die luisteraar nie: die houer loop, die poortkaart bestaan, en die pakket kom aan. Die houer is gesond en die versoek bereik dit wel. Wat verskil, is waar die antwoord begin wanneer Linux sy roete kies, en daardie verskil bepaal watter van die twee ontwerpe hieronder jy nodig het.

Volg die tuple deur die bestemming-NAT

Neem ’n gasheer by 192.0.2.10 wat TCP 2222 na ’n houer by 172.30.240.5:22 publiseer. ’n Versoek van 198.51.100.25 word vertaal voordat dit die houer bereik, en die houer antwoord as homself.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

By die gasheer se roetebesluit dra die antwoord steeds die houer se bronadres. Omgekeerde vertaling herstel later die gepubliseerde tuple, en daarom lyk die pakket verkeerd juis op die oomblik wanneer die roete gekies word.

Waarom ’n reël net vir die gasheer dit mis

’n Reël wat die WAN-tabel net vir pakkette van 192.0.2.10 kies, dek die gasheer se eie daemons en mis hierdie deurgevoerde antwoord heeltemal. Die bronadres op die antwoord is 172.30.240.5, nie die gasheer nie.

Die oorkorreksie is om alles van die houer deur die WAN te stuur, wat ook die houer se onverwante uitgaande verbindings van die VPN vrystel. Dit is ’n ander beleid as die een wat gevra is, en dit verras gewoonlik iemand later.

Post-DNAT-passing is ’n ander haak

Docker se dokumentasie oor firewalls wys daarop dat gewone gebruikersfiltering die bestemming ná DNAT sien, so om die gepubliseerde poort 2222 in ’n normale reël te pas is nie dieselfde as om houerpoort 22 te pas nie. As die oorspronklike tuple saak maak, gebruik die ondersteunde oorspronklike-bestemming-meganisme eerder as om te raai watter poort sigbaar is.

Hierdie haakverwarring lewer reëls op wat korrek lyk en nooit pas nie. Kyk na die tellers op die reël self voordat jy die beleid herskryf. ’n Reël met nul treffers sê vir jou dit word op ’n plek geëvalueer waar die pakket nooit kom nie.

Ontwerp A: dra die besluit as verbindingstoestand

’n Verbindingsmerk kan die inkomende besluit deur die vertaling dra, maar dit moet aan die pakket terugbesorg word voordat die betrokke roetesoektog plaasvind. Die stadiums is:

  1. Reserveer ’n merkveld en reëlprioriteit wat nie met Docker, die VPN of ’n ander beleideienaar bots nie.
  2. Identifiseer net die beoogde nuwe WAN-verbinding by ’n pre-DNAT-punt waar verbindingsnaspeuring beskikbaar is.
  3. Teken die besluit op die verbindingsmerk aan, sonder om die oorspronklike versoek self na die WAN-tabel te dwing.
  4. Herstel in die antwoordrigting net jou eie merkbitte aan die pakket voordat daar gerouteer word.
  5. Kies ’n volledige WAN-tabel vroeg genoeg dat ’n VPN-reël nie eerste kan wen nie.

Daardie tabel het die werklike gekoppelde roetes en die poort nodig. Dit het ook ’n bepaalde gedrag nodig wanneer die roete ontbreek. Stil deurval in die tonnel is die slegste uitkoms, want die konfigurasie lyk steeds asof dit werk. Misluk geslote en teken dit aan eerder.

Ontwerp B: termineer op die gasheer

’n Doelbewus opgestelde frontend aan die gasheerkant, soos ’n TCP-proxy of ’n omgekeerde proxy voor die houer, hou die antwoord afkomstig van die gasheer se adres. Reëls wat vir die gasheer geskryf is, werk dan soos verwag, en die houer bly op sy private netwerk.

Die koste is nog ’n bewegende deel met sy eie konfigurasie, bronadreshantering en toegangsbeheer. Dit is gewoonlik die eenvoudiger ondersteunde grens, en dit is dikwels die regte antwoord wanneer die routeringsbeleid deur een persoon onderhou sou word wat dalk weggaan.

Verifieer die verandering, nie die bedoeling nie

Maak ’n nuwe gemagtigde verbinding van die openbare kant oop en bevestig dat die antwoord die bedoelde koppelvlak verlaat. Kyk dan of ’n onverwante versoek wat die houer begin, steeds die VPN volg.

Moenie die masjien se verbindingstabel spoel om een reël te toets nie: bestaande inskrywings hou hul vroeëre kaart, en die spoel breek alles anders op die gasheer. Om ’n poort te publiseer definieer bereikbaarheid. Dit definieer nie die antwoordpad nie. Skryf die gekose ontwerp neer met sy tabelname, sodat die volgende persoon dit nie tydens ’n insident herontdek nie.

Verwante artikels