Lokale app, VPN-regel: wêrom’t jo FORWARD-keten nea ôfgiet
In proses op ’e masine brûkt OUTPUT, net FORWARD. Kies de heak yn ’e juste nammeromte en beslút dan oft in mark of in gewoane rûte genôch is.
Jo foegje in regel foar VPN-ferkear oan ’e FORWARD-keten ta, fiere it fersyk fan deselde Linux-masine út, en de teller bliuwt op nul. De regel is wierskynlik korrekt. It pakket hat dy wei nea nommen, om’t in fersyk dat op ’e masine sels ûntstiet, troch dy masine net trochstjoerd wurdt. It libben fan it pakket fan ’e socket nei de tried folgje ferklearret wêrom, en wêr’t de regel ynstee heart.
Fyn wêr’t it pakket berne waard
De heakfolchoarder fan Netfilter skiedt trije gefallen, en mar ien dêrfan hat FORWARD yn ’e mjitte:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
In lokale applikaasje begjint yn it OUTPUT-paad, om’t de kearn al fêststeld hat dat it pakket hjir ûntstiet en nea in kandidaat foar trochstjoeren is. In tunnel meitsje feroaret dy klassifikaasje net; de tunnel is in apparaat dêr’t it pakket troch fuortgean kin, net in stadium dat lokale útfier yn transyt feroaret.
Twa pakketten, ien ferhaal
As de tunnel ienris stiet, binne it ynderlike pakket fan ’e applikaasje en it fersifere úterlike pakket ferskillende objekten. It ynderlike pakket draacht de bestimming en lading dy’t de app keas. It úterlike pakket draacht siferskrift nei it adres en de poarte fan ’e peer, en dat is wat eins de fysike ynterface oerstekt.
Jo belied giet oer ien fan beide, en it ferkearde kieze is in faak foarkommende reden dat in regel like neat te dwaan. In regel dy’t oerienkomt mei it úterlike adres fan ’e peer, sjocht elk tunnelpakket itselde, wat de applikaasje binnen ek docht. In regel dy’t oerienkomt mei in ynderlike bestimming, sjocht it ferkear dêr’t jo om tinke, en dy sil allinnich ôfgean as dat pakket de heak berikt dêr’t jo de regel op ynstallearre hawwe.
Nammeromten ferpleatse de grins
In container makket dit dreger sûnder it prinsipe te feroarjen. It fersyk fan ’e applikaasje is lokale útfier binnen de netwurknammeromte fan ’e container. De host ûntfangt dat ferkear op in firtuele Ethernet-ynterface en kin it trochstjoere, dus in FORWARD-regel op ’e host kin sinfol wêze, ek al hat it proses dat it fersyk makke nea de OUTPUT-keten fan ’e host oanrekke.
Foardat jo in heak kieze, stel fêst wêr’t de regelset en de tunnel eins libje. In tunnel binnen de container, in tunnel op ’e host mei de container dertroch rûte, en in tunnel yn in aparte nammeromte binne trije ferskillende topologyen mei trije ferskillende regelplakken. Lês de regels binnen de nammeromte dy’t it apparaat besit, net allinnich yn ’e standert.
Freegje jo ôf oft jo wol in mark nedich hawwe
As it doel is ien bestimmingsprefiks troch de tunnel te stjoeren, kin in rûte foar dat prefiks genôch wêze. Kontrolearje earst de effektive rûtes, ynklusyf alles wat de tsjinner skood hat: in omalte standertrûte stjoert folle mear ferkear troch it VPN as it smelle belied dat jo yn ’t sin hiene, en gjin hoemannichte markearring sil it resultaat mei de bedoeling oerienkomme litte.
Klassifikaasje is nedich as de beslissing ôfhinget fan eat dat in rûte net útdrukke kin, lykas de boarne, de brûker of it proses. Foar ûntfongen ferkear wurket markearring yn PREROUTING. Foar lokaal ferkear moat de markearring barre yn in útfierstadium dat in nij rûte-ûndersyk útlizze kin nei’t de mark set is. Mei nftables is dat in keten fan it type route op ’e útfierheak; in gewoane útfierfilterketen sil de wearde sette en de rûte ûnferoare litte.
Mei iptables libbet it ekwivalint yn ’e mangle OUTPUT-opstelling, en deselde eask jildt: de rûtebeslissing moat opnij besjoen wurde nei’t de mark bestiet. Dan moat in beliedsregel de mark brûke en nei in tabel wize dy’t in brûkbere rûte befettet. In conntrack-mark sette is in tredde, aparte operaasje; it bewarret in wearde op ’e stream en set dy wearde net op himsels op it hjoeddeistige pakket sadat rûtering it lêze kin.
Kontrolearje it sykjen en de teller tegearre
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1
It adres en de mark binne yllustratyf, en de twa rûtefragen beantwurdzje ferskillende fragen. De twadde freget wat de kearn dwaan soe as in pakket dy mark droech; it wiist net út dat jo regelset ien tawiist. Behannelje it as in hypotezetest, net as bewiis dat it belied wurket.
Fier dan in ûngefaarlik fersyk út en sjoch tagelyk twa dingen: de teller op ’e heak dy’t jo keazen, en de útgong dy’t it pakket eins naam. As de teller beweecht en it pakket fart earne oars fuort, binne de mark of de tabel ferkeard. As gjin fan beide beweecht, berikt it pakket dy heak hielendal net, en de folgjende fraach is de nammeromte of it paad.
Ta beslút, behein de test ta wat it meganisme útdrukke kin. Ien rûte foar ien adres wurdt gjin permanint belied foar in tsjinst waans adressen rotearje. Beslút earst it pakketberik, en kontrolearje dan oft it rûte- en markearringsûntwerp dat berik nei in werferbining hâlde kin.