Zergatik zure Linux zerbitzu publikoak VPN bidez erantzuten duen

Socket-ean ezerk ez du gogoratzen zein interfazek eraman zuen eskaera, beraz tunel osoko VPN baten bide lehenetsiak WAN-era dagokion erantzun bat har dezake. Zerbitzuak ez dio sarrerako interfazeari jaramonik egiten; Linux-ek tokian sortutako erantzuna bideratzen du helmugaren eta iturburu-politikaren arabera. Iturburuan oinarritutako arau batek zerbitzuaren erantzunak soilik bidal ditzake WAN taula oso baten bidez, irteera arrunta tunelean utzita. Ataka irekita mantentzen da erantzuna bide okerretik irteten den bitartean, eta horregatik sintomak alde bakarreko itxura du.

Gaizki ulertzea: erantzunek iritsi ziren interfazea jarraitzen dute

Logikoa dirudi eth0-n iristen den pakete batek eth0-tik irtetea. Egoerarik gabeko pakete-iragazkiak horrela idatz daitezke, eta sarrerako aldean tcpdump-ek eskaera espero den lekuan bertan erakusten du. Bideratzeak ez du horrela funtzionatzen ostalariak berak sortzen duen trafikoarentzat.

Zerbitzuak konexioa onartzen duenean, haren erantzuna tokian sortutako pakete berria da. Kernelak erantzunaren helmuga eta iturbururako bideratze-arauak kontsultatzen ditu, eta VPN-aren bide lehenetsia erantzun erabat baliozkoa da. Socket-ean ezerk ez du gogoratzen zein interfazek eraman zuen eskaera.

Horregatik sintomak alde bakarreko itxura du: eskaerak iristen dira, erantzunak desagertu egiten dira. Horregatik ere sarrerako atakarentzako suebaki-arau bat gehitzeak ez du ezer aldatzen. Paketea ez da barruranzko bidean blokeatzen; kanporanzko bidean beste norabait bideratzen da. Jarraitu erantzunari iturburuz kalifikatutako bilaketa batekin eta saihesbidea ikusgai bihurtuko da.

Kernelak benetan bideratzen duena: iturburu helbidea

Behar duzun heldulekua zerbitzuak erantzunetarako erabiltzen duen tokiko helbidea da. 192.0.2.10/24 eth0 helbide ilustratzailea eta 192.0.2.1 atebidea dituen ostalari batean, helbide hori interfazean dago. Hodeiko VM batean, helbide publikoa goragoko mailan itzulita egon eta gonbidatuan ez egon daiteke, beraz erabili ostalariak benetan duen helbidea.

Ikuskatu uneko egoera taula-zenbaki edo arau-lehentasun bat erreserbatu aurretik. Lehendik dauden politika-arauak berri bat itzal dezakete, eta zenbaki bereko taula zahar batek jada erlaziorik gabeko bideak eraman ditzake:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Ondoren hautatu taula bat iturburuaren arabera. Araua jada 192.0.2.10 daramaten erantzunekin bat dator, hain zuzen salbuetsi nahi duzun tokian amaitutako trafikoarekin. Birbidalitako trafikoak eta beste tokiko helbide batzuetako paketeek ez dute bat egiten.

Eraiki itzulera-taula oso bat, ez erdi bide lehenetsi bat

Bide lehenetsi bat soilik duen taula ez da nahikoa. Kernelak atebidea ebatzi behar du oraindik, eta ebazpen horrek prefijo konektatua behar du taula berean. Prefijo hori falta zaion taula batek atebidearen ebazpenean huts egiten du, bere bide lehenetsia zuzena dirudien arren. Gehitu biak, eta gero zuzendu iturburu-araua taulara:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Erabili benetako prefijoa eta atebidea adibidea kopiatu beharrean. On-link atebidearekin /32 gisa konfiguratutako hodeiko interfaze batek beste bide konektatu bat behar du, eta prefijo okerretik eraikitako taula batek lehen jauzian huts egiten du. src atributuak bide horretarako lehentasunezko iturburua adierazten du; ez du iturburu-araua ordezkatzen.

Ordenak ere badu garrantzia. Lehentasun-zenbaki txikiagoa duen arau zabala lehenengo ebaluatzen da, beraz iturburu-araura iritsi behar da trafiko hau taula nagusira itzuliko lukeen edozein arau baino lehen. Egiaztatu lehentasunak ip rule show erabiliz gehitu ondoren, ez soilik abioan.

Egiaztatu iturburuz kalifikatutako bilaketarekin

Eskatu kernelari zerbitzuaren helbidetik probako helmuga bat bideratzeko. Erantzunak eth0 eta WAN atebidea aipatu beharko lituzke, ez tunela:

ip -4 route get 198.51.100.25 from 192.0.2.10

Ondoren egin baimendutako konexio berri bat eta behatu bi norabideak. Taula zuzena hautatzen duen bilaketa batek, konexio erreala oraindik huts egiten duen bitartean, alderantzizko bidearen iragazketara edo suebaki-arau batera eramaten du, ez taulara. Egiaztatu kontrol horiek ezer globalki desgaitu aurretik.

Jarri azken bideak eta araua interfazearen jabea den sare-kudeatzailearen pean. Helbide-aldaketek, DHCP berritzeak eta VPN berriz konektatzeek kernelaren egoera osoa berridazten dute, eta eskuz gehitutako arau bat desagertu egiten da edo atebide zaharkitu bat seinalatzen du hurrengo gertaeraren ondoren.

Non amaitzen den salbuespen hau

Arauak iturburu helbide batetik tokian amaitutako trafikoa salbuesten du. Ez ditu estaltzen Docker-ek argitaratutako atakak, DNAT edo ostalariaren bidez birbidalitako zerbitzuak, pakete horiek birbidalitako trafiko gisa bideratzen direlako eta inoiz ez dutelako ostalariaren tokiko iturburua modu berean eramaten. Diseinu horiek sarreran jarritako marka bat eta markarekin bat datorren arau bat behar izaten dituzte.

Ez du ere ostalariaren helbide publikoa interfazean agerrarazten. NAT goragoko batek helbide horren jabe denean, erantzunak oraindik NAT horrek espero duen bidetik irten behar du, eta horregatik WAN taulak jatorrizko atebidea eta prefijoa islatu behar ditu, asmatutako barruti publiko bat ordez.

Mantendu salbuespena dokumentatuta bere taula-zenbakiarekin, arau-lehentasunarekin eta iturburu-helbide zehatzarekin. VPN-an edo interfazean hurrengo aldaketak isilean hauts dezake, eta hiru balioak aipatzen dituen ohar bat bezero-txosten batetik sintoma berriz aurkitzea baino azkarrago egiaztatzen da.

Zerbitzuak bide okerretik erantzuten badu iturburuz kalifikatutako bilaketa arrakastatsua izan eta gero, alderatu socket bizien iturburu-helbidea araukoa denarekin. Helbide komodin bati lotutako zerbitzu batek probatu duzun helbidea ez den iturburu bat hauta dezake, eta desadostasun hori da geratzen den hutsunea.