{"id":41051,"date":"2020-02-05T21:28:58","date_gmt":"2020-02-05T18:28:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/consul-iptables-3"},"modified":"2020-02-05T21:28:58","modified_gmt":"2020-02-05T18:28:58","slug":"consul-iptables-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/consul-iptables-3","title":{"rendered":"Consul + iptables = :3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I 2010 havde virksomheden <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/wargaming\/\">Wargaming<\/a><\/noindex> 50 servere og en simpel netv\u00e6rksmodel: backend, frontend og firewall. Antallet af servere voksede, modellen blev mere kompleks: staging, isolerede VLAN med ACL, derefter VPN med VRF, VLAN med ACL p\u00e5 L2, VRF med ACL p\u00e5 L3. Har du f\u00e5et hovedpine? Det bliver sjovere.<\/p>\n<p>Da antallet af servere n\u00e5ede 16.000, blev det umuligt at arbejde med s\u00e5 mange forskellige segmenter uden problemer. Derfor fandt vi en anden l\u00f8sning. Vi tog Netfilter-stakken, tilf\u00f8jede Consul som datakilde, og fik en hurtig distribueret firewall. Den erstattede ACL p\u00e5 routerne og blev brugt som en ekstern og intern firewall. For dynamisk styring af v\u00e6rkt\u00f8jet udviklede vi systemet BEFW, som blev anvendt overalt: fra brugeradgangsstyring i produktnetv\u00e6rket til isolering af netv\u00e6rkssegmenter fra hinanden.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/246e74278f413749a676599b5ce986a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvordan det hele fungerer, og hvorfor du skal holde \u00f8je med dette system, vil <strong>Ivan Agarov<\/strong> (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/annmuor\/\" class=\"user_link\">annmuor<\/a><\/noindex>) \u2014 leder af infrastruktur sikkerhedsgruppen i Maintenance-afdelingen ved Wargaming's Minsk udviklingscenter. Ivan er en fan af SELinux, elsker Perl, skriver kode. Som leder af cybersikkerhed, arbejder han regelm\u00e6ssigt med logs, backups og R&amp;D for at beskytte Wargaming mod hackere og sikre driften af alle spilserverne i virksomheden.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"4zP67uYnsR4\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/4zP67uYnsR4\/hqdefault.jpg\" alt=\"Afspil video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Historisk baggrund<\/h2>\n<p>\nF\u00f8r jeg fort\u00e6ller, hvordan vi gjorde det, vil jeg forklare, hvordan vi kom dertil, og hvorfor det var n\u00f8dvendigt. For at g\u00f8re det, lad os g\u00e5 tilbage 9 \u00e5r: til 2010, da World of Tanks lige var kommet.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/64e1c2839363dbdf59ba5f11bb13530e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Diagram over v\u00e6ksten i virksomhedens servere.<\/em><\/p>\n<p>Vi havde en netv\u00e6rksmodel. P\u00e5 det tidspunkt var det optimal.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/c0509324e2a83882a9792ba75612ceea.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Netv\u00e6rksmodel i 2010.<\/em><\/p>\n<p>P\u00e5 frontend bor de d\u00e5rlige fyre, der \u00f8nsker at bryde os, men der er en firewall. P\u00e5 backend er der ingen firewall, men der er 50 servere, vi kender dem alle. Alt fungerer godt.<\/p>\n<p>P\u00e5 4 \u00e5r voksede serverparken 100 gange til 5000. De f\u00f8rste isolerede netv\u00e6rk dukkede op - staging: de kan ikke komme til produktionen, og der k\u00f8rte ofte noget, der kunne v\u00e6re farligt.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/08e1d7670ce1a1346e49d87c67c4be1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Netv\u00e6rksmodel i 2014.<\/em><\/p>\n<p>Vi fortsatte med at bruge de samme hardware, og alt arbejde blev udf\u00f8rt p\u00e5 isolerede VLAN: der skrives ACL til VLAN, der tillader eller forhindrer en bestemt forbindelse.<\/p>\n<p>I 2016 n\u00e5ede antallet af servere op p\u00e5 8000. Wargaming opk\u00f8bte andre studier, og der kom flere partnerskaber til. De virker til at v\u00e6re vores, men er ikke helt: for partnere fungerer VLAN ofte ikke, s\u00e5 vi er n\u00f8dt til at bruge VPN med VRF, hvilket komplicerer isoleringen. En blanding af ACL-isolationer voksede.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/a6580c9551730447e16d7881eb102275.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Netv\u00e6rksmodellen i 2016.<\/em><\/p>\n<p>Ved udgangen af 2018 var maskinparken vokset til 16.000. Der var 6 segmenter, og vi talte ikke de andre, herunder de lukkede, hvor finansielle data blev opbevaret. Container-netv\u00e6rk (Kubernetes), DevOps, cloud-netv\u00e6rk, der var tilsluttet via VPN, eksempelvis fra IWS, dukkede op. Der var mange regler \u2013 det var smertefuldt.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/ec44e6a60da98daa4bbf2bca2e3b2e1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Netv\u00e6rksmodellen og isolationsmetoderne i 2018.<\/em><\/p>\n<p>Til isolation brugte vi: VLAN med ACL p\u00e5 L2, VRF med ACL p\u00e5 L3, VPN og meget mere. Alt for meget.<\/p>\n<h2>Problemer<\/h2>\n<p>\nAlle lever med ACL og VLAN. Hvad er overhovedet galt? P\u00e5 det sp\u00f8rgsm\u00e5l vil Harold svare og skjule smerten.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/4df5105af3bce515d80e8e5f3e14c027.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer var mange problemer, men f\u00e5 massive.<\/p>\n<ul>\n<li><strong>Geometrisk prisstigning for de nye regler<\/strong>. Hver ny regel tog l\u00e6ngere tid at tilf\u00f8je end den forrige, fordi man f\u00f8rst skulle se, om der allerede fandtes en s\u00e5dan regel.<\/li>\n<li><strong>Der er ingen firewall inden i segmenterne<\/strong>. Segmenterne blev p\u00e5 en m\u00e5de adskilt fra hinanden, men der var allerede ikke nok ressourcer indeni.<\/li>\n<li><strong>Reglerne blev anvendt lang tid. <\/strong>Ved hj\u00e6lp af h\u00e6nderne kunne operat\u00f8rerne skrive \u00e9n lokal regel p\u00e5 en time. En global regel tog flere dage.<\/li>\n<li><strong>Udfordringer med regelefterlevelse<\/strong>. Mere pr\u00e6cist, det var umuligt. De f\u00f8rste regler blev skrevet tilbage i 2010, og st\u00f8rstedelen af deres forfattere arbejdede ikke l\u00e6ngere i virksomheden.<\/li>\n<li><strong>Lav kontrol over infrastrukturen<\/strong>. Det er det st\u00f8rste problem \u2013 vi vidste d\u00e5rligt, hvad der egentlig skete.<\/li>\n<\/ul>\n<p>\nS\u00e5dan s\u00e5 netv\u00e6rksingeni\u00f8ren ud i 2018, n\u00e5r han h\u00f8rte: 'Vi har brug for lidt flere ACL.'<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/8366d3092558ebb15a4ba6d8e5702032.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>L\u00f8sninger<\/h2>\n<p>\nI begyndelsen af 2018 blev det besluttet at g\u00f8re noget ved det.<\/p>\n<p><strong>Prisen for integrationer stiger kontinuerligt. <\/strong>Udgangspunktet var, at store datacentre stoppede med at underst\u00f8tte isolerede VLAN og ACL, fordi hukommelsen p\u00e5 enhederne var opbrugt.<\/p>\n<p>L\u00f8sningen: at fjerne menneskeligt faktorer og maksimalt automatisere adgangsudstedelsen.<\/p>\n<p><strong>Nye regler anvendes langsomt. <\/strong>L\u00f8sningen: at fremskynde anvendelsen af reglerne, g\u00f8re den distribueret og parallel. Til dette er der brug for et distribueret system, s\u00e5 reglerne kan leveres direkte, uden rsync eller SFTP til tusind systemer.<\/p>\n<p><strong>Manglende firewall inden i segmenterne. <\/strong>Firewall inden for segmenter begyndte at komme til os, n\u00e5r forskellige tjenester opstod inden for det samme netv\u00e6rk. L\u00f8sning: anvende en firewall p\u00e5 v\u00e6rtsniveau \u2014 host-baserede firewalls. Praktisk talt overalt har vi Linux, og der er iptables overalt, hvilket ikke er et problem.<\/p>\n<p><strong>Udfordringer med revision af regler.<\/strong> L\u00f8sning: gemme alle regler \u00e9t sted til oversigt og styring, s\u00e5 vi kan revidere dem alle.<\/p>\n<p><strong>Lav grad af kontrol over infrastrukturen. <\/strong>L\u00f8sning: foretage en opg\u00f8relse over alle tjenester og adgange imellem dem.<\/p>\n<p>Det er mere en administrativ proces end en teknisk. Nogle gange har vi 200-300 nye udgivelser om ugen, is\u00e6r under kampagner og helligdage. Dette er kun for \u00e9t af vores DevOps-hold. Med s\u00e5 mange udgivelser er det umuligt at forst\u00e5, hvilke porte, IP, integrationer der er n\u00f8dvendige. Derfor havde vi brug for s\u00e6rligt uddannede serviceledere, der stillede sp\u00f8rgsm\u00e5l til holdene: 'Hvad har I egentlig, og hvorfor satte I det op?'<\/p>\n<p>Efter alt, hvad vi har lanceret, s\u00e5 netv\u00e6rksingeni\u00f8ren i 2019 allerede s\u00e5dan ud.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/ccca25d7f7bb7f70638725addc6d99ed.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Consul<\/h2>\n<p>\nVi besluttede, at alt, hvad vi fandt ved hj\u00e6lp af serviceledere, ville blive gemt i Consul, og derfra ville vi skrive iptables-regler.<\/p>\n<p>Hvordan besluttede vi at g\u00f8re dette?<\/p>\n<ul>\n<li>Vi samler alle tjenester, netv\u00e6rk og brugere.<\/li>\n<li>Vi laver iptables-regler baseret p\u00e5 dem.<\/li>\n<li>Vi automatiserer kontrollen.<\/li>\n<li>\u2026.<\/li>\n<li>PROFIT.<\/li>\n<\/ul>\n<p>\nConsul er ikke en fjern API, det kan arbejde p\u00e5 hver node og skrive til iptables. Det er kun tilbage at finde ud af automatiske kontrolmidler, der kan rense un\u00f8dvendige ting, s\u00e5 det meste af problemerne vil v\u00e6re l\u00f8st! Det resterende klarer vi i processen.<\/p>\n<h3>Hvorfor Consul?<\/h3>\n<p>\n<strong>Har bevist sit v\u00e6rd. <\/strong>I 2014-15 brugte vi det som backend til Vault, hvor vi gemmer vores adgangskoder.<\/p>\n<p><strong>Taber ikke data<\/strong>. I l\u00f8bet af brugen har Consul ikke tabt data ved nogen fejl. Dette er en stor fordel for firewallstyringssystemet.<\/p>\n<p><strong>P2P-forbindelser fremskynder \u00e6ndringsudbredelse<\/strong>. Med P2P kommer alle \u00e6ndringer hurtigt, man skal ikke vente i timer.<\/p>\n<p><strong>Brugervenlig REST API.<\/strong> Vi overvejede ogs\u00e5 Apache ZooKeeper, men det har ikke en REST API, s\u00e5 vi skal lave l\u00f8sninger.<\/p>\n<p><strong>Fungerer som b\u00e5de en n\u00f8glelagring (KV) og som et katalog (Service Discovery)<\/strong>. Man kan gemme b\u00e5de tjenester, kataloger og datacentre. Dette er praktisk ikke kun for os, men ogs\u00e5 for de tilst\u00f8dende teams, da vi bygger en global tjeneste og t\u00e6nker stort.<\/p>\n<p><strong>Skrrevet i Go, som er en del af Wargaming-stakken. <\/strong>Vi elsker dette sprog, vi har mange Go-udviklere.<\/p>\n<p><strong>Mighty ACL-system. <\/strong>Med ACL i Consul kan man styre, hvem der skriver og hvad. Vi sikrer, at firewall-reglerne ikke overlapper med noget som helst, og at vi ikke f\u00e5r problemer med det.<\/p>\n<p>Men Consul har ogs\u00e5 ulemper.<\/p>\n<ul>\n<li><strong>Det skalerer ikke inden for datacenteret, medmindre du har business-versionen. <\/strong>Det skalerer kun via federation.<\/li>\n<li><strong>Meget afh\u00e6ngig af kvaliteten af netv\u00e6rket og serverbelastningen. <\/strong>Consul vil ikke fungere ordentligt som server p\u00e5 en belastet server, hvis nettet har hakker, f.eks. uregelm\u00e6ssige hastigheder. Dette skyldes P2P-forbindelser og opdateringsmodeller.<\/li>\n<li><strong>Vanskeligheder med at overv\u00e5ge tilg\u00e6ngelighed<\/strong>. I Consul-status kan det sige, at alt er godt, men den er faktisk d\u00f8d for l\u00e6nge siden.<\/li>\n<\/ul>\n<p>\nDe fleste af disse problemer har vi l\u00f8st under drift af Consul, derfor valgte vi det. Virksomheden har planer om en alternativ backend, men vi har l\u00e6rt at h\u00e5ndtere problemerne og lever stadig med Consul.<\/p>\n<h3>S\u00e5dan fungerer Consul<\/h3>\n<p>\nI et hypotetisk datacenter installerer vi servere - fra tre til fem. En eller to servere er ikke tilstr\u00e6kkelige: de kan ikke danne quorum og afg\u00f8re, hvem der er korrekt, n\u00e5r dataene ikke stemmer overens. Mere end fem giver ikke mening, da ydeevnen vil falde.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/96153c4e9075b067b34a63ceba5b80f0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKlienter tilsluttes serverne i vilk\u00e5rlig r\u00e6kkef\u00f8lge: de samme agenter, kun med flaget <code>server = false<\/code>.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/0854d1286c18bb5e7c1130c6734154a9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEfter dette f\u00e5r klienterne en liste over P2P-forbindelser og opbygger forbindelser imellem hinanden.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/2457cb7707c27cc23f6e13415119b91d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00e5 globalt plan forbinder vi flere datacentre. De er ogs\u00e5 forbundet P2P og kommunikerer.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/3b4ae922eb8d2a6a9a79425e769505d7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00e5r vi \u00f8nsker at hente data fra et andet datacenter, g\u00e5r anmodningen fra server til server. Denne ops\u00e6tning kaldes <strong>Serf-protokollen<\/strong>. Serf-protokollen, ligesom Consul, er udviklet af HashiCorp.<\/p>\n<h3>Nogle vigtige fakta om Consul<\/h3>\n<p>\nConsul har dokumentation, der beskriver dets funktion. Jeg vil kun n\u00e6vne udvalgte fakta, som er v\u00e6rd at vide.<\/p>\n<p><strong>Consul-servere v\u00e6lger en leder blandt de stemmeberettigede<\/strong>. Consul v\u00e6lger en leder fra listen af servere for hvert datacenter, og alle anmodninger g\u00e5r kun til ham, uanset antallet af servere. Hvis lederen h\u00e6nger, f\u00f8rer det ikke til nyvalg. Hvis ingen leder er valgt, behandles anmodningerne af ingen.<\/p>\n<blockquote><p>\u00d8nskede du horisontal skalering? Beklager, det er ikke muligt.<\/p><\/blockquote>\n<p> Anmodningen til et andet datacenter g\u00e5r fra master til master, uanset hvilken server den kommer til. Den valgte master modtager 100% af belastningen, bortset fra belastningen ved at videresende anmodninger. Den aktuelle kopi af data er tilg\u00e6ngelig p\u00e5 alle servere i datacentret, men kun \u00e9n svarer.<\/p>\n<blockquote><p>Den eneste m\u00e5de at skalere p\u00e5 er at aktivere stale-tilstand p\u00e5 klienten.<\/p><\/blockquote>\n<p>I stale-tilstand kan man svare uden quorum. Det er en tilstand, hvor vi opgiver datakonsistens, men l\u00e6ser en smule hurtigere end normalt, og alle servere kan svare. Selvf\u00f8lgelig skrives der kun gennem masteren.<\/p>\n<p><strong>Consul kopierer ikke data mellem datacentre.<\/strong>Ved ops\u00e6tning af federation vil hver server kun have sine egne data. For andre vil den altid henvende sig til en anden.<\/p>\n<p><strong>Atomaritet af operationer garanteres ikke uden for transaktioner.<\/strong>Husk, at ikke kun du kan \u00e6ndre noget. Hvis du vil have det anderledes, skal du udf\u00f8re en transaktion med l\u00e5sning.<\/p>\n<p><strong>L\u00e5sende operationer garanterer ikke l\u00e5sning.<\/strong>Anmodningen g\u00e5r fra master til master og ikke direkte, s\u00e5 der er ingen garanti for, at l\u00e5sningen vil fungere, n\u00e5r du laver en l\u00e5sning, for eksempel i et andet datacenter.<\/p>\n<p><strong>ACL garanterer heller ikke adgang (i mange tilf\u00e6lde).<\/strong>ACL kan m\u00e5ske ikke fungere, fordi den opbevares i \u00e9t datacenter i federation \u2014 i ACL-datacenteret (Prim\u00e6rt DC). Hvis DC ikke svarer, vil ACL ikke fungere.<\/p>\n<p><strong>En fastl\u00e5st master vil medf\u00f8re, at hele federation fryser.<\/strong>For eksempel, i en federation med 10 datacentre, og i \u00e9t er der en d\u00e5rlig forbindelse, og \u00e9n master falder. Alle, der kommunikerer med den, fryser i en cyklus: der g\u00e5r en anmodning, der er ikke noget svar, tr\u00e5den fryser. Man kan ikke vide, hvorn\u00e5r dette vil ske, bare efter en time eller to vil hele federation falde. Du kan ikke g\u00f8re noget ved det.<\/p>\n<p>Status, quorum og valg behandles af en separat tr\u00e5d. Der vil ikke ske genvalg, status viser ingenting. Du tror, at din Consul er aktiv, anmoder, og der sker ingenting \u2014 der er intet svar. I mellemtiden viser status, at alt er i orden.<\/p>\n<p>Vi har st\u00f8dt p\u00e5 dette problem, vi har v\u00e6ret n\u00f8dt til at ombygge specifikke dele af datacentre for at undg\u00e5 det.<\/p>\n<p><strong>I erhvervsversionen af Consul Enterprise mangler nogle af de tidligere n\u00e6vnte ulemper.<\/strong>Det har mange nyttige funktioner: valg af afstemmer, fordeling, skalering. Der er kun \u00e9n 'men' - licenssystemet til det distribuerede system er meget dyrt.<\/p>\n<p>Lifehack: <code>rm -rf \/var\/lib\/consul<\/code> \u2014 medicinen mod alle agentens sygdomme. Hvis noget ikke virker, s\u00e5 slet bare dine data og hent data fra en kopi. Sandsynligvis vil Consul fungere igen.<\/p>\n<h2>BEFW<\/h2>\n<p>\nLad os nu tale om, hvad vi har tilf\u00f8jet til Consul.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wgnet\/befw\">BEFW<\/a><\/noindex> \u2014 det er en forkortelse for <strong>B<\/strong>ack<strong>E<\/strong>nd<strong>F<\/strong>ire<strong>W<\/strong>alle. Jeg m\u00e5tte finde p\u00e5 et navn til produktet, da jeg oprettede repoet for at l\u00e6gge de f\u00f8rste test commits ind. S\u00e5dan et navn blev det.<\/p>\n<h3>Regelm\u00f8nstre<\/h3>\n<p>\nReglerne er skrevet i iptables-syntax.<\/p>\n<ul>\n<li>-N BEFW<\/li>\n<li>-P INPUT DROP<\/li>\n<li>-A INPUT -m state\u2014state RELATED,ESTABLISHED -j ACCEPT<\/li>\n<li>-A INPUT -i lo -j ACCEPT<\/li>\n<li>-A INPUT -j BEFW<\/li>\n<\/ul>\n<p>\nAlt g\u00e5r til k\u00e6den BEFW, bortset fra <code>ESTABLISHED<\/code>, <code>RELATED<\/code> og localhost. M\u00f8nstret kan v\u00e6re hvilket som helst, dette er bare et eksempel.<\/p>\n<p>Hvad er BEFW godt for?<\/p>\n<h3>Tjenester<\/h3>\n<p>\nVi har en service, den har altid en port, noden hvor den k\u00f8rer. Fra vores node kan vi lokalt sp\u00f8rge agenten og finde ud af, at vi har en eller anden service. Man kan ogs\u00e5 s\u00e6tte tags.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/6d8c74db37e2e1eed971cfa6947cc5c8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEnhver service, der k\u00f8rer og er registreret i Consul, bliver til en iptables regel. Vi har SSH - vi \u00e5bner port 22. Bash-scriptet er enkelt: curl og iptables, der er ikke brug for mere.<\/p>\n<h3>Klienter<\/h3>\n<p>\nHvordan \u00e5bner man adgang for nogle f\u00e5, men ikke for alle? Ved at navngive service og l\u00e6gge IP-lister i KV-lageret.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/11a5af5aad9e848565458f168a1eee64.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor eksempel \u00f8nsker vi, at alle fra det tiende netv\u00e6rk kan tilg\u00e5 SSH_TCP_22 servicen. Vi tilf\u00f8jer et lille felt TTL? og nu har vi tidsbegr\u00e6nsede tilladelser, for eksempel i et d\u00f8gn.<\/p>\n<h3>Adgang<\/h3>\n<p>\nVi forbinder tjenester og klienter: vi har en service, for hver er der et klart KV-lager. Nu giver vi adgang ikke til alle, men selektivt.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/d1119fbb226595184cac8d9ce7a924e3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Grupper<\/h3>\n<p>\nHvis vi hver gang skal skrive tusindvis af IP'er for adgang, bliver vi tr\u00e6tte. Lad os finde p\u00e5 grupperinger - et separat subset i KV. Lad os kalde det Alias (eller grupper), og vi vil gemme grupper der efter samme princip.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/67c6ab76cc25a3973739bdd44b69cef9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nForbindelser: nu kan vi \u00e5bne SSH ikke specifikt p\u00e5 P2P, men til en hel gruppe eller flere grupper. P\u00e5 samme m\u00e5de er der TTL - man kan midlertidigt tilf\u00f8je eller fjerne medlemmer fra gruppen.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/a00b7db5087a96730c2725090f33e2b0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Integration<\/h3>\n<p>\nVores problem \u2014 menneskelig faktor og automatisering. Indtil videre har vi l\u00f8st det s\u00e5dan.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/ce7a0c16543d0624453e6bdada3b8f03.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi arbejder med Puppet og overf\u00f8rer alt, der vedr\u00f8rer systemet (applikationskode). I puppetdb (almindelig PostgreSQL) opbevares en liste over de tjenester, der k\u00f8rer d\u00e9r, som kan findes efter ressource-type. Her kan man ogs\u00e5 finde ud af, hvem der henvender sig til hvem. Vi har ogs\u00e5 et system for pull request og merge request til dette.<\/p>\n<p>Vi har skrevet befw-sync \u2014 en simpel l\u00f8sning, der hj\u00e6lper med at overf\u00f8re data. F\u00f8rst henvender sync cookies sig til puppetdb. Der er opsat et HTTP API: vi sp\u00f8rger, hvilke tjenester vi har, og hvad der skal g\u00f8res. Derefter foretages en anmodning til Consul.<\/p>\n<p>Er der en integration? Ja: vi har skrevet regler, der tillader at acceptere Pull Requests. Skal der v\u00e6re en port eller tilf\u00f8je en v\u00e6rt til en bestemt gruppe? Pull Request, review \u2014 ikke flere \u00abFind 200 andre ACL'er og pr\u00f8v at g\u00f8re noget med det\u00bb.<\/p>\n<h3>Optimering<\/h3>\n<p>\nPing til localhost med en tom regelk\u00e6de tager 0,075 ms.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/39263844f79c4795af05dc3ecb734394.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi tilf\u00f8jer 10.000 adresser til iptables i denne k\u00e6de. Som et resultat vil ping stige 5 gange: iptables er helt line\u00e6rt, behandlingen af hver adresse tager noget tid.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/e6c314155c3a34fdf61e40479ecb26c3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor den firewall, som vi migrerer tusindvis af ACL'er til, har vi mange regler, og det medf\u00f8rer forsinkelse. Det er d\u00e5rligt for spileprotokoller.<\/p>\n<p>Men hvis vi placerer <strong>10.000 adresser i ipset<\/strong> , vil ping endda falde.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/2dd844d9324d057ba9ab098e501a1e51.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPointen er, at \u00abO\u00bb (algoritmens kompleksitet) for ipset altid er 1, uanset hvor mange regler der er. Dog er der en gr\u00e6nse \u2014 der kan ikke v\u00e6re mere end 65535 regler. Indtil videre lever vi med det: vi kan kombinere dem, udvide dem og lave to ipset i \u00e9n.<\/p>\n<h3>Lagring<\/h3>\n<p>\nEn logisk forts\u00e6ttelse af iterasjonsprocessen er at opbevare information om kunderne til tjenesten i ipset.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/126069799d95594be8611237e935189d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNu har vi den samme SSH, og vi skriver ikke blot 100 IP'er med det samme, men angiver navnet p\u00e5 ipset, som vi skal kommunikere med, og den n\u00e6ste regel <code>DROP<\/code>. Det kan g\u00f8res til \u00e9n regel \u00abDen, der ikke er her, bliver DROP\u00bb, men det er mere overskueligt s\u00e5dan.<\/p>\n<p>Nu har vi regler og s\u00e6t. Hovedopgaven er at lave s\u00e6ttet, inden vi skriver reglen, for ellers vil iptables ikke registrere reglen.<\/p>\n<h3>Generelt skema<\/h3>\n<p>\nSom en skitse ser alt, hvad jeg har fortalt, s\u00e5ledes ud.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/4046e921cb5f466f8af5a6af1fcd151c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi committer til Puppet, alt sendes til v\u00e6rten, tjenesterne er her, ipset der, og dem, der ikke er registreret der, f\u00e5r ikke adgang.<\/p>\n<h3>Allow &amp; deny<\/h3>\n<p>\nFor hurtigt at redde verden eller hurtigt at koble nogen fra har vi lavet to ipset i begyndelsen af alle k\u00e6der: <code>rules_allow<\/code> og <code>rules_deny<\/code>. Hvordan fungerer det?<\/p>\n<p>For example, someone creates a load on our Web using bots. In the past, it was necessary to find their IP from logs, report it to network engineers to trace the traffic source, and ban it. Now it looks different.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/6e7f906919536cab2c283ba6ceb0472d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWe send to Consul, wait 2.5 seconds, and it's done. Since Consul quickly distributes the load via P2P, it works everywhere, in any part of the world.<\/p>\n<p>Once, I completely stopped WOT by mistakenly configuring the firewall. <code>rules_allow<\/code> \u2014 this is our insurance against such cases. If we mistakenly configure the firewall somewhere and something gets blocked, we can always send a conditional <code>0.0\/0<\/code>, to quickly bring everything back up. We can fix everything manually later.<\/p>\n<h3>Other sets<\/h3>\n<p>\nYou can add any other sets in the space <code>$IPSETS$<\/code>.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/4e1e337b35da81cd7324b2adc106b085.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWhy? Sometimes someone needs ipset, for example, to emulate turning off some part of the cluster. Anyone can bring any sets, name them, and they will be fetched from Consul. At the same time, sets can participate in iptables rules or act as a command. <code>NOOP<\/code>: consistency will be maintained by the daemon.<\/p>\n<h3>Brugere<\/h3>\n<p>\nIt used to be: the user connected to the network and received parameters through the domain. Before the advent of next-gen firewalls, Cisco couldn't understand where the user was and where the IP was. Therefore, access was only granted via the hostname of the machine.<\/p>\n<p>What did we do? We intervened at the point of address retrieval. Usually, this is dot1x, Wi-Fi, or VPN \u2014 everything goes through RADIUS. For each user, we create a group named after the user and place the IP in it with a TTL equal to their dhcp.lease \u2014 as soon as it expires, the rule disappears.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/04550475c6af49d094c18b1d5b89123a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNow we can open access to services, like in other groups, by username. We eliminated the pain of hostname changes and relieved network engineers since they no longer require Cisco. Now the engineers configure access on their servers themselves.<\/p>\n<h3>Isolation<\/h3>\n<p>\nMeanwhile, we started addressing isolation. Service managers conducted an inventory, and we analyzed all our networks. We will break them into similar groups and added them, for example, to deny on the necessary servers. Now the same staging isolation goes into rules_deny of production but not into production itself.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/60fe7407013aa64b853791f8def627cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe scheme works quickly and simply: we remove all ACLs from servers, unload the hardware, and reduce the number of isolated VLANs.<\/p>\n<h3>Integrity control<\/h3>\n<p>\nTidligere havde vi en speciel trigger, der gav besked, n\u00e5r nogen manuelt \u00e6ndrede firewallreglerne. Jeg skrev en enorm linter til kontrol af firewallregler, det var besv\u00e6rligt. Nu opretholder BEFW integriteten. Den holder n\u00f8je \u00f8je med, at de regler, den angiver, ikke \u00e6ndres. Hvis nogen \u00e6ndrer firewallreglerne, vil den bringe alt tilbage. \"Jeg satte hurtigt en proxy op for at arbejde hjemmefra\" \u2014 s\u00e5dan nogle muligheder findes ikke l\u00e6ngere.<\/p>\n<p>BEFW overv\u00e5ger ipset fra tjenesterne og listen i befw.conf, service reglerne i BEFW-k\u00e6den. Men den overv\u00e5ger ikke andre k\u00e6der og regler samt andre ipset.<\/p>\n<h3>Beskyttelse mod nedbrud<\/h3>\n<p>\nBEFW gemmer altid den sidste succesfulde tilstand direkte i den bin\u00e6re struktur state.bin. Hvis noget g\u00e5r galt, vil den altid g\u00e5 tilbage til denne state.bin.<\/p>\n<p><img decoding=\"async\" alt=\"Consul + iptables = :3\" src=\"\/wp-content\/uploads\/2020\/02\/724f3537c06a7135fa6397f9ddd5630f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er en sikkerhed mod ustabil drift af Consul, n\u00e5r den ikke har sendt data eller nogen har lavet en fejl og brugt regler, der ikke kan anvendes. For at vi ikke st\u00e5r uden en firewall, vil BEFW g\u00e5 tilbage til den sidste tilstand, hvis der opst\u00e5r en fejl p\u00e5 et tidspunkt.<\/p>\n<p>I kritiske situationer er dette en garanti for, at vi forbliver med en fungerende firewall. Vi \u00e5bner alle gr\u00e5 netv\u00e6rk i h\u00e5bet om, at administrationen kommer og reparerer det. En dag vil jeg inkludere dette i konfigurationerne, men lige nu har vi simpelthen tre gr\u00e5 netv\u00e6rk: 10\/8, 172\/12 og 192.168\/16. Inden for vores Consul er dette en vigtig funktion, der hj\u00e6lper os med at udvikle os videre.<\/p>\n<p><em>Demo: under pr\u00e6sentationen viser Ivan demo-tilstanden for BEFW. Det er nemmere at se demonstrationen p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/4zP67uYnsR4?t=1663\">en video<\/a><\/noindex>. Kildeteksten til demoen er tilg\u00e6ngelig <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wgnet\/befw\/tree\/master\/demo\">p\u00e5 GitHub<\/a><\/noindex>.<\/em><\/p>\n<h2>Faldgruber<\/h2>\n<p>\nJeg vil fort\u00e6lle om de fejl, vi st\u00f8dte p\u00e5.<\/p>\n<p><strong>ipset add set 0.0.0.0\/0. <\/strong>Hvad sker der, hvis man tilf\u00f8jer 0.0.0.0\/0 til ipset? Bliver alle IP\u2019er tilf\u00f8jet? \u00c5bner der adgang til internettet? <\/p>\n<p>Nej, vi f\u00e5r en fejl, der kostede os to timers nedetid. Desuden har fejlen ikke fungeret siden 2016, og den ligger i RedHat Bugzilla under nummer #1297092, og vi fandt den tilf\u00e6ldigt \u2014 fra udviklerens rapport.<\/p>\n<p>Nu er der i BEFW en streng regel om, at <code>0.0.0.0\/0<\/code> bliver til to adresser: <code>0.0.0.0\/1<\/code> og <code>128.0.0.0\/1<\/code>.<\/p>\n<p><strong>ipset restore set &lt; file. <\/strong>Hvad g\u00f8r ipset, n\u00e5r du siger til den <code>restore<\/code>? \u0412\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u043e\u043d \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0442\u0430\u043a\u0436\u0435, \u043a\u0430\u043a iptables? \u0412\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442 \u0434\u0430\u043d\u043d\u044b\u0435?<\/p>\n<p>Ikke noget lignende \u2014 den laver en sammenl\u00e6gning, og de gamle adresser forsvinder ikke, du lukker ikke adgangen.<\/p>\n<p>Vi fandt fejlen, mens vi testede isolation. Nu er der et ret komplekst system \u2014 i stedet for <code>restore<\/code> udarbejdes <code>create temp<\/code>, derefter <code>restore flush temp<\/code> og <code>restore temp<\/code>. Til slut swap: for atomaritet, fordi hvis man f\u00f8rst laver <code>flush<\/code> Og p\u00e5 det tidspunkt vil en eller anden pakke komme, og den vil blive afvist, og noget vil g\u00e5 galt. Derfor er der lidt sort magi.<\/p>\n<p><strong>consul kv get -datacenter=other. <\/strong>Som jeg allerede har n\u00e6vnt, tror vi, at vi anmoder om nogle data, men vi vil enten f\u00e5 data eller en fejl. Vi kan g\u00f8re dette lokalt gennem Consul, men selv i dette tilf\u00e6lde vil begge dele fryse.<\/p>\n<p>Den lokale Consul-kl client er et lag over HTTP API'et. Men den fryser bare og svarer ikke p\u00e5 Ctrl+C, Ctrl+Z eller noget som helst, kun p\u00e5 <code>kill -9<\/code> i den tilst\u00f8dende konsol. Vi st\u00f8dte p\u00e5 dette, da vi byggede et stort cluster. Men vi har ikke nogen l\u00f8sning endnu; vi forbereder os p\u00e5 at rette denne fejl i Consul.<\/p>\n<p><strong>Consul-lederen svarer ikke. <\/strong>Vores master i datacentre svarer ikke, vi t\u00e6nker: \"M\u00e5ske vil valgalgoritmen nu tr\u00e6de i kraft?\" <\/p>\n<p>Nej, det vil ikke ske, og overv\u00e5gningen vil ikke vise noget: Consul vil sige, at commit-indekset eksisterer, lederen er fundet, alt er godt.<\/p>\n<p>Hvordan k\u00e6mper vi med dette? <code>service consul restart<\/code> i cron hver time. Hvis du har 50 servere, er det ikke skr\u00e6mmende. N\u00e5r du har 16.000, vil du forst\u00e5, hvordan det fungerer.<\/p>\n<h2>Konklusion<\/h2>\n<p>\nI sidste ende har vi opn\u00e5et f\u00f8lgende fordele:<\/p>\n<ul>\n<li>100% d\u00e6kning af alle Linux-maskiner.<\/li>\n<li>Hastighed.<\/li>\n<li>Automation.<\/li>\n<li>Vi har befriet hardware og netv\u00e6rksingeni\u00f8rer fra slaveri.<\/li>\n<li>Mulighederne for integration, der er n\u00e6sten gr\u00e6nsel\u00f8se: enten med Kubernetes, Ansible eller Python.<\/li>\n<\/ul>\n<p>\n<strong>Ulemper<\/strong>: Consul, som vi nu skal leve med, og den h\u00f8je pris p\u00e5 fejl. Som eksempel, en gang i 18-tiden (primetime i Rusland) \u00e6ndrede jeg noget i netv\u00e6rkslisterne. Vi byggede netop isolation p\u00e5 BEFW. Jeg lavede et eller andet forkert, ser ud til, at jeg angav den forkerte maske, men alt gik ned p\u00e5 to sekunder. Overv\u00e5gningen lyser op, supportkonsulenten kommer l\u00f8bende: \"Alt ligger nede!\" Afdelingslederen blev gr\u00e5h\u00e5ret, da han forklarede forretningen, hvorfor det skete.<\/p>\n<p>Fejlen har s\u00e5 h\u00f8j en pris, at vi har udviklet vores egen komplekse forebyggelsesprocedure. Hvis du implementerer dette i en stor produktion, skal du ikke give master-tokenet over Consul til alle. Det vil ende d\u00e5rligt.<\/p>\n<p><strong>Omkostninger. <\/strong>Jeg har skrevet kode i 400 timer alene. Min supportteam p\u00e5 4 personer bruger 10 timer om m\u00e5neden p\u00e5 alles support. Sammenlignet med prisen p\u00e5 enhver ny generation af firewall er det gratis.<\/p>\n<p><strong>Planer. <\/strong>Den langsigtede plan er at finde en alternativ transport i stedet for eller som supplement til Consul. Det kunne v\u00e6re Kafka eller noget lignende. Men i de kommende \u00e5r vil vi leve med Consul.<\/p>\n<p>N\u00e6ste planer: integration med Fail2ban, med overv\u00e5gning, med nftables, muligvis med andre distributioner, metrics, udvidet overv\u00e5gning, optimering. St\u00f8tte til Kubernetes er ogs\u00e5 et sted i planerne, fordi vi i \u00f8jeblikket har flere klynger og lyst.<\/p>\n<p>Andre planer inkluderer:<\/p>\n<ul>\n<li>opdagelse af anomalier i trafikken;<\/li>\n<li>h\u00e5ndtering af netv\u00e6rkskort;<\/li>\n<li>st\u00f8tte til Kubernetes;<\/li>\n<li>pakket bygning for alle systemer;<\/li>\n<li>Web-UI.<\/li>\n<\/ul>\n<p>\nVi arbejder konstant p\u00e5 at udvide konfigurationen, \u00f8ge metrics og optimere.<\/p>\n<p><i>Deltag i projektet. Projektet er blevet fantastisk, men desv\u00e6rre er det stadig et projekt for \u00e9n person. Kom og <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wgnet\/befw\">GitHub <\/a><\/noindex>og pr\u00f8v at g\u00f8re noget: commit, teste, foresl\u00e5 noget, give din feedback.<\/i><\/p>\n<blockquote><p>I mellemtiden forbereder vi os p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/spb\/2020\">Saint HighLoad++<\/a><\/noindex>, som finder sted den 6. og 7. april i Sankt Petersborg, og vi inviterer udviklere af h\u00f8jtydende systemer <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/lectures\/propose?conference=hl2020-spb\">til at indsende en ans\u00f8gning om opl\u00e6g<\/a><\/noindex>. Erfarne talere ved allerede, hvad de skal g\u00f8re, mens vi anbefaler nybegyndere i opl\u00e6g at i det mindste <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/spb\/2020\/speakers\">pr\u00f8v<\/a><\/noindex>. Deltagelse i konferencen som taler har en r\u00e6kke fordele. Hvilke kan du l\u00e6se om i slutningen af <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/486142\/\">denne artikel<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/486842\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 2010 \u0433\u043e\u0434\u0443 \u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Wargaming \u0431\u044b\u043b\u043e 50 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u043f\u0440\u043e\u0441\u0442\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c: \u0431\u044d\u043a\u0435\u043d\u0434, \u0444\u0440\u043e\u043d\u0442\u0435\u043d\u0434 \u0438 \u0444\u0430\u0439\u0440\u0432\u043e\u043b. \u041a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0440\u043e\u0441\u043b\u043e, \u043c\u043e\u0434\u0435\u043b\u044c \u0443\u0441\u043b\u043e\u0436\u043d\u044f\u043b\u0430\u0441\u044c: \u0441\u0442\u0435\u0439\u0434\u0436\u0438\u043d\u0433\u0438, \u0438\u0437\u043e\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0435 VLAN \u0441 ACL, \u043f\u043e\u0442\u043e\u043c VPN \u0441 VRF, VLAN c ACL \u043d\u0430 L2, VRF \u0441 ACL \u043d\u0430 L3. \u0417\u0430\u043a\u0440\u0443\u0436\u0438\u043b\u0430\u0441\u044c \u0433\u043e\u043b\u043e\u0432\u0430? \u0414\u0430\u043b\u044c\u0448\u0435 \u0431\u0443\u0434\u0435\u0442 \u0432\u0435\u0441\u0435\u043b\u0435\u0435. \u041a\u043e\u0433\u0434\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0441\u0442\u0430\u043b\u043e 16 000 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0431\u0435\u0437 \u0441\u043b\u0435\u0437 \u0441 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":41052,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-41051","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 2010 \u0433\u043e\u0434\u0443 \u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Wargaming \u0431\u044b\u043b\u043e 50 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u043f\u0440\u043e\u0441\u0442\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c: \u0431\u044d\u043a\u0435\u043d\u0434, \u0444\u0440\u043e\u043d\u0442\u0435\u043d\u0434 \u0438 \u0444\u0430\u0439\u0440\u0432\u043e\u043b.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/consul-iptables-3\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Consul + iptables = :3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 2010 \u0433\u043e\u0434\u0443 \u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Wargaming \u0431\u044b\u043b\u043e 50 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u043f\u0440\u043e\u0441\u0442\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c: \u0431\u044d\u043a\u0435\u043d\u0434, \u0444\u0440\u043e\u043d\u0442\u0435\u043d\u0434 \u0438 \u0444\u0430\u0439\u0440\u0432\u043e\u043b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/consul-iptables-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-05T18:28:58+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-05T18:28:58+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Consul + iptables = :3 | ProHoster","description":"I 2010 havde Wargaming 50 servere og en simpel netv\u00e6rksmodel: backend, frontend og firewall.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/consul-iptables-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Consul + iptables = :3 | ProHoster","og:description":"\u0412 2010 \u0433\u043e\u0434\u0443 \u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Wargaming \u0431\u044b\u043b\u043e 50 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u043f\u0440\u043e\u0441\u0442\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c: \u0431\u044d\u043a\u0435\u043d\u0434, \u0444\u0440\u043e\u043d\u0442\u0435\u043d\u0434 \u0438 \u0444\u0430\u0439\u0440\u0432\u043e\u043b.","og:url":"https:\/\/prohoster.info\/da\/blog\/consul-iptables-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-05T18:28:58+00:00","article:modified_time":"2020-02-05T18:28:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"41051","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:24:42","updated":"2022-10-01 10:00:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/41051","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=41051"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/41051\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/41052"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=41051"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=41051"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=41051"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}