Meshnet, Docker at ang pahintulot sa pagitan
Ang isang peer ng mesh na umabot sa isang publikadong container ay tumatawid sa pahintulot ng host at sa pagsasalin ng Docker. Suriin ang dalawa nang hiwalay o maaaprubahan mo ang maling saklaw.
Dalawang URL ay maaaring magmukhang magkapareho mula sa browser ng isang peer at gayon pa man ay ibang-iba ang ibig sabihin para sa firewall. Ang isa ay tumuturo sa isang serbisyo na nakikinig sa host mismo. Ang isa ay tumuturo sa isang address ng host na ang port ay publikado sa isang container network, kung saan ang isang hakbang ng pagsasalin ay inihahatid ang koneksyon sa ibang IP. Sa isang mesh na peer-to-peer na kumokontrol sa pag-access sa lokal na network gamit ang pahintulot sa bawat peer, ang pagkakaibang iyon ang buong pagsusuri.
Ang pahintulot ay tungkol sa endpoint ng host, ang pagsasalin ay tungkol sa Docker, at ang pag-login ay tungkol sa aplikasyon. Tatlong desisyon, tatlong lugar na titingnan.
Sundin ang destinasyon pagkatapos ng publikasyon
Kumuha ng host na Linux Docker na nagpapublikado ng port 80 ng isang container sa port 8080 ng host. Kumokonekta ang isang peer sa address ng mesh ng host sa 8080, tinatanggap ng host ang koneksyon, at muling isinusulat ng isang pagsasalin ng destinasyon ito patungo sa address ng tulay ng container, karaniwang isang bagay na tulad ng 172.17.0.2 sa port 80.
Sa oras na suriin ng isang patakaran ang daloy na iyon, ang kawili-wiling destinasyon ay ang container, hindi ang host. Ang isang patakaran na nangangatuwiran lamang tungkol sa «isang serbisyo sa makinang ito» ay nangangatuwiran tungkol sa maling bagay. Dumapo ang kahilingan sa host, ngunit inihahatid ito sa ibang lugar.
Iyon ang dahilan kung bakit inililista ng dokumentasyon ng mesh ang mga container ng Docker sa mga resource na kinokontrol ng pahintulot sa lokal na network sa Linux. Ang pahintulot ay hindi kasingkahulugan ng ordinaryong entry sa listahan ng pinapayagan ng VPN, at ang dalawang kontrol ay hindi nagpapalitan. Ang isa ay nagpapasya kung ang isang peer ay makakaabot sa mga lokal na resource; ang isa ay nagpapasya kung aling mga destinasyon ang dinadala ng isang rutang naka-tunnel.
Magpasya kung gaano karaming lokal na pag-access ang ibinibigay ng isang pahintulot
Ang pagbibigay ng pag-access sa lokal na network sa isang peer ay hindi desisyon tungkol sa isang container. Maaari nitong ilantad ang iba pang publikadong serbisyo sa parehong host, at maaari itong umabot nang mas malayo depende sa kung paano ipinapasa ng host. Suriin ang epektibong saklaw bago pindutin ang switch para sa isang dashboard.
Pagkatapos ay tingnan kung saan ipinapublikado ng Docker ang port. Ang publikasyon sa 0.0.0.0 ay lumilikha ng tagapakinig sa bawat address ng host, na maaaring magdagdag ng ordinaryong entry sa LAN kasama ng entry ng mesh. Kung ang pangangailangan ay mesh lamang, itali ang publikasyon sa partikular na address o interface na nilalayon mo, at ituring ang mas malawak na pagtali bilang hiwalay na natuklasan at hindi bilang kaginhawahan.
Panatilihing sapat na makitid para sa serbisyo ang patakaran sa pagpapasa ng host at ang sariling pagpapatunay ng aplikasyon. Ang isang URL na mukhang pribado ay hindi kontrol sa pag-access, at ang isang container na nagtitiwala sa bawat pinagmulan sa network ng tulay nito ay hindi protektado ng katotohanang naaprubahan ang peer ng mesh. Ang pagpapatunay ng aplikasyon ang ikatlong desisyon, at ito lamang ang nakakaalam kung sino ang gumagamit. Ang pahintulot sa antas ng host ay hindi makapagbibigay ng kaalamang iyon.
Subukan ang pahintulot, hindi lamang ang URL
Mula sa naaprubahang peer, buksan ang eksaktong serbisyo at kumpirmahing gumagana ito. Pagkatapos ay subukan ang isang destinasyon na dapat manatiling tinatanggihan at kumpirmahing hindi ito gumagana. Ang pagsubok lamang sa masayang landas ay nagsasabi sa iyo na ibinigay ang pahintulot; hindi nito sinasabi na ang hangganan ay nasa lugar na iniisip mo.
Ihambing nang hiwalay ang isang serbisyong katutubo sa host. Kung ang isang database ay nakikinig sa host at ang isang dashboard ay tumatakbo sa isang container, sinusundan nila ang magkaibang landas sa parehong pahintulot at maaaring hindi pantay na kontrolin ng patakaran sa pagpapasa ng host. Itala kung alin ang alin bago isulat ang tala ng pagsusuri.
Huwag burahin ang mga talahanayan ng Docker o ang mga patakaran ng kliyente ng mesh para «i-reset» ang pag-access. Ang parehong produkto ay naglalagay ng kanilang sariling integrasyon ng patakaran, at ang pagbura nito ay lumilikha ng host na mukhang gumagana habang nilalampasan ang mga kontrol na hiniling sa iyong suriin. Kung ang isang patakaran ay mukhang mali, basahin ito at baguhin lamang ang patakarang iyon. Kung hindi mo maipaliwanag kung ano ang ginagawa ng isang patakaran, iyon ang natuklasan, hindi dahilan upang burahin ito.
Isulat ang natuklasan sa mga termino ng system mismo
Ang mahalaga ay ang pagkakaibang aktwal na ipinatutupad ng produkto, hindi ang nasa template ng pagsusuri: pahintulot na maabot ang endpoint ng host, pahintulot na maabot ang mga ruta na pribadong resource, at pahintulot na gamitin ang aplikasyon. Ang pagpapublikado ng port ay iniiwan ang tatlong desisyong iyon nang eksakto kung nasaan sila, at ang isang tagasuri na itinuturing silang isa ay maaaprubahan ang maling saklaw.
Isulat ang address ng host, ang publikadong port, ang destinasyon ng container at ang pahintulot ng peer sa iisang pangungusap. Ang pangungusap na iyon ay masusubukan ng ibang tao, at iyon ang dahilan kung bakit ito ay natuklasan at hindi opinyon.