Folle tunnel hat dyn SSH-sesje dea makke: pin de weromrûte fêst

Start in OpenVPN-klant op de masine wêrop't do oer SSH wurkest, en midden yn 'e opdracht ferstiivt de sesje. De tunnel meldt dat er ferbûn is, de host berikt it ynternet der troch, en dyn toetsoanslaggen komme noch altyd oan wylst der neat weromkomt. Wat feroare is, is net de tunnel: it is de weromrûte foar pakketten dy't oan dy adressearre binne, dy't no oerienkomt mei de nije standertrûte en in tunnel yn giet dy't de fiere poarte net brûke sil om dyn buro te berikken.

Wat redirect-gateway eins ynstallearret

Yn syn def1 foarm redirect-gateway foeget 0.0.0.0/1 en 128.0.0.0/1 ta yn plak fan de standertrûte oer te skriuwen. Dy beide helten dekke de hiele adresromte wylst se beide langere foarheaksels bliuwe as 0.0.0.0/0, dus elk bestimming sûnder in mear spesifike oerienkomst giet no de tunnel yn. Dat is it meganisme om fêst te hâlden, want elke reparaasje hjirûnder wurket troch in mear spesifike oerienkomst te ynstallearjen.

Dyn behearderadres is ien fan dy bestimmingen.

De VPN-tsjinner stjoert ferkear fan syn klanten nei it ynternet. Hy hat gjin rûte foar it iepenbiere adres dêr't do fan ferbynt, en gjin reden om dy pakketten oars te behanneljen as ferkear dat fan in klant komt, dus hy smyt se fuort. Underwilens berikte it fersyk dat do stjoerde de host dochs, en dêrom liket de sesje allinnich oan ien kant libjend.

ip route show table main | head -n 20
ip route get 198.51.100.23

Fyn dyn boarneadres en it paad foar de tunnel

Op de tsjinner, list de oprjochte SSH-ferbining op en notearje it peer-adres dêr't er wei kaam. Dat adres is wat dyn weromrûte dekke moat, en it is net altyd wat do tinkst: in springhost, in NAT-poarte of in oersetter fan 'e provider kin in oare boarne ferfange.

Fyn dan de fysike poarte en it ynterface dat ferkear droech foardat de tunnel begûn. Yn 'e def1 opstelling is de standertrûte noch altyd oanwêzich ûnder de heal-standerten, dus de ynformaasje is beskikber, al noeget it lêzen fan in lange rûtetabel mei it each flaters út.

Notearje beide wearden en de ynterfacenamme byinoar, want de rûte dy't do op it punt stiest ta te foegjen hat alle trije nedich. As de host in beliedsrûtearringregel brûkte om syn uplink te kiezen, wurdt in gewoane rûte miskien hielendal net besjoen, en dy mooglikheid feroaret de reparaasje.

Pin in hostrûte fêst dy't de heal-standerten oertroeft

In rûte /32 is langer as elk fan 'e beide heal-standerten, dus antwurden op dyn adres nimme dy boppe de tunnel. De folgjende hop is de poarte foar de tunnel en it apparaat is it fysike ynterface, wat it pakket op it paad hâldt dat it brûkte foardat de tunnel bestie.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Ferifiearje mei in opsocht yn plak fan troch de tabel te besjen: it antwurd moat eth0 en de poarte neame, nea tun0.

OpenVPN foeget al in hostrûte nei it eigen adres fan de VPN-tsjinner ta om deselde reden, dus it patroan is bekend en it behearderadres is gewoan noch in útsûndering. Gryp net nei route-nopull om dit te reparearjen, want it smyt de trochstjoerde rûtes fuort dy't de tunnel nedich hat, ynklusyf it fiere netwurk en de DNS-opsjes.

Meitsje dat it in werferbining oerlibbet

In rûte dy't mei de hân tafoege is ferdwynt as de klant wer ferbynt en syn eigen ynstallearret, wat in reparaasje yn in weromkommende steuring feroaret. Heakje de opdracht oan eat dat rint neidat rûtes ynstallearre binne.

Sawol in route-up-skript as de pre-up-heak fan 'e netwurkbehearder wurkje, en de betroubere kontrôle is in werferbining folge troch itselde opsocht.

Op Windows is it ekwivalint in permaninte rûte tafoege mei -p, dy't werstarts oerlibbet mar noch altyd nei de krekte poarte wize moat nei in netwurkferoaring. Hokker platfoarm ek, skriuw de reden njonken de rûte: de folgjende behearder moat witte dat se bestiet om in behearsesje te beskermjen, net om't it netwurkûntwerp it easke.

Wannear't in fêstpinde rûte noch net genôch is

Filtering fan it werompaad kin in pakket fuortsmite dat op ien ynterface oankomt en troch in oar fuortgiet, en dat is krekt wat in fêstpinde rûte makket. Kontrolearje de effektive rp_filter wearde foardat do eat globaal útskeakelest, en ferkies it reparearjen fan 'e asymmetry boppe it útsette fan 'e kontrôle. It is de ynstelling per ynterface dy't jildt, en de loose-modus registrearret faak allinnich de asymmetry yn plak fan it pakket fuort te smiten. Lês beide foardat do konkludearrest dat it filter dyn skuld is.

Hosts mei beliedsrûtearring hawwe in regel nedich njonken in rûte, want de regelbasis kiest de tabel foardat de rûte deryn besjoen wurdt. In rûte yn 'e main-tabel is ûnsichtber foar in stream dy't oerienkomt mei in regel dy't nei in oare tabel wiist. Lês de regels foardat do eat oan main taheakest. As in regel al behearsferkear dekt, heart de útsûndering ynstee yn 'e tabel fan dy regel.

Hâld in bûtenbân-konsole iepen wylst do testest, en kontrolearje opnij fan in twadde oanmelding foardat do dy't do brûkst loskeppelest. In rûte dy't dyn eigen behearsferkear de tunnel yn stjoert, snijt de ferbining troch dêr't do it troch reparearrest. Weromkomme betsjut dan in searjele konsole of in rêdingsstart, wat in minne ruil is foar it oerslaan fan ien ferifikaasjestap.