Rekursive rûteleasing: as de tunnel syn eigen pakketten opfynt

De tunnel komt omheech, it logboek lit in foltôge hânskud sjen, en in sekonde letter stjert deselde sesje en ferbynt him wer yn in lus. Dat patroan hat in beskate oarsaak: de rûte nei de tsjinner wiist no de tunnel yn, dus de pakketten dy’t de tunnel drage wurde troch de tunnel stjoerd. Oan ’e autentikaasje is neat feroare, en dêrom makket it op ’e nij ynfieren fan ’e oanmeldgegevens gjin ferskil. Ferlykje it bûtenste paad foar en nei de rûtewiziging, dan wurdt de rekursje sichtber.

Kontrolearje earst it bûtenste paad

Der binne twa pakketten yn it spul, net ien. It binnenste pakket heart by de applikaasje en soe fersifere wêze moatte, wylst it bûtenste pakket oan de tsjinner adressearre is en him berikke moat oer in paad dat net fan ’e tunnel ôfhinget.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Freegje de kearn om de rûte nei it adres fan ’e tsjinner neidat de tunnel omheech is, en wer neidat de standertrûte feroare is. In folgjende hop dy’t op it tunnelapparaat delkomt is de rekursje, en dy is sichtber sûnder hokker pakketopname dan ek. It binen oan in interface, markearrings of in netwurknammeromte kinne in gewoane syktocht ûnfolslein meitsje, dus brûk de kontekst dy’t de client sels brûkt. As it antwurd goed liket mar de sesje bliuwt yn ’e lus, lês de regels fan it rûtebelied en net allinnich de haadtabel.

Wêrom’t de sesje in momint oerbliuwt

It hânskud is klear foardat de nije rûte ynstallearre wurdt, dus de earste sekonden lykje sûn. Sadree’t de client de standertrûte taheakket, folget it folgjende bûtenste pakket dy de interface yn dêr’t dat bûtenste pakket troch moat. De tsjinner sjocht neat, de client ferstjoert op ’e nij, en de poging rint ôf of slacht de sesje dea en begjint oer.

Dy folchoarder ferklearret wêrom’t in tunnel op in laptop wurkje kin en op in router misse kin, en wêrom’t de flater faak begjint as it ferkear úteinset en net by it ferbinen. Hy ferklearret ek de lus: elke werstart set de sesje wer op foardat de rûte dat ûnmooglik makket.

Fyn wa’t de útsûndering fan it einpunt hat

Stipe clients regelje har eigen útsûndering: in hostrûte nei de tsjinner fia de oarspronklike gateway, of in markearring dy’t de bûtenste socket bûten de tunnel hâldt. De fraach is oft eat oars dy fuorthelle of oerskreauwen hat.

Foar rûtebasearre IPsec moatst de beliedsselekteurs besjen dy’t beslute hokker pakketten de tunnel yn geane, en befêstigje dat it adres fan ’e peer derbûten falt. Foar WireGuard hâlde de firewallmarkearring fan ’e interface en syn beliedsregels de transportpakketten bûten de tunnel, sadat in mei de hân taheakke standertrûte dy regeling brekke kin. In twadde VPN-profil of in behearskript dat de standertrûte oerskriuwt is in faak foarkommende skuldige. Brede omgongsregels dy’t ien foar ien taheakke wurde binne it gewoane resultaat, en se feroarje in rûteflater yn in tabel dy’t nimmen ûnderhâlde kin.

Kontrolearje op ’e nij nei in netwurkferoaring

In hostrûte fia in Wi-Fi-gateway is korrekt oant de masine nei in oar netwurk ferhuzet. Dan komt itselde symptoom werom sûnder hokker konfiguraasjewiziging dan ek.

Skriuw it adres fan it einpunt op, de rûte foar en nei it ferbinen, en de interface dy’t elk brûkte. Dy trije feiten skiede meastentiids in clientflater fan in oerskriuwing, en se oerlibje dejinge dy’t se sammele hat.

Ferbyn op ’e nije netwurk wer en werhelje it lêzen. As de útsûndering wer ûntbrekt, heart de oanpassing yn it profyl dat him hat, net yn in ienmalige opdracht dy’t by in steuring yntype is.