Aðskilin útleið: VPN-safn á usb0, gáttarumferð á eth0

Biðlar tengjast og sannvotta sig, og þá fer umferðin út um ranga uppstreymisleið, því eina sjálfgefna leiðin á vélinni tilheyrir gáttinni sjálfri. Að skipta um þá sjálfgefnu leið myndi brjóta eigin uppfærslur vélarinnar og stjórnunaraðgang, svo valið verður að vera þrengra en „öll umferð“. Vinnanlegt form er stefnuregla sem byggir á innra upprunaaðsetri biðlasafnsins og vísar á aðra leiðatöflu sem á hina WAN-leiðina. Þaðan fjallar gátlistinn um heilleika og hegðun við bilun, ekki regluna sjálfa.

Staðfestið að upprunaaðsetrið lifi til leiðarákvörðunar

Stefnuregla sem passar við upprunasvið virkjast aðeins þegar pakkinn ber enn þann uppruna við uppflettinguna. Framsend biðlaumferð gerir það, svo framarlega sem ekkert ofar hefur skrifað hana aftur fyrir leiðarvalið. Umferð sem gáttin býr sjálf til gerir það ekki, og þess vegna getur sjálfgefna leið gáttarinnar verið kyrr þar sem hún er.

Hér villa staðbundnar prófanir um fyrir manni. curl sem keyrt er á gáttinni er staðbundið myndað flæði með aðsetri gáttarinnar, svo það tekur aðaltöfluna og sannar ekkert um slóð biðilsins. Prófið frá tengdum biðli, eða búið til umferð með uppruna sem tilheyrir safninu í raun.

Byrjið á að skrifa niður raungildin: forskeyti safnsins, tunnuviðmótið sem ber það, aðsetur og næsta stökk hinnar WAN-leiðar, og töflunúmerið sem þið ætlið að nota. Hreinsið gömlu reglurnar frá hverri fyrri tilraun áður en þið bætið nýjum við, því tvíteknar reglur á mismunandi forgangi valda bilunum sem líta út fyrir að vera handahófskenndar.

Byggið valda töflu sem er heildstæð

Tafla er ekki sjálfgefin leið með vin. Hún þarf nógu margar leiðir til að hver uppfletting leysist innan hennar, þar á meðal tengda leið fyrir WAN-undirnetið svo næsta stökk sé aðgengilegt. Fyrir safn 10.77.0.0/24 á tun1, WAN-aðsetur 203.0.113.20/24 með næsta stökki 203.0.113.1, og töflu 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Reglan situr á forgangi undir hverri fyrirliggjandi grípa-allt reglu, svo samsvarandi biðlar ná fyrst töflu 600 og allt annað fellur í aðaltöfluna. ip-rule-tilvísunin lýsir röðuðu uppflettilíkaninu og setningafræði valsins að fullu.

Hugsið svo um það sem taflan inniheldur ekki. Áfangastaður sem hefur leið aðeins í aðaltöflunni, til dæmis stjórnunarundirnet sem næst um eth0, finnst ekki í töflu 600 og fellur ekki aftur í aðaltöfluna þegar sjálfgefin leið er þar. Ef þessar slóðir skipta máli skuluð þið bæta þeim skýrt við valdu töfluna, sem er venjulega rétta svarið fyrir útleiðartöflu VPN.

Haldið eigin umferð hlustandans utan stefnunnar

Hlustandinn OpenVPN hefur sína eigin ytri tengingu, borna um þá uppstreymisleið sem biðillinn náði til hans um. Sú umferð verður að halda þeirri afturleið sem hún kom með, og breið regla sem nær yfir opinbert aðsetur þjónsins eða allt tunnuviðmótið getur dregið hana inn í hina töfluna. Takmarkið regluna við innra safnið og ekkert annað.

Síun afturleiðar á skilið að kíkja á af sömu ástæðu. Þegar svör til biðla fara út um usb0 á meðan beiðnin kom um aðra tengingu getur ströng rp_filter stilling varpað burt pökkum sem leiðarstefnan telur gilda. Athugið gildandi sysctl-gildi á báðum viðmótum áður en þið ályktið að reglan hafi brugðist.

Röðin skiptir líka máli gagnvart öllu öðru á vélinni. Docker-brýr, önnur VPN og allar fyrirliggjandi reglur úr mynd þjónustuaðila bæta við forgangi, svo lesið alla reglulistann í stað þess að gera ráð fyrir að forgangur 100 standi einn.

Látið framsendingu og þýðingu stemma við leiðina

Leiðarval velur uppstreymisleið; það veitir ekki leyfi til að framsenda. Kjarninn verður að hafa IPv4-framsendingu virka, og eldveggurinn verður að samþykkja stefnuna frá biðli til WAN og afturumferðina. Rétt tafla með FORWARD-keðju sem sleppir flæðinu gefur sömu einkenni og leið sem vantar, þess vegna eru bæði athuguð í sama ferli.

Ef hin WAN-leiðin mun ekki leiða einkasafn aftur til ykkar, þýðið upprunann á þeirri útleið. Fyrir viðmót með kviku aðsetri er venjulegi kosturinn þröng masquerade-regla takmörkuð við safnið og viðmótið:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Umfangið skiptir meira máli en markið hér. Masquerade-regla sem passar við hvaða útleiðarviðmót sem er mun líka endurskrifa umferð sem fer rétt út um eth0, og það felur leiðarvillur í stað þess að laga þær. Þýðing keyrir eftir leiðarákvörðunina, svo hún getur aldrei lagað pakka sem sendur var um röngu uppstreymisleiðina.

Tunnuálagið þarf líka athygli þegar slóðirnar eru ólíkar. Ef biðlar semja um stórt TCP MSS og hin WAN-leiðin er með lægra MTU eða tunnu inni í sér, stöðvast stór hlutar á meðan litlir virka. Að þrengja MSS á framsendingarslóðinni gerir þetta að fyrirsjáanlegri hegðun í stað stundarlegrar stíflunnar.

Ákveðið hvað gerist þegar usb0 hverfur

Tóm tafla er ekki lokandi staða við bilun. Ef samsvarandi leið hverfur heldur uppflettingin áfram á næstu reglu, nær aðaltöflunni og tekur sjálfgefnu eth0-leiðina. Umferð sem átti að fara út um hina WAN-leiðina fer hljóðlega út um þá fyrri, sem í uppsetningu með stefnuleiðingu er venjulega útkoman sem þið viljið síst.

Þar sem sú afturhvarf er óásættanleg skuluð þið bæta skýrri endanlegri leið við töflu 600, til dæmis blackhole-sjálfgefinni leið, eða sleppa safninu í eldveggnum á meðan viðmótið er niðri. Hvort tveggja er ákvörðun sem þið getið skrifað niður; þögn er það ekki.

Varanleiki er síðasti liðurinn. Sá sem á báðar tengingarnar, hvort sem það er netstjórinn, sendingarskript eða lífsferill tengingarinnar, verður að endurskapa leiðirnar og regluna við hverja endurtengingu án þess að bæta við tvítekningum. Sannreynið með beiðni frá raunverulegum biðli og aðskilinni beiðni frá gáttinni, staðfestið séða útleið í báðum, dragið síðan hina WAN-leiðina og fylgist með hvor af tveimur hönnuðum útkostum raunverulega verður. IPv6 þarf sína eigin töflu, reglu og þýðingu; IPv4-reglan hér að ofan segir ekkert um hana.