Hverfa svör Linux VPN? Athugaðu rp_filter og leiðina

Beiðnir yfirgefa vélina, VPN-jafninginn svarar, og svarið nær aldrei í sokkinn. Göngin eru uppi, annálar jafningsins sýna að pakkinn er sendur, og ekkert í forritinu útskýrir þögnina. Á Linux er eitt algengra grunsemda síun öfugrar leiðar: hægt er að hafna innkomandi IPv4-pakka þegar upprunastaðfesting passar ekki við leiðina sem kjarninn ætlast til fyrir þann uppruna. Að fara í gegnum þetta í röð segir þér hvort það sé orsökin eða tilviljun. Það kemur líka í veg fyrir að þú slökkvir á öryggisstýringu til að laga leið sem vantar.

Hvað upprunastaðfestingin ákveður

Kjarninn athugar hvort upprunastaður pakka sé sennilegur fyrir viðmótið sem hann barst á, með því að fletta upp í leiðartöflunni leið til baka til þess uppruna. Ef öfug leið vísar annað getur pakkinn verið felldur áður en nokkur eldveggjarregla eða forritssokkur sér hann. Þessi athugun er til að gera ákveðin fölsunarmynstur erfiðari, og þess vegna rekast ósamhverf og stefnuleiðstýrð hönnun á hana á meðan hver venjulegur biðlari á sama neti virkar fínt. Venjulegir biðlarar hafa samhverft leiðarval, sem er einmitt það sem athugunin gerir ráð fyrir.

Mikilvæga orðið er sennileg. Pakkinn getur verið fullkomlega lögmætur og samt fallið á athuguninni, því það er ekki lögmætið sem er prófað.

Lestu raunverulega haminn, ekki einn reit

Þrír hamir eru til: óvirkur, strangur og slakur. Strangur setur aðra leiðarventingar en slakur, og almenna stillingin hefur áhrif ásamt þeim fyrir hvert viðmót, svo lestur eins skjals getur lýst rangt því sem í raun gildir. Lestu bæði, og lestu þau á viðmótinu sem tekur á móti svarinu, ekki á viðmóti sjálfgefnu leiðarinnar.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Leiðarleitin í þriðju línunni er sá hluti sem fólk sleppir. Hún segir þér hvað kjarninn telur um upprunann, og það er einmitt inntak athugunarinnar.

Finndu misræmið áður en þú breytir athuguninni

Finndu út hvers vegna svarið berst á það viðmót og hvort öfug leið þess eigi að vera önnur. Stefnuregla sem sendir beiðnir út um eina leið á meðan svör koma til baka um aðra er lögmæt hönnun, og það er líka hönnunin sem ströng staðfesting hafnar. Merki sem notuð eru í stefnuleiðarvali geta skipt máli hér líka, því þau breyta því hvað öfugleitin skilar.

Ef öfug leið vantar einfaldlega lagar að bæta henni við orsökina í stað þess að slökkva á athugun. Leið sem vantar, höfnun eldveggjar og rangur umferðarval geta öll framkallað sömu sýnilegu einkennin, og aðeins eitt þeirra snýr að upprunastaðfestingu.

Ekki slökkva á upprunastaðfestingum almennt sem fyrsta viðbrögð. Það skiptir ákveðinni greiningu út fyrir breiða hegðunarbreytingu sem þú þarft að muna eftir síðar.

Sértæk stilling sem þú getur varið

Ef þröng stilling er sannarlega nauðsynleg, takmarkaðu hana við viðmótið sem þarf hana, skrifaðu niður hvers vegna, og settu hana í stillingarnar sem eiga það viðmót svo hún lifi endurræsingu. Prófaðu svo aftur nákvæmlega það flæði sem brást, frá sama uppruna til sama áfangastaðar, í stað ping til einhvers þægilegs.

Láttu fylgja mál sem á enn að hafna. Ef það mál tekst núna veikti stillingin meira en eina leiðina sem þú ætlaðir að laga.

Haltu IPv4 og IPv6 aðskildum

Þekkt útlit sysctl er ekki stefna fyrir hverja vistfjölskyldu. IPv6 hefur eigin hegðun og eigin stillingar, og vél getur verið ströng í einni fjölskyldu og mild í annarri án þess að nokkur taki eftir því fyrr en ákveðinn áfangastaður bregst. Athugaðu bæði ef vinnuálagið notar bæði.

Skráðu haminn, viðmótið, útkomu leiðarleitarinnar og ástæðu breytingarinnar á einn stað. Næsta manneskja finnur stillinguna og enga skýringu, og mun annað hvort fjarlægja hana eða afrita hana þangað sem hún á ekki heima.